
Ask HN: How to get developers to care less about edge cases? - exabrial
I&#x27;m noticing a frequent problem with a handful of developers. Rather than coding for the 80% of what an application must do, they think of all the possibilities that go wrong and start from the edge cases inwards, which individually represent a small piece of functionality.<p>I would rather they deliver a working chunk and just log.error when missing information is present.<p>Working in the manner they do is causing them to miss deadlines with nothing to show. I&#x27;d be ok if they missed deadlines but an app handled 50% of what it&#x27;s supposed to do and it&#x27;s well documented what it doesn&#x27;t do, but we&#x27;re getting to the finish line with no workable product.
======
rowanG077
I'm noticing a frequent problem with a handful of construction workers. Rather
than constructing for the 80% of what a building must do, they think of all
the possibilities that go wrong and start from the edge cases inwards, which
individually represent a small piece of the whole.

I would rather they deliver a building and just let it collapse when an edge
case occurs.

Working in the manner they do is causing them to miss deadlines with nothing
to show. I'd be ok if they missed deadlines but a building could already be
used for 50% and it's well documented what it doesn't do, but we're getting to
the finish line with no useable building yet.

~~~
lawnchair
nope. doesn't apply. construction is public safety. software, most of the
time, is not life and death.

~~~
rowanG077
The comment was more of a joke. But the message behind it is something I do
believe. Software at this point in time is kind of a joke. It's plagued by so
many problems that people don't even blink anymore when there is software bug.
The kind of attitude OP has is precisely the problem why the field is a joke.

------
beardedProgmr
Just remember this when someone order -9999 items and you send a customer a
few mill..

But for sure. Tactic id use is get MVP working and have a ticket for edge
cases. But really low quality devs will push janky code. Good devs will stop
and make it solid. Great devs pick their battles and hit some deadlines and
fix major corner cases..

~~~
dmlittle
I can’t remember where I first heard this but this is the first article I
could find about being able to buy a negative amount of books in Amazon

[https://www.businessinsider.com/when-amazon-launched-a-
bug-a...](https://www.businessinsider.com/when-amazon-launched-a-bug-allowed-
users-to-get-paid-by-the-company-2011-10)

------
ereyes01
I think an important qualifying question is: how does your team/company deal
with failures? Is there some other carrot/stick that incentivizes developers
to behave this way?

There's certainly a rational argument to be made that a project's progress is
important and lines of "acceptable quality" should be drawn somewhere, but
people are often not rational and respond to other things, and that's probably
where your problem lies, IMO.

For example- I used to work in a team that maintained an enterprise UNIX
kernel, and we had a space shuttle - like culture of obsessive failure
prevention using meticulous process and checks, because the cost of a failure
could mean [m|b]illions of dollars at our customer sites. I now create
startups, and the incentives are the absolute opposite- I need to get
_something_, _anything_ out the door as soon as possible because the most
important question I need to answer is "does anyone want this?"

The reasons for either approach are not technical, and the source of your
frustration, I suspect, is deeper than "convincing developers" (though I look
forward to hearing what you have to say).

EDIT: this post also expands a bit on the carrots/sticks I was referring to
above: [https://www.verica.io/inhumanity-of-root-cause-
analysis/](https://www.verica.io/inhumanity-of-root-cause-analysis/)

~~~
ericathegreat
This. Absolutely.

If something fails six months after release, who ends up paying the penalty?

Are your developers on-call for production issues? Will they be woken up at 3
in the morning, expected to solve customer issues caused by one of those
corner cases? Or if it's someone else on call, will your developers experience
the wrath of the person who _was_?

If a production issue occurs, does the person who produced that code get
pulled off whatever new they are now working on, because "they're the best
person to fix that issue"? Even if they've "moved on and up" and their new
work is more interesting or prestigious than the project that has the issue?

Is their failure publicized across the whole business?

If data is corrupted because of a corner case, do your developers have to go
through tedious processes to repair that data (with angry customers causing
frustrated managers to breathe down their necks)?

Do they have to defend and justify to all of their peers why their code broke
production because of a "corner case" that they were fully aware of and chose
not to handle?

And even more importantly, if they build the 80% first, what guarantee do they
have that you will let them write the last 20%, and not just move on to the
next thing? Consider - if they build the corner cases first, they've
guaranteed that they'll get all the scoped work done (because you won't ship
without the other 80%), but if they front load that highly visible 80%, they
will almost certainly get pulled off the project before they get to handle
those corner cases.

All of these things are very strong motivators for teams to do exactly what
you're asking them not to do. As a (presumably) product focused person, your
reward happens as soon as your product is in customers' hands. You are
rewarded for a product that is released quickly. But developers are frequently
penalized for that.

