When software development works best, why it goes wrong, what to do when it is going wrong, and what developers really need from a requirement.
Software requirements are your first line of defence against wasting time and money building the wrong thing, and they’ve become a necessity ever since developers stopped speaking directly to end users and people in the business. Remote working and offshore development centres have only made this more prevalent.
What makes an effective software requirement isn’t the format or the amount of detail, it’s whether the developer can make good implementation decisions, work without blockers and deliver the intended functionality. Some developers enjoy working to clear outcomes, others do better with more explicit instructions; finding the right balance makes software requirements so difficult to do well.
When software development works best
Software development works best when developers interact directly with users, hearing about their experiences with the software and discussing what should come next. Conversations replace the need for requirements, and ideas and concepts are quickly put together and pushed out the door. Developers confidently release to real users because high-quality processes guard against adverse effects. Feedback happens in near real-time; a simple comment, under-the-breath muttering or facial expression is often enough to gauge reception. It sounds like fantasy, but commercial software really was built like this circa year 2000, and still is in many startups and small companies.
This approach works because developers know multiple technologies and can work up and down the stack, delivering entire working features themselves. Developers create database tables and stored procedures, develop middle-tier code and author front-end interfaces (often not very good ones, I admit). They may have strengths in particular technologies, but what’s most important is delivering whole solutions. Additionally, these developers converse with real-life humans, sketch out rudimentary designs, and even test finished code, a far cry from most developers today.
Why software development goes wrong
The distance between the end user and software developer is the biggest indicator of whether your software product will delight users, or be a poor proxy of misunderstood needs. The further you stray from close collaboration between users and developers, the greater the likelihood of things going wrong, and the greater the need to manage the software development process carefully. Developers not sitting with actual users, or user advocates, break the close collaboration and direct feedback loop that avoids the need for formal software requirements and software specifications in the first place.
Technical silos
Modern software development is very different from the early 2000’s. Technical complexity means developers specialise in one or two technologies or frameworks, teams are distributed globally, ‘product ownership’ and ‘user experience’ are entirely new functions, and DevOps sits outside the development team. I’m not against any of this, nor am I advocating a return to an earlier time; rather, I’m pointing out how things have changed in the software development industry.
Large corporations develop software in ways that definitively break the link between users and developers, leaving a communication gap of monumental proportions. Users and developers no longer collaborate; sometimes, they have never even spoken to one another. Remote development teams, outsourced and located offshore in supplier ‘centres of excellence’ is standard practice. The user feedback loop is broken too, needing to traverse through layers of product owners, user researchers, designers and business analysts, before ending up in ticketing systems like Atlassian Jira and Azure DevOps.
Poor management
Someone needs to tell the developers what to do, otherwise certain chaos ensues. A few will work it out for themselves; many charge ahead, producing half-baked solutions and confused code; others turn to day trading, gardening and other hobbies to fill the time. Good software developers can tolerate a measure of ambiguity in their work; many enjoy putting their skills to good use and resolving unknowns. What developers cannot do, however, is make decisions on behalf of a business that doesn’t know what it wants or navigate political environments and organisational complexity from behind their development IDE. Developers struggle to do this.
Someone, somewhere, needs to convert ideas and concepts into instructions for the software developers, but it’s hard to do well because you really need to understand the business problem you are trying to solve. Then, you must communicate effectively. Not knowing what to tell the developers isn’t an option, unless you want poorly built software, idle hands, or conversations and ideas that never become a reality. Each developer needs a prioritised work stack and sufficient work to do; large development teams with broad skill sets make this particularly tricky.
High complexity
Some software projects are more complicated than others. The risk of unexpected problems and total project failure is higher when one or more of the following are present:
- New proposition and product development
- Bespoke and custom software development
- Integration of multiple backend systems
- System rationalisation
- Retiring end-of-life technology
- Several suppliers present
- Outsourced and offshore development
- Poor quality or inexperienced developers
- Absence of critical project roles
- Operating in regulated environments
- Developing safety-critical applications
- History of failed projects and poor delivery
My software development is going wrong
You’ll attend a product demo and be either thoroughly underwhelmed at the progress made or simply furious at the sloppiness you see, or you’ll lie awake at night worrying that you don’t know what is being delivered, and when, even approximately or on a prioritised basis. These are major indicators that something is wrong with your software development process.
Regularly cancelled product demos because of overrunning development. Infrequent production releases to actual users. Production releases that go wrong; unexpected outages, data corruption and spiralling bug counts. Unhappy users when they finally get new software versions. Frustrated developers working in a team with low morale and high staff attrition. These are other indicators to look out for.
What developers need
Developers need to know what to do and be able to make the right decisions. Some developers tolerate ambiguity better than others, however they still need a clear understanding of what to do. Experienced developers in small teams with good access to users require less prescriptive requirements; junior developers in remote teams building enterprise software require more. Some folk believe modern agile practices remove the need for software requirements, but this couldn’t be further from the truth.
The further developers are away from end users and business stakeholders, the greater their reliance on written communication. Developers who work without direct, personal user feedback depend heavily on written requirements as their primary source of guidance. By all means, bring users and developers closer together, but when you can’t, you need software requirements. Software requirements are far from perfect, often only a poor approximation of close collaboration and direct feedback. Still, they are necessary to bridge the monumental communication gap that exists in modern software development. This is particularly true in large corporate and enterprise settings.
Occasionally, the exact thing to build is known but the software requirements lack detail, such as acceptance criteria, business rules, testing scenarios, and other important things. You’ll see developers becoming blocked in their work, needing conversations to iron out the details, and then waiting for system access and environments to be made available. Better software requirements, adequate time to review them as a team, and consideration for third-party dependencies are usually the solution.