Ask HN: How to get developers to care less about edge cases? | Hacker News Reader

Ask HN: How to get developers to care less about edge cases?

37 pointsexabrial41 comments

I'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.

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

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 an app handled 50% of what it's supposed to do and it's well documented what it doesn't do, but we're getting to the finish line with no workable product.

View on HN

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.

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

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.

Even if you can guarantee it isn’t life and death, edge cases also include URLs that contain ../../, users setting their username to ”NULL” or ”Robert'); DROP TABLE Students;--”, hackers skipping client-side argument validity checks, etc.

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..

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...

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/

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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?

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.

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.

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.

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.

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.

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.

1) Explain the concept of a 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...). 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) 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)).

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.

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

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

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

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.

> 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.

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.

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?

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.

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."

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

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

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.

Hire lower quality devs.

You have it backwards!

Reply on news.ycombinator.com