Why does it take so long to write software?
I am asked this question from time to time. Then it follows a statement offering an example on how some other company manages to do the same code in much less time.
There are many reasons that could justify taking longer to write code but, on this occasion, I would like to focus on a specific case… Non-Functional Requirements a.k.a. NFRs.
NFRs are the kind of things that are present but invisible to the end user. For instance, on your banking website where you see your latest transactions, you see a simple table with rows and columns, a logo, some other buttons, etc. but there are many other things on that same page that you cannot see, they are there, but you do not see them.
One of those things that you cannot see is, for instance, the security of the page, you don’t want your data to be compromised, you don't want your data to be modified by a third party, you don’t want your data stolen. The list goes on and on.
If that page of transactions was just a table with rows and columns, anyone could make it in just an hour, very cheap, almost anyone with some basic HTML/JavaScript knowledge could do it. Here is where you need to value what is the impact on your business, you need to estimate the cost of having that data lost or stolen. The cost of customer complaints, the loss of credibility and potential regulatory fines....
Security does not happen magically, achieving security is done by writing lines of codes, you cannot see them, but they are there, and this is how that simple table with rows and columns is no longer just a simple table with rows and columns. Secure code takes longer to write since you are not writing only lines of codes to show a simple table with rows and columns, on top of that you are writing code to make that page secure.
Writing code that is secure not only takes longer, but it also requires people that have acquired some specific knowledge on secure coding. By now you should be realising that not almost anyone with some basic HTML/JavaScript knowledge can create that table with some rows and columns and at the same time make it secure. Now you need people that have gone through an often extensive and expensive learning process, and this increases the cost of people.
This is about security, but the same applies to other NFRs such as Robustness, Performance, Scalability, Availability, Reliability, Recoverability, Maintainability, Serviceability, Manageability, Traceability, Usability, Data Integrity, Compliance, Delivery, Reporting, Monitoring, Disaster Recovery...
Hiring people that know these NFRs and how to use them has a cost. Are you in a business for the long run or something quick that only needs to be out for a short period of time? That may define how much you want to spend on NFRs.
You need to wonder how much your business relies on all those NFRs… Do you run a business where your site is seen by a few hundred people all located in the same city and you don’t depend on this to sell your products or are you serving a website to hundreds of thousands of people, in many countries across the globe and this is your only way of making money? How much revenue do you lose if the site goes down for one hour? Or one minute? Or one second? Do you depend on investors trusting your site is not going down or losing data?
When I talk about this subject, I often hear someone saying that there has to be a balance, that we cannot spend too much time on having the perfect NFRs, that we need to cut some corners to take products to market before our competitors do. I agree there has to be a balance, but not at the expense of quality. If you want to get a product faster to market, there are other things you should be doing to take your product out in increments, in faster iterations to reduce the Cost of Delay (I will speak of this in a different article) and beat your competitors.
There is a lot to learn when it comes to NFRs, how to implement them, how to measure them, how to maintain them. It is a long and exiting learning that you need when you are on a fast and competive market.
Very well said Miguel! Great article!
Great article! Thanks for sharing your thoughts on this Miguel, this really reminded me how much I’ve learned from you!
Vague requirements usually