When you ask your development team to focus on releasing incomplete software,
you're asking them to treat _your_ success as more important than _theirs_.

That doesn't mean that what they're doing is necessarily right. You need to
set up an environment where your teams' success is aligned to the thing you
most want to have happen. Change the rewards and penalties in your company,
and behavior will change itself.

Or, failing that, negotiate a compromise position between your desire to get
something to market, and their desire not to continue paying the price for
that speed for the rest of their tenure at the company.

~~~
dkersten
People also like to work on things that they can be proud of and incomplete
software that ignores the edge cases often isn’t that and can be frustrating
to work on for too long.

------
rhinoceraptor
No matter how detailed the requirements you give them are, the requirements
are not software and they are not fully formalized.

The job of developing software is to take requirements and find the
inconsistencies at every level of detail. The software _is_ the design, not
the requirements.

All software teams miss deadlines, it's a natural consequence of the fact that
developing software is an exploratory process.

~~~
daveslash
This. I've heard some devs before complain that the requirements aren't
specific enough. As a dev myself, my opinion is that if the requirements were
100% clear, thorough, precise, and unambiguous, then you'd essentially have a
programming language.

If you have developers requesting that specs be 100% perfect, then you have
either (a) too junior devs who are lacking a senior mentor or (b) somehow the
devs have gotten the idea that any imperfection, misinterpretation, or bug is
going to reflect poorly on them, so they're trying to pass the buck - I see
this a lot and it's usually a systemic culture problem.

------
human20190310
Are you sure that these edge cases can be deferred without having to do a full
re-design and re-write to accommodate them later? I.e., if you do an
implementation that doesn't include the edge cases, is this implementation
something that can be used in the full solution, or are you 0% done with the
100% solution when you deliver the 80% solution?

If the edge cases arise out of contradictory or unsatisfiable requirements, it
might make more sense to refine the requirements than to defer the difficult
part of the implementation.

------
kabes
It's exactly the handling of edge cases that separates a product from a proof
of concept. If you want a proof of concept that should be made clear to the
developers. If you want a product, but there's not sufficient time, then
that's a management failure.

------
codingdave
Talk to the devs and express the concerns. Ask them to document the edge cases
as future tasks/cards/stories, whatever you call them. Prioritize as you see
fit. If you are a dev lead, work with them on different ways to approach
problems. If you are more on the product side, work with their dev lead on why
you think their approaches are not getting the results you hope for.

In short, this should be resolved by having open conversations with the team.

As a side note, do not blame devs for a project failure. If they did the work
they were handed, and the project doesn't come together, the project
leadership needs to own that. There is nothing that will trash morale on a dev
team more than leadership throwing blame downhill.

~~~
arenaninja
This is the answer.

I work on software that deals with millions of dollars daily; mistakes would
be very costly and our team spans multiple timezones. Two things my team has
going are that our lead dev understands the business case (10 years of
industry experience - not just tech), when the dev team runs into an edge case
our default is to email the interested parties (product owner, UX, QA) to say
"I ran into this edge case that isn't covered by the stated requirements;
please open a work item and prioritize accordingly". The lines of
communication between DEV/UX/QA/Product needs to be very open and judgment
free to deliver on an ongoing basis

------
jamestimmins
It's important to understand that sometimes all of the edge cases _do matter_.
So it's not a bad reflex per se, it just isn't right for this circumstance.
It's likely that they simply don't know how to make this judgement call. It
might be helpful to come up with a list of all of those edge cases, then sit
down with them and have an open discussion about what types of things matter.
Help them to develop heuristics for assessing what does and doesn't matter at
a particular phase, and then have a "known limitations" document.

This document is also helpful bc when the client or management comes to you
and says something doesn't work, you can point to this as a known and
prioritized problem.

In general, I'd say that desire to cover the edge cases is the better problem
to have. I'd rather that than developers who aren't worried about gaps and
issues.

------
contravariant
There's a pretty big difference between an application that has 80% of the
functionality and an application that fails 20% of the time.

Carving up the functionality in a way that can be implemented independently is
a delicate process and not solely the responsibility of the developers.

It's also worth keeping in mind that the easiest way to solve a (jigsaw)
puzzle is to start with the corner and edge cases.

------
matneyx
How is your organization structured in regards to dev and QA? Do your devs
feel like QA is there to help them succeed, or to catch them in their
mistakes?

I worked for a company that briefly had a "bug scoreboard," where QA were
rewarded for finding a larger quantity of bugs, regardless of quality. Typos,
weird UI things being 1px off (no joke), weird edge-case stuff like "if I load
this item into my cart in Chrome, but then change the quantity in IE, and then
try to check out in FireFox, it will say I'm not logged in..." The value was
next to nil.

