I'm a developer, not a lawyer

Many years ago, I was hired by the company Omni-Corp to work on a new brilliant product. We had a talent, a budget and cool technologies, but this project should have been a fiasco (and as a result it was canceled) in less than a year.

No one is perfect - we had our own problems, some of them were technical, some were not. One of these was the requirements management method:

The person engaged in the product could create a text document describing the new function. After several meetings and agreeing on the development of the characteristics of this function, the code began to be written. Ultimately, testers could use this text document to create test plans and test how these requirements are met.
')
It was a good process that was easy to explain (and comply with) with clear steps (Requirements -> Development -> Testing) and a clear result for each step.

Like all well-laid plans, this one did not survive the encounter with the real world.

Since the people involved in the product were “businessmen” and not “software developers”, they did not fully understand the logic of how developers understand the requirements, and since the developers were “developers”, we created our own solutions every time when faced with the "hole in the logic" of the requirements document.

Behind mistrust and chaos follows ...

We (the developers) could argue that, since this is not in the document, we had to do everything the way we thought was right - and therefore one brilliant young manager made a decision: quickly update the document five minutes before the meeting, and then poke that “It was definitely stated in the document!”.

Now we had a new problem - it was impossible to write software with constantly changing conditions, so it was necessary to invent a “freeze of requirements”.

Freezing requirements !?

As you probably already guessed, at a certain point in time the requirements document had to be blocked so that it would not be updated anymore, and, like freezing the code, it did not work. At one point, a person working on a product found that he could copy a frozen document, update it, and invoke a new version.

At this point, it became just ridiculous and unproductive - the distrust increased, as both teams felt that the other team was trying to deceive them. The development team believed that the product was trying to be put in half ready, constantly changing functions, while the working group believed that the developers were constantly trying to block everything in order to look for new reasons not to work.

Thus, each stage of the process turned into negotiations between opposing parties - I reached the point where I refused to sign the requirements until I read them several times and ask the head to re-read them and make sure that they are complete and do not contain hidden conditions.

I felt like a lawyer! There is nothing wrong with being a lawyer (a few of my best friends are lawyers), unless it is spelled out in your job duties.

And we were to blame

We (both teams) have forgotten that our job is to create software in accordance with the requirements of our consumers.

Looking back at these times, I realized something - requirements change, even in an ideal project, customers tend to change their mind, mistakes are corrected, and new data can make us look at our product from a different point of view. I worked for many companies before and after this, and more than once I met mythical projects with requirements that are 100% definitely not going to change - even the best ones in their business.

We struggled with reality - where projects can change over time. If only we had the same passion and energy trying to make sure that we could just as easily change our code.

The truth is that the code should be easily changed. Code reorganization, unit testing, code testing, and other software development techniques can help you become good, experienced software developers. This was our job - to use appropriate methods to provide our customers with new functions and fix bugs as quickly as possible - instead of complaining that the requirements are constantly changing ...

Sometimes it is very difficult to make changes to large and complex code bases. When we make changes, it is important to make sure that we make one at a time. Too often, it seems to us that we change only one thing, and as a result we inadvertently change other elements, and thereby create new bugs.

Michael Feathers - effective work with legacy code

It's pretty simple - simple code means easy to change. So make sure you do your job before trying to change the world.

Happy you (and clean) code ...