Understanding why software fails to meet expectations.
Stop me if you have heard this one before. An expert team of software developers spends months on an application. Analysts work to gather requirements and make tickets. Each and every feature described in a ticket is meticulously worked on. The work passes quality assurance. Someone even took the time to set up automated testing. The repository for the project is neat and tidy. Release 1.0 goes live. But it is not looking good. Users are complaining. Things are being reported as bugs that are not bugs but missing features. When feature requests do come in, most contradict the original requirements the development team worked from. Years of maintenance later and the feedback on the application gets so bad that management requests that everyone starts over from scratch. Again. All the technical details seemed to be right, so where did it all go wrong? Commonly, the issue has to do with how development interacts with the end users, the requirements and the feedback that comes after release.
In the world of software development, the user is often the butt of many jokes. From old sayings like “ID 10-T Error” to modern memes that compare them to drooling, knuckle dragging cave dwellers; the user often gets a bad rap. This sort of consideration of users, even when done in jest, is extremely detrimental to the development of an application. It makes it easy to blame the shortcomings of poor planning and requirement gathering on the user. However, if a development group finds itself in the situation described in the introduction, chances are the entire application was built without considering the perspectives of the end users. Understandably, it is difficult to even consider their perspective in the first place. No single user has a unique view that contains the entire scope of the application. You may have users that serve different roles like administrators or users with different skill sets that use the application in different ways. Only the collective of users “know” how they want to use the application, in a very abstract, fuzzy and difficult to fully grasp way.
While it seems impossible, understanding that collective and their perspectives is key to developing a product they actually want to use. Development team managers, technical analysts and other stakeholders may claim that they really know what the user wants or how the user should go about performing a task within an application. But even if they have played the same roles as the end users before, the only stakeholder that matters when deciding how an application is designed is the end user. They are the ones who are going to use it! Not the managers or analysts. Those roles are in place to negotiate between stakeholders and developers and help distill the multiple perspectives down into requirements that can be worked on. Still, those roles need to be kept in check as when there are too many layers between developers and users the entire chain of communication becomes a game of telephone. What starts as a requirement for a page to edit a record becomes a mess of different asks as each layer adds their own interpretation of what that feature means. Especially when jargon is involved, further muddying the communication by introducing terms that only one part of the chain of communication understands. Who even knows what is or is not tech jargon anymore? Having clean lines of communication between the development team and users help to build clean requirements.
I recently learned a term that describes a situation that I have seen multiple times: bike-shedding. Imagine analysts and managers coming together to start defining the work needed for a financial application. They start building out the tickets for the user facing web application because it is what they know best. They have plenty of experience between them designing user interfaces and can refer to their use of other applications to guide requirements for this one. By the end of the meeting there are a plethora of work items for the front end describing every minute detail, right down to the color that the buttons should be. For the back end, where all the logic for the application exists, they create one work item titled “Implement a financial backend.” Bike-shedding, a coin termed to describe Cyril Northcote Parkinson’s Law of Triviality [^1], happens during project planning when a disproportionate amount of attention is spent on trivial matters. Because analysts and managers are so familiar with what a front end looks and feels like, they will pour all the time and effort into requirements for it. But when it comes to the subject matter of the application and the logic behind it, chances are they know little about it and will assume that someone else has already has the knowledge needed.
This leaves a terrible imbalance on the shoulders of the developers. Whoever takes responsibility for a portion of the front end has their work spelled out for them. The developer left with a ticket titled “Implement a financial backend” now has weeks of back and forth conversations with analysts ahead of them that leads to contradictions, frustrations and ultimately a weaker end product. If we leave the developer to their own devices to gather more information on requirements, chances are they will not document their findings outside of code which leads to another gap in knowledge. Worse yet, they may even build whatever they assume a financial backend is without attempting to understand the subject matter. Good requirements come from having an understanding of the subject matter. Great requirements come from understanding the tasks and processes that end user wants to use the application for. Getting those good requirements involves reaching out to subject matter experts and distilling development requirements from their perspective. Most likely, those subject matter experts are the end users the application is being developed for. A good test to know whether or not your requirements are getting closer to what the user is expecting is to watch the language used within the work items and tickets describing those requirements. Generic, tech language ridden things like “a financial backend” become less technical and closer to the action the user is performing, like “loan share manager” or “transaction audit”. Requirements, gathered from subject matter experts and refined by the development team, are the difference between developing an application that users are quiet about rather than one they complain about.
The moment the application is in the hands of the users the feedback starts to flow. Sadly, on the development team, we usually only see the negative feedback. There will be requests to fix a bug that someone found. A need for a new feature will show up eventually, especially as the subject matter changes and evolves. Or maybe The color of the button was just the wrong shade of green. The fact of the matter is that no amount of planning will result in a perfect application that users are silent about. The planning only mitigates the feedback and keeps the scope of what needs to change reasonable. Handling feedback appropriately keeps the application from spiraling into an unrepairable state.
Users will report a bug in an application that, in truth, is a feature that was not accounted for in the original requirements. If it is truly a missing feature, it should not be handled like a bug would be with a quick, and often dirty, fix. The temptation to just whip a missing feature up as part of a hot fix release should be avoided at all costs as it will lead to compounding issues. A hasty implementation is more than likely riddled with new bugs especially if it is rushed through a quality assurance process just to get it in the hands of the user faster. A missing feature is an opportunity to better understand what users want out of an application and a reminder to look a little deeper for requirements next time a new feature request is made. The work done to implement that missing feature should be handled with care. Documentation for the feature should be added to the appropriate spaces as soon as the requirements for that feature are understood. Of course, that care will not prevent missing features from being reported in the future, but the goal is not to eliminate the missing features but to mitigate the occurrences and their effects on the development process. Actual bugs, on the other hand, still need to be handled appropriately and in a timely manner. Mistakes happen and while there is usually something to learn from them it is best not to dwell on them too long. There is also the possibility that a feature is not missing but was not implemented to behave in a way the users expected. This should be understood as a failure to gather requirements properly in the first place and should be corrected by the development team as soon as possible.
Building any application requires more than just the ability to write code. Frankly, a lot of issues plaguing development of applications these days is the abundance of focus on the technical aspect of things. Problem solving, communication, design and so many other skills are needed to take an idea and make an implementation that users want to use. Rarely do these abilities reside in one person alone. To steal a phrase common to parenting: “It takes a village.”. The end users and their perspectives are needed to build an application tailored to them. Analysts and subject matter experts are necessary when gathering and refining requirements. Listening to the feedback from the users keeps the application moving forward with features. It is not an easy task by any means, but with the right team and a well kept process, the things that often go wrong can end up going right.
I would like to thank two people who very much helped to refine my ideas and thoughts for this post. First, my wife Sam who is currently the victim of an application that is not well designed for the end user. We spent many conversations over coffee discussing the finer points of this matter and her insight as a user was beneficial. Second, my coworker and fellow senior developer, Wayne, who introduced me to the concept of bike-shedding in the midst of our own struggle to get good requirements. I often find his wisdom invaluable but only after initially rejecting it and stewing on it for a while.
[1] Kamp, Poul-Henning. “The Bikeshed email”. freebsd.dk. April 2nd, 2025. https://phk.freebsd.dk/sagas/bikeshed/