Summary
Many developers don’t speak to users or collaborate with the business, instead they take direction from email threads and poorly written tickets. Remote, outsourced and offshore developers know this only too well. Even with better access to people, these developers would struggle to navigate organisational complexity, political decision-making, and siloed systems.
Being on the receiving end of a poorly performing development team is upsetting, particularly if you’ve tried everything to fix the situation but low throughput and poor workmanship remain. The business pays the hidden price for this; individuals least well-placed to know what’s going wrong. Unfortunately, these experiences are only too familiar.
If your software development team is struggling and it’s holding back your business, then you’ve come to the right place. We believe better software requirements can literally change the world. Developers thrive when they know what to do and can make the right decisions. Read on for some practical advice that might just change your life.
Table of Contents
Introduction
When software development works best
Why software development goes wrong
My software development is going wrong
What developers need
Better software requirements
Gathering software requirements
Writing software requirements
Reviewing software requirements
Special considerations
Remote development
Neurodiverse developers
Agile transformations
Frequently Asked Questions
About Frank
Introduction
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.
By all means, bring users and developers closer together if you can. But when you can’t, you need software requirements. It’s far from perfect, and often requirements are only a poor approximation of close collaboration and direct feedback, but you need them to bridge the monumental communication gap that exists today. Software requirements are an undisputed fact of modern software development, particularly in large corporate and enterprise settings.
Poor management
Someone needs to tell the developers what to do, otherwise certain chaos ensues. 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 software requirements for the 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
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 are heavily dependent on written requirements as their primary source of guidance. This is true, irrespective of whether you philosophically agree or not. Some folk believe modern agile practices remove the need for software requirements, but this couldn’t be further from the truth.
Developers need to k
(read more)