The problem with software + only focusing on functional requirements
Do you consider when planning or developing a product, the amount of work focused on functional vs non functional requirements? If you don’t, you should, and here is why…
What are functional requirements?
TLDR; Features
So this is the core of your app, program, system, project, product, etc. The functionality / features that make it work, that ensure it is carrying out its intended purpose.
Arguably the features are what will make your users want to use it, and without features, your product is non-existent.
While this is true, and important, all too often I see non-functional requirements completely ignored, which you do at your peril!
What are non-functional requirements?
TLDR; Documentation, commenting, writing specs, automated testing, build automation, etc
TLDR2; Things that make your product more legible, resilient, and sustainable.
So as a developer, or a team, this is everything you do to your code base that isn’t directly related to product/project features. At this point, a nod to those of you reading that realise that functional requirements could actually only be a fraction of your total workload.
To those of you saying, “Well what else is there?”, in my experience that is a fairly common response, so don’t feel bad. Also not everyone that focuses on non-functional requirements, will do them well. If something is worth doing, it’s worth doing right, right?
Essentially anything you do to your product that isn’t related to features counts for this. Want to spend less time wrestling builds? Automate them. Want to make sure code you commit is good? Get it peer reviewed. Want to make sure the person reviewing your code can read it? Add comments, and not just any comments, consider what it does, how it does it, why it does it, etc.
The list goes on and on, and in reality sounds like an awful lot of work right? Surely there is some reason, perhaps way above your pay grade why you should be doing all this.
Why are non functional requirements important?
TLDR; Without them, your product is essentially a house of cards, waiting for a slight breeze to come and knock it all down.
Without them, you create short and long term technical debt.
We’ve all been there, locked ourselves away for a few days or weeks coding up a storm, get to the end, and realised you’ve created a monster. Now on a personal / side project this probably isn’t the end of the world, but if you are building this for a client, who is paying good money, or for your own business then chances are this is going to be a huge problem.
Businesses are probably going to want to utilise this code for reasonably anywhere between 2–10 years. Also they are probably going to want to add things to it. Fix bugs. Deploy it to different places. Hell, they may even not like your face and want someone else / another company to take it over.
When one of the above happens, and it will, at best you are going to be the one to have to get your hands dirty and make those changes, or at worst explain to someone just exactly why their product should be taken out back and shot in the face.
The aim of the game here is sustainability, and ensuring the product can be maintained by anyone vaguely familiar with the product / code with the right technical skills.
Why do they get ignored?
TLDR; ‘We don’t have time’
The #1 excuse I have heard for this is that the company / team / developer doesn’t have time. This is short sighted and dangerous, and directly impacts the sustainability and maintainability of your product. Without investing that time up front, you are in for a world of hurt further down the line. New hires will struggle, existing developers will forget what was once fresh in their minds, you will lose days or weeks doing manually what could be automated, and you are now haemorrhaging time and money that a little insight could have prevented.
Generally this is a consequence of lack of technical leadership. Lets face it, developers want to write code and solve problems. Documenting, commenting, ensuring code coverage, etc doesn’t seem very glamorous compared to smashing out that new bit of functionality the client just asked for. This is especially true of less experienced developers, who haven’t yet endured what ignoring sustainability means.
Senior developers, Technical Directors, CTO’s, Scrum Masters, Product Owners, Consultants, should all be aware of the dangers of neglecting non functional requirements. All of these roles provide more value to the team and the product when they understand how imperative these non functional requirements are.
Without these decision makers strategising or at least applying pressure, you are unlikely to attract technical talent. Without putting up a considerable bounty, no experienced developer worth their salt will want to go near you. Which means you will only be able to get the less experienced who also aren’t aware of this trap, and you are doomed to repeat yourself.
Why do software projects need to be sustainable and maintainable?
TLDR; Software is an asset, it needs to be business viable
Expectations are fairly reasonable. If you build something, you’re investing time and effort into an asset. It needs to have the potential to be modified, iterating on feedback, fixing bugs, ensuring this happens without unreasonable overhead.
Also in software teams, people come and go, but knowledge must survive. It’s no use having the majority of working knowledge of the product being in certain key people’s heads. If they leave / get hit by a bus / win the lottery, you need to ensure that information is stored and accessible. Also that information needs to be clear, concise, and where possible be written in a fashion that doesn’t assume implied understanding. If in doubt ELI5 (explain like I’m five).
Without this, you will be rebuilding your product every 1–2 years, or whenever your developer turnover means you no longer have people with enough comprehension to effectively engineer your product.
If you don’t rebuild, at some point someone is going to realise there is no way forward as is, and you could find the plug being pulled, or being out of a job.
This will also affect your reputation, especially if you are working with external development teams who have to consume your crappy API, or you find yourself constantly blocked because the system isn’t doing what it was designed to do, or falls over every time you deploy.
This all impacts cost of future development. Ignoring all those things means eventually, everything is going to grind to a halt. Even the smallest change is going to cost you an absurd amount of effort. But by diverting some focus to non functional requirements, you can keep the cost of development down forever. This is usually the biggest selling point because clients can directly correlate that to something they understand, money. “If we ignore this, you save £20,000 now, but could end up spending an extra £100,000 in the next 2 years”.
What all software projects need to be sustainable and maintainable
TLDR; Strategy
The following list are all just common sense. They aren’t nice to haves, they aren’t debatable, if you do not have these your project will fail.
It may not crash and burn, and cause the demise of the company, but a software project’s success relies on it working, allowing you to iterate on new features / fixes, and doing so in a timely manner. Also if your entire dev team left tomorrow, you would have something to ensure continuity.
- Documentation (code, deployment, platform, architecture, conventions, etc)
- Commenting (Doc comments, what, how, why, etc)
- Regularly share knowledge across team / knowledge stores
- Utilising the correct programming language / framework for the job
- Architecture / structure / design patterns
- Adherence to style guides (and perhaps force through linting)
- Automated testing (unit, E2E, etc)
- Security and performance tests
- Automated builds, CI / CD
- Peer reviewed code
- Version control (with some kind of git flow branching strategy)
- Changelog and semantic versioning
- Separation of concerns
- API spec (if applicable)
- Empathetic UX
Now to some people this might all seem obvious, but in my experience the number of companies / software teams / engineers out there who aren’t doing these fundamentals is quite frankly terrifying.
Obviously nobody is perfect, and not all projects are going to have the time or budget to handle all these things (especially if you are doing them from scratch). In those cases, explain what neglecting these things will do to the end product and their return on investment. You have then done your job in informing key stakeholders of the consequences of their decisions.
If you add these concepts to your process, raise your standards, and strive for excellence, good things will happen.