As was the company's way, each bug was logged (as is good), but because the
bugs were usually found in the test environments, the devs who were actively
doing the work felt like they were being directly attacked for focusing on the
big picture and NOT the edge cases.

This ultimately lead to the QA director being demoted, once management
realized how much money was being wasted on meaningless stuff and not being
spent actually improving the site, but the damage was done -- some devs who
were working in that environment will never trust QA again.

So, to simplify my question: do your devs feel punished by missing edge cases,
or do they feel rewarded by providing functionality?

~~~
tfehring
This seems like a failure on the part of the product manager(s), not on QA.
It's not QA's job to decide whether minor bug fixes should be prioritized over
new features, or at all. And if the product manager decides that they _should_
be prioritized, either on a case-by-case basis or as part of a broader "fix
all bugs before writing new code" rule, then it's their job to take ownership
of that decision and communicate it to the team.

Also, if developers felt attacked when bugs (however minor) were reported,
that's a pretty serious cultural issue, and again it was likely driven by the
product manager's failure to actively take ownership of prioritization
decisions. It's easy (and probably more common) to end up at the opposite end
of the spectrum, where developers rightly complain about having to work with a
bug-ridden codebase because new features continually get prioritized over bug
fixes.

Bringing all of this back to the OP, I think all of this is still mostly true
for handling edge cases. Ultimately it's the product manager's job to decide
how robust the application needs to be, and to take ownership of that decision
- and to take the blame if deadlines are missed due to dealing with obscure
edge cases, or if those edge cases are ignored and come back to bite the
company in the ass later.

~~~
matneyx
I totally forgot about the PM / PO role -- probably because I've literally
never had one that did their job. I've had someone in that role, sure, but
they were either too busy trying to climb the corporate ladder to care about
their teams (and were eventually let go), were puppets for the team lead (the
lead who eventually left the company because they didn't have a PO / PM who
actually did their job, go figure), or were too busy trying to micro-manage
the dev teams (and, again, were eventually let go).

But a cultural issue is ultimately what I was trying to say, and you kinda
nailed it with the idea that cultural issues generally stem from someone not
doing their job, or trying too hard to do someone else's.

------
api_or_ipa
Look inward. The problem is likely in your company's management style. Instead
of designing a big complex thing all at once, design a truly simple MVP-- and
have your engineers involved in pruning back complex or low value features.
THEN build the product. It usually far far far harder to debug a broken system
than to build a new system from scratch. What your engineers are telling you
is to reduce your requirements, think carefully about them and to build a
stable system you can then develop on top of.

------
jbob2000
Who are these developers? Can I hire them? I am having the opposite problem.
Our business team cares TOO MUCH about the edge cases and doesn't spend any
time on the 80% work.

Tell your devs to come work in banking or finance, they'll feel totally at
home. We have 100 clients on a credit card that we sunset 10 years ago?
Equally as valid as the 2.3 million clients on the highly profitable new
credit card. GRRRRR.

------
cryptoz
This sounds like a failure in writing Acceptance Criteria for work completed
rather than the devs' fault dealing with edge cases. When you assign work,
make sure you are clear in what you want done. Left with ambiguities, many
developers may be afraid of reprimand for delivering a product with known,
intentional failures if management did not specifically request that.

------
thijsvandien
This sounds like a great problem to have. I wish more developers thought about
them sooner, to build the right kind of fundament rather than doing something
that works reasonably well for the happy path but grows incredibly ugly when
you try patching the inevitable edge cases. Perhaps it's not always needed to
actually deal with those right away, but they surely need to be considered
early on, so that it's fairly straightforward to do when the time is right.

