Laser focus on only happy-path implementations
Posted by karacic@reddit | ExperiencedDevs | View on Reddit | 67 comments
It seems to be very hard to get buy-in from the management or oftentimes from other devs to handle all the edge cases once the happy path implementation of a feature is live. There always seems to be a rush get an MVP of a feature out of the door, and most edge cases are logged as tickets but usually end up in tech debt because of the rush to ship out an MVP of the next feature.
The tech debt gets handled either if you insist on doing it - and then risk a negative review for not following the PM orders. Or when enough of users complain about it. But then the atmosphere is like it's the developers fault for not covering the tech debt before the feature is released.
I guess this is mostly me venting about the endless problem of tech debt but I would like to hear if anyone else has similar experiences and how they're dealing with it.
danielt1263@reddit
It feels wrong to call such lack of work "tech debt". It's more like "use-case debt" or "design debt"...
I recently had a situation where management asked "what happens if this fails?" my response was "I didn't get a design for that possibility." The acceptance criteria for the use-case were met and that's where my responsibility ends.
Obviously, when I see an edge-case that design missed, I will point it out, but if I miss it too, or design/management refuses to allocate time to handle the edge-case, that's not on me.
mackstann@reddit
I think the issues are a bit adjacent to the stated problem.
This sounds like a toxic culture, and of course it is leading to bad outcomes. The problem generally starts at top. Engineering leadership or maybe company leadership. The fix, from an IC's perspective, is to figure out how to cope with the dysfunction better, or find a less dysfunctional company to work for.
thefool-0@reddit
You need to play a bit of a game where you push back delivering the feature so you can make sure there is sufficient error handling, completeness, test coverage, but not by too much. You need to slowly, over time, shift the mindset and culture of your organization to accept that building things correctly is in fact worth it, but that you're not going too far that it slows down development too much. Or, they just need to learn the hard way by having angry calls from customers about things being broken... and maybe even threat of financial or legal consequences. (And they need to see the angry grumbling of engineering staff scrambling to fix it over a weekend or whatever.)
auchjemand@reddit
The V in MVP stands for viable. A product focusing only on the happy path usually is not viable.
cfogrady@reddit
That's not tech debt, those are bugs waiting to be unleashed. Tech debt is almost exclusively non-user facing. Like business logic is duplicated in 5 locations and needs to be refactored into a consolidated function call. Or the API requires multiple calls, but could be consolidated down to one to reduce chance of missing a step in future developments.
If these are user facing issues, you should file them in your ticket system as bugs. Sometimes edge case bugs will still get ignored by management because they are so unlikely that unless you are big tech scale they will probably never happen.
And sometimes bugs with workarounds will be ignored with workaround instructions given to support, but if they are truly ignoring bugs that negatively impact user experience then they either misunderstand the software development lifecycle or things aren't properly being communicated. If the latter, I'd think about jumping ship. If the former, it's time to have some reflection on how things can be better communicated.
thesauceisoptional@reddit
I try to build the sad paths first, on the way to implementing the happy path. TDD practices help (even if not exhaustively employed), and can garner management support for their use in preventing regression in critical code. (They also act as preemptive gates, when employed directly in your build pipeline--you do have a pipeline with automated builds and unit testing, don't you?)
pydry@reddit
The problem with doing this is that it takes 3-5x as long and if the feature ends up not being used *at all* then that is a waste.
Even features that do get used often get substantially reworked before they get used heavily.
Drited@reddit
I would be curious to hear whether or not this problem is alleviated by AI to any degree in your experience?
SituationSoap@reddit
It's not and the fact that you're asking this question means you're on the wrong sub.
Drited@reddit
Ignoring the ad hominem, for the avoidance of doubt, you're saying it's not alleviated to any degree? That was the specific question.
SituationSoap@reddit
It's not an ad hominem. It's me pointing out that if you are asking this question you are not experienced enough to be posting here. This is a sub that's explicitly for people who have several years of professional experience explicitly so that we don't have to answer questions exactly like this one.
AI alleviates the problem to the exact same amount as an automatic transmission in a Toyota alleviates this problem. It's entirely unrelated to the question at hand.
The fact that you can't understand this even when someone tells you it directly is exactly why we don't want these kinds of questions in this sub. Go away.
Drited@reddit
I think your emotional reaction has made you misinterpret which part of the problem I was asking if AI could alleviate. It seems to me that you've jumped to the conclusion that I was asking if it could help with finding sad paths first. However I was reponding to pydry who in term responded to thesauceisoptional. thesauceisoptional said that test-driven development practicies help. pydry responded that the problem with implemention of his solution (finding sad paths and using TDD practices which help) was that it takes 3-5x as long to do that.
I asked pydry (not you or the OP of this submission) if AI could help with that problem. While I could understand if you had this reaction regarding a suggestion to do this to find sad paths, that's not what I was asking. I was actually thinking about AI helping on the TDD side which was part of the solution that pydry mentioned can take a long time to implement.
If I'm wrong that this was a misinterpretation and you and the other people who downvoted my comment were indeed suggesting that AI can't help with TDD, that would be very interesting to me. It would suggest the presence of a blind-spot among experienced developers given that helping to test and debug code is one of the selling points of latest tools such as Claude Code: https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview#test-and-debug-your-code
However I think you just misinterpreted which part of the problem I was asking about.
oupablo@reddit
I agree depending on the definition of "edge cases". I've seen some places define "edge cases" to mean anything off the happy path, like calling an API and not handling an error in the response or building an API and assuming the database won't ever return empty or throw an error. I think logging a ticket for a rare scenario that COULD happen but is generally just going to result in some kind of generic error now is fine. I do not think it's ok to default to a generic error, i.e. throwing a 500 on everything, for a lot of standard error scenarios like bad input or not found.
thesauceisoptional@reddit
Well, I generally don't TDD anything but the critical parts when times, budgets, or perspectives are tight. But, I try to use fail-fast and fail-safe practices jointly when building without TDD. So, yeah, nothing wrong with OP's approach. I also don't religiously apply TDD everywhere; just where it seems "public" interfacing would be likely.
hippydipster@reddit
SPDD - sad path driven design
Blecki@reddit
If the users never actually encounter the sad path, is it sad?
Ch3t@reddit
I used to be much more conscientious. MBAs with no understanding of software engineering have mostly burned that out of me. You have to learn to only care if it affects you. Will that edge case make you to do work on your on-call weekend? Will it get you called in the middle of the night? Will it cause you to work after 5 PM? If the answer is yes to any of those, then push to fix it before release. If no, then it's not your problem. I've found you will get far more recognition for fixing a bug found in production than you will for building a system that runs for years with no problems and everyone forgets it's even there.
SuaveJava@reddit
In my experience, this means you have to care about all the edge cases, as you should. Companies are increasingly firing engineers who let bugs into production. Yes, you'll get recognition once the issue is fixed, but you'll be gone soon.
SituationSoap@reddit
No they aren't.
etcre@reddit
Lol companies are firing engineers who don't ship garbage when they're told to. Customer experience once paid for be damned.
caboosetp@reddit
I agree.
This is the big CYA that protects devs from this, and it looks like OP has themselves covered. Once and issue is identified and logged, it's on management and product to determine if the value is worth the time. Most (good) business aren't firing devs for not doing something that was deprioritized by someone else. If anything, listening to management on these cases is seen as good.
Yes, people get fired for repeat bugs in prod, but there's a huuuge difference between not doing work on identified cases and taking down prod because you're bad at coding.
etcre@reddit
It's this "fix it in production" mentality that has me on a job search.
stdmemswap@reddit
This.
I would even say, before anything gets shoved down as OP responsibility, inform the stakeholders (PM, boss, whoever is doing the cut corners) the risk.
Working after 5 PM? on-call on weekend? Noone should break their back alone for the mistake done by the rest of the company.
LogicRaven_@reddit
You wrote nothing about the business context.
For a startup trying to find product-market fit, focusing only a happy path makes sense. If PMF is not found, then the company will go bankrupt and edge cases will not matter.
The atmosphere shouldn't blame it on devs though.
You could try listing the technical debt not fixed for the release decision for visibility. So it's clear the org is going for the launch with acknowledging the missing things.
Conscious_Support176@reddit
This sounds false. Trying to find a market, you focus on what features bring the must value. Happy path implementations have support costs outside of the happy path. Laser focus on happy path implementations probably means managers are blame their staff instead of accepting responsibility for cost of technical debt.
Ratslayer1@reddit
I think you're talking about different things. Of course a startup's product needs to be polished to some degree (and there's a lot of discourse in startup circles about that, from the exact definition of MVP to concepts like minimum lovable product, etc). At the same time, a startup running out of cash needs to run many experiments and try different things out. Not all of these will reach (all) end users and hence don't need the same level of quality as the homescreen of your app. If early results of the experiment are promising, you can invest more to handle edge cases etc.
drake-dev@reddit
Your product will not work as expected always, you need to control for some sad paths.
If I’m trying out a new app from a startup and crashes or blank screens from an error, it’s a no from me. Doesn’t have to be every case has its own solution, but basic errors handling is part of (any sane person’s) MVP.
severoon@reddit
Developers need to discover the power of the superticket!
It is true that a lot of small, independent rough edges are not each important on their own, and it's hard to lose sight of the bigger picture if you get mired in playing whack-a-mole with these.
However, step back and take a user-centric view. Identify a core use case and walk through it with an eye toward those little speed bumps. If you can wade through all of those little bits and organize them by their cumulative effect on individual important use cases, you can create a burndown list (or a superticket that is a collection of other tickets, and only can be closed when all of the tickets it references are closed).
This is how you demonstrate the impact of this work. You set out to build a 65 mph interstate highway that actually supports traffic at 80 mph, and you ended up building a road that's full of little problems and the traffic only does 45 or 50 mph as a result. Fixing any one pothole or whatever isn't going to change anything, but if you undertake a project to get everything up to code, then the cars will gradually speed up until they find themselves on that interstate you set out to build.
You may need to instrument the code as you go. Add instrumentation that records the problems, close a superticket, compare the new metrics to the old. The important thing is to make sure the work here is focused on not just fixing random potholes and other issues all along the road. You need to make sure that everyone descends on a particular stretch and fixes everything that brings that stretch up to snuff. Otherwise, you can't have any demonstrable impact until this massive tide rises and gradually lifts all boats.
AceHighFlush@reddit
It's a cashflow issue OR a common problem of today; leadership is looking for an exit. They need growth at all costs.
So if you are looking to sell in 2-3 years. You do all you can to pump the numbers. Why do you care if there is lots of technical debt that must be paid in 5 years if you're out in 3 years? But you also got a higher valuation because of the happy path profits?
Address this issue, and things will change. Start by having shared ownership with all employees rather (lol, yeah, right).
karacic@reddit (OP)
And there is also the case of feature work (significantly) slowing down if you're pushing fast-and-loose unmaintainable code onto unmaintainable code. The levels of spaghetti code in some places is insane.
AceHighFlush@reddit
They don't care. Too many companies have gone under during a prolonged feature freeze to refactor.
You have to speak their language and talk numbers. Like if we rebuilt X it would take Y time and have an ROI in Z days where more feature would be created than before. Z needs to be a low number.
If you owned the company and had to priprtize profit above all else, what would you want to see?
fuckoholic@reddit
Many more died from tech debt.
djnattyp@reddit
The problem is - they got to that point of needing a feature freeze to refactor by being run by short term MBAs chasing dollar signs and teams being shitty short term feature factories.
This is like complaining that lots of people have died while undergoing dental surgery, so don't go to the dentist.
And your boss is telling you you don't have time to brush your teeth.
DreadSocialistOrwell@reddit
This has been the common problem of tech since the dotcom days. Founders and VCs are looking for the exit. If they are able to gain a high valuation or IPO, they're looking for that transfer of wealth from the shareholders to their pockets.
This isn't all startups or companies, there are passionate founders who care and want to be involved in the company. But that doesn't mean they're not concerned about the bottom line and getting the numbers into the black and attaining cashflow positive status.
ninetofivedev@reddit
Can you blame them? Especially in the B2B world. Most startups aren’t novel ideas. They’re building a better mouse trap. Ie, for too long has that 1980s platform dominated the industry. If we just made the same product but with a modern UX, we could carve out a nice slice.
So they do that and it’s all about pleasing your early, big customers.
——
I think as software engineers, we want to feel like our work is more important than it really is. I doubt companies are actually “laser focused” on only happy path. It’s rather that there are often infinite edge cases and rather than sit around all day and come up with problems that we may or may not have, it’s just more enticing to ship based off what we knows
ideamotor@reddit
What i’ve seen is deliberately not understanding the information architecture due to ego. So the engineers know and expect a “sad path” but the managers force them to push forward with a less than minimum MVP. When ultimately confronted with the expected problems it can’t be justified in fixing because it’s too difficult to deal with the complicated code that was written wrongly. An example would be missing a year of data and instead of letting users pick the year, hard coding averaging of specific years in many places.
lumenglimpse@reddit
unless you own the company, who cares
koreth@reddit
When you say "edge cases," do you mean technical edge cases (like an unexpected network glitch causing a microservice to be unreachable) or what I'll call "behavioral" edge cases (say, user-entered numbers add up to more than the expected maximum which causes a later calculation to produce a bad value)?
In my view, technical edge cases are completely up to us to identify and account for as developers. Our code should be appropriately robust against technical failures, where "appropriately" can vary depending on context. No non-developer should be expected to know about all the possible ways that infrastructure can flake out or all the places an exception can be thrown. Handling these kinds of edge cases should, I believe, just be considered part of the cost of implementing a system and we should bake it into our estimates as best we can.
Behavioral edge cases ideally ought to be identified and accounted for in the requirements, because there are often product- or business-level implications that require domain expertise to work through. Obviously developers can, and should, participate in defining requirements, and as part of that process, we can point out edge cases other people missed. Nobody can spot every edge case. But ultimately it should be the responsibility of the author of the requirements to produce a robust specification.
Notice I said "ideally," though. In practice, I've found it rarely works out that way unless you're lucky enough to have a rockstar product manager. Developers often end up having to figure out both the technical and the behavioral edge cases.
Over time I've come to believe that it boils down to different modes of thinking. Some people seem to have a knack for looking at a situation and saying, "Okay, but what if X? What if Y? What if Z?" and some people don't. The ones that have the knack are drawn to fields like law, engineering, and philosophy where constructing an artifact that can withstand hypothetical problems is core to the work.
I think this mindset can be taught to a certain extent, but part of it seems innate to me. Which means as developers, we're probably going to be stuck dealing with happy-path focus most of the time.
mint-parfait@reddit
I've noticed this too. I work somewhere that edge cases are ignored in requirements, and all of the QA have been laid off. I push back constantly while some other devs push absolute trash through. The whole thing is going to eventually explode.
Agent_03@reddit
Why does your PM or manager need to know that you're covering edge cases? Most places I've worked it's assumed that anything you deliver will work at a basic level for edge-cases (or at least degrade gracefully) and have some level of test coverage. Some level of common-sense judgement by developers is assumed as a given.
Letting non-technical folks dictate and micro-manage basic technical quality is setting you up for failure. It's none of their business, as long as this doesn't go overboard and bloat out timelines excessively.
If you're having to ask for buy-in to follow common-sense assumptions about quality, then you've already lost the battle. The way to win is to have those decisions be addressed as part of implementation and code review. The more stakeholders push back on addressing tech debt (and the harder your job gets to do effectively as a result), the more you hide cleanup work in your normal story implementation. Bake that time into all your team's estimates. Tell them it's technical debt causing slowdowns... this will also incentivize them to care about that.
Unless it's a case where you're a super early startup and your business will die if MVPs aren't shipped ASAP, toxic short-sighted management deserves less than transparent development practices.
dudeaciously@reddit
I am in four meetings today because of edge cases and negative cases. Killer.
Users don't appreciate the 95% of time things work great. They complain forever about the problem.
It sounds like an environment lacking trust. Then introduce formality. What you are describing is not tech debt, it is either bugs in stated requirements, or gaps, in requirements gathering. That is how they should be logged. Bugs for devs. Gaps for BAs.
aaaaargZombies@reddit
This is where a good type system really makes a difference
Grundlefleck@reddit
While I agree this can improve the situation as it makes edge cases more visible, they are no silver bullet. The culture of pressure to build and ship the happy path still fights against better tools and techniques, and still wins it's share of battles. I've triaged the Elm bugs where a case statement is matched with Nothing and the UI becomes unresponsive.
I've also seen robust code in the worst languages, and the common factor is a shared mindset and culture to care about quality.
aaaaargZombies@reddit
There is deffinetly no single cause to the problem and you're right you can do something like this which is valid at the type level
I just find it gives me more oportunity to spot the various paths and ideally narrow them sooner.
improbablywronghere@reddit
What I do here is add a branching path for the unhappy path and if it is ever followed 1. Log it 2. Blow up the observability channels like “IT HAPPENED MAYBE ITS MORE COMMON THAN WE THOUGHT” 3. Manually intervene to fix it for them. I’ve found with this approach I identify when I’m right and we need to build it or they are right and they don’t really easily.
titpetric@reddit
My reasoning is, if you want to join a high standards org, those exist. I'd go as far as saying never again SCRUM. You're right and I don't think managers are aware how much of an overall cost and burnout center technical debt is. Lack of leadership and technical standards can really make a place unbearable to work at if you're at least a little bit of a self starter and want to maintain the codebase hygiene, consistency, cyclomatic sh...
Not many people know of the Joel test these days. And even if they did, technical standards are a top-down process if this is for work. Figure it's easier to change employers or resign if it's a barrier for you.
Threatening-Silence-@reddit
With Copilot there is less excuse than ever for not testing edge cases. It will write most of the tests for you.
codescout88@reddit
The key is to frame resolving tech debt as a measurable business benefit. By addressing issues like missing tests or improving our deployment process, we reduce the risk of bugs, accelerate bug fixes, and ensure smoother, more reliable releases. This means we can deliver features faster and with greater confidence, ultimately improving the user experience and reducing firefighting in the long run.
To make the case stronger, we can tie it to business-relevant KPIs. For example, once we improve our deployment processes and ensure higher availability, we can deploy more frequently without downtime or disruptions, directly impacting time-to-market. Additionally, by implementing automated tests, we can track a decrease in the number of bugs reported per week—from X bugs to Y—which translates into fewer user complaints and lower support costs.
However, it's also important to keep the cost-benefit analysis in mind. If an improvement doesn't lead to measurable gains in efficiency, performance, or reliability, it may not be worth the effort. In those cases, it's okay to prioritize other work that has a clearer business impact.
roger_ducky@reddit
When you’re in a high pressure environment like that, fighting for full coverage will fall on deaf ears. Instead, champion for acceptance testing. In other words, happy path plus user-causable errors testing. This should eliminate the perception problem from the user’s side.
If they’re okay with the service bombing out, that’s… fine. Just make sure you have ways to restarting the service automatically or have people watching it and restarting. Preferably with logs on what happened.
birdparty44@reddit
Prototypes deal with happy paths
Production apps consider sad paths from the start.
And error propagation. What might be user facing, what can be used for flow control, what can be logged remotely and silently recovered from.
I work at a startup. All a bunch of rookies, but none of them dummies. Still, their intellectual arrogance and lack of experience has them underestimating the importance of the sad paths.
prisencotech@reddit
This is why I
panic/aborton the edge cases.rob113289@reddit
I create logs or metrics or throw a specific error when an edge case is reached. This way I can point to a dashboard and say that this edge case is a significant enough impact to take care of. This way I'm not relying on users to complain about it. I can complain about it for them. Or on the contrary I will find out that it's only .00001% of traffic and not worth the time to deal with.
DragoBleaPiece_123@reddit
RemindMe! 2 weeks
RemindMeBot@reddit
I will be messaging you in 14 days on 2025-04-15 13:50:39 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) ^(delete this message to hide from others.)
No_Technician7058@reddit
We have a cultute of accepting work on a feature and baking in time to do it according to our development standards. that means designed appropriately, well tested and unhappy paths covered, docstrings and documentation created and updated, released via ci or other release tools, not monkey patched, all to the best of our abilities.
these standards arent written down, they aren't spoken about in front of management, they aren't acknowledged outside of PR reviews. Because in the past, when they were, non-devs want this work skipped.
additionally, my devs do QA and operations as well. if they ship something shitty they will have to fix it and deal with the fallout as well. they can't just throw it over the wall and have someone else deal with it.
I do allow for escape hatches if something truly needs doing quickly. however it is the developers which ultimately make that call, not non-devs. because they're the ones who are best positioned to assess if the value of not getting something done exceeds the price of getting it done the wrong way.
Overall i have found if devs are made responsible for the consequences of their own mess, they have adequate incentive to do a good job. However, I still needed to hire strong devs who could actually do the work as well.
polypolip@reddit
It's fine pushing MVP through the door, that's the point, but I don't get the resistance on going through the extra tickets that come up.
Do you work with features or epics in your ticket system? IMO the tickets with the additional use cases should have the feature assigned to them properly and so the feature should not be considered complete until all the tickets are closed. Then if you get the customer bug report you can point management to your reporting system and tell them it was deprioritized and the feature is not complete.
I agree it's a stupid game to play, and you may need to adjust it to the reality of your company, but from outside it looks like there's no clear visibility or definition of when a feature should be considered ready, and what's the difference between MVP and complete feature.
karacic@reddit (OP)
That is true. Having a "paper trail" alleviates some of the responsibility for not having a fully working feature.
polypolip@reddit
It's not even about responsibility and playing the blame game, if your company environment does that then it sucks. It's about finding the point in process which causes this.
Why are there incomplete features, if tickets are there it shouldn't be a visibility issue. Is it because if the pressure to push new feature out? Reduce the pressure or accept that customers will complain about incomplete features. There are decisions to be made at the management level. Can't eat and have the cake at the same time.
OkLettuce338@reddit
Clearly capture all the edge cases in stories or tickets in Jira and mark in the comment section why they aren’t getting done. Cya
Western_Objective209@reddit
Do you have a PO? Generally a PO has the job to ensure that the software is actually good, not just implemented. This is the common way that software companies get out of the mindset that all you should be doing is pushing out features, the PO will have you spend time on iteration and improvement which is where the real value comes from
donny02@reddit
way of the world
fdeslandes@reddit
This is asking for major problems later on. Deciding what to do with the edge cases is often what ends up driving the right architecture and design. Being asked to fix them later on, you risk realising there is no solution in the current design and you must rewrite some parts to be able to accomodate the edge case.
I guess I'm lucky to have management who will listen to the concerns about edge cases once they are explained properly, and told what is the risk of ignoring them now.
djnattyp@reddit
It's because "the industry" is no longer about engineering actual solutions, just focused on get-rich-quick schemes.
dystopiadattopia@reddit
Then they complain when bugs happen, or if it takes too long to fix them.
SegretoBaccello@reddit
It would take a full EM book to answer this question. I would advise clarifying the following things first:
- what does an unacceptable fault look like in your industry. Data loss, system unavailability are common. Rounding errors are a problem if you are a bank, not so much if you do GenAI. Bad UX is a problem if you do mobile games for kids, not so much if you are a B2B fintech.
- what does "done" mean for your PM especially with regards to test coverage.
- who is on call for L3 escalations. This person should be one of those signing the readiness of your product.
- who is estimating the effort of deliverables, what does this estimate include, and how accurate has it been.
Ultimately it's always going to be a compromise. Negotiate your willing to rush things versus your availability to be on call on weekends. Document your known issues.
Safe_Professional832@reddit
Sad path should be covered by a simple catch-all handler that is easy and fast to implement. Sad path doesn't have to mean edge cases, and vice versa. Technical debt is technical debt, work according to priority. Ability to prioritize is a skill that should be learned, and confusion, analysis paralysis, overpromising, and overworking is a failure.
Standard_Act_5529@reddit
That's how it goes everywhere. You need to frame it in terms of total cost to fix it later. Also, get people to back you up in meetings (before the meetings).
End of the day, it should be a conversation and a compromise.
So many people just relegate themselves to being tools and doing exactly what they're told when they're told, without thinking how it affects their future selves.
Also, you can build metrics and review said metrics. Agree that if it hits X cases over a certain period, you look at resolving it. Or say that you're paving the way for future work (and clean up something in the process). There are a lot of ways to make what you want happen.
End of the day you don't have to hit every edge case(but you should have a way to detect if it's hot) and you sometimes have to build your case in a way that aligns it with other's goals.