------
abrichr
1) Explain the concept of a Minimum Viable Product
([https://en.wikipedia.org/wiki/Minimum_viable_product](https://en.wikipedia.org/wiki/Minimum_viable_product)).
The only way developers get paid is if the business makes money, and the
business only makes money by shipping working product ASAP.

2) Define invariants at the top of functions using assertions
([https://en.wikipedia.org/wiki/Assertion_(software_developmen...](https://en.wikipedia.org/wiki/Assertion_\(software_development\))).
Make this a requirement in your style guide, and always do code reviews. Think
of this like the MVP of handling edge cases in code, e.g.

    
    
        def foo(bar):
            assert 0 < bar < 1, (
                "bar must be between 0 and 1"
            )
            # TODO: handle bar <= 0 and bar >= 1
            ...
    

3) Use Test Driven Development ([https://en.wikipedia.org/wiki/Test-
driven_development](https://en.wikipedia.org/wiki/Test-driven_development)) to
define the minimum required functionality. Write the high level integration
tests, then give them to the developers to implement against.

4) Reward success periodically by looking at how many tests each developer got
passing. This could be in the form of looking at burndown charts during a
sprint retrospective
([https://en.wikipedia.org/wiki/Scrum_(software_development)](https://en.wikipedia.org/wiki/Scrum_\(software_development\))).

------
winkelwagen
Often the first step I take is just make it work, in most straightforward way.
Make sure that it is tested. When I say tested, I do not mean, write a unit
test for each permutation for each small piece of code. You don’t want to test
the implementation, but focus on the behavior, what should this code do to
make the customer happy.

If that is done, I start refactoring. I now know the problem space much
better, making it easier to do sweeping changes of interfaces, and because the
test are most focused on behavior and the interfaces, that shouldn’t require
that much work.

When i’m Happy with the design, and the basics are working. I start working on
the edge cases, and to refactor the internal implementation to something that
is focused on maintainability.

So I think your approach should be to teach your colleges to first, just make
it work.

That said, if you are a team lead, I think you should think of the psychology
of your developers. Why are they so focused on the edge cases. Does the
business blame them when it goes wrong. Are the stories over promising,
leaving little interpretation for the developers to only think about the gold
road.

If that is the case you should definitely be more involved when the features
get specified. If everyone is clear what edge cases are not involved, then it
will lift the burden of the person coding the feature.

Also, perhaps you should move the developers to projects were a more rigid
approach fits the project. I know I’m pretty terrible to hack something
together in a couple of hours. But I’m the person that works a week on it, so
it’s stable, works and tested. Different kind of developer for different kind
of projects.

Just make sure you encourage the developers to work the way you like, and to
be there when shit hits the fan because the edge case is not as edgy as they
expected.

------
chachachoney
Do the stories the developers are given specify that handling of edge cases is
not a requirement for completion of the current sprint?

------
acroback
You are a product or sales guy, aren't you?

Looks like you did not set your expectations correctly with your engineering
counterpart.

------
hrktb
I am wondering how you effectively start from the edge cases. To deal with
errors, in particular complicated ones, you need the main skeleton coded and a
central case working.

Are the 20% left (btw a fifth of stuff missing feels huge) really “edge cases”
to them ? If these are behaviors they personaly can’t accept in a shipping
product I’d totaly see devs ignoring arbitrary deadlines.

For instance I don’t think most people woud want to ship potentially data
destroying code, even with a PO on their back pestering for a release of the
rest. And a defense mechanism for that would be to cripple pieces of the main
scenario until the critical cases are covered, if they can’t otherwise
negociate that.

I am basing that on the fact that it’s a recurring event and from specific
devs.

------
acesubido
> they think of all the possibilities that go wrong and start from the edge
> cases inwards, which individually represent a small piece of functionality.

> I would rather they deliver a working chunk and just log.error when missing
> information is present.

Another way to look at this: they might be "afraid" of doing log.error and
thus trying to overpolish; it could be a symptom of a lack in internal
alignment on how to support a customer or meet customer expectations when the
code hits that log.error line.

Sounds like a scoping problem.

------
sethammons
If you have several problems, I'm a proponent of solving the hardest ones
first so you know you can actually solve them. Imagine building something over
a long haul, and putting off the really hard problem to show "progress," but
when you get to the hard problem, it turns out your can't solve it the way
you've built your system. Now you get to tear it all down and start again.
This could be what your devs are doing by looking at edge cases more heavily.

------
tyagis
I am curious to know who you are in the context of having an opinion about
these "handful of developers"? Engineering/Project/Product manager? CTO?

------
Jtsummers
You need to prioritize the work and make sure it's worked in the desired
priority order. If these edge cases are things they discovered while
developing the primary work, they need to queue it up in the backlog and
figure out the right priority, not run down a rabbit hole. If these "edge
cases" are known up front, you should have given them priorities and if they
aren't important, they shouldn't even have started on them.

------
postit
My company was having the same issue when I joined a couple of years ago.
Endless design documents, RFCs, meetings, polishing corner cases.

I pushed the teams implement user story mappings for each project and cut the
fat to delivery it on time. The argument with the developers was basically
around: "I know you want to plan ahead and put shine things on your resume,
you can do that if you get the following 3 releases on first."

~~~
peteradio
And then after 3 releases did you laugh in their faces for believing you?

------
Railsify
1\. Don't hold them responsible when edge cases they were supposed to ignore
cause downtime or headaches 2\. Hold the business leaders responsible for
failure to identify and document edge cases early enough in the process to
include it in the dev plan

------
larrik
I would press the point that you really want an MVP first that works with
perfect input, and then iterate after that. The term "MVP" _should_ articulate
your point better than a lot other things you could say.

------
imtringued
Hire lower quality devs.

------
captainredbeard
You have it backwards!

