I'm a developer, not a lawyer

Many years ago, Omni-Corp hired me to work on a new brilliant product. We had talent, budget and cool technology, but this project was supposed to fail (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 them was a way to manage requirements:

A person who was involved in a product could create a text document describing a new function. After several meetings and development coordination on the characteristics of this function, code began to be written. Ultimately, testers could use this text document to create test plans and verify that these requirements are met.

This was a good process, which was easy to explain (and follow) with clear steps (Requirements -> Development -> Testing) and a clear result for each step.

Like all well-laid plans, this one did not survive meetings 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 a "hole in the logic" of the requirements document.

Distrust and chaos follow ...

We (the developers) could argue that, since this is not in the document, we had to do everything as we thought was right - and therefore one brilliant young manager decided: 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 “freezing requirements”.

Freezing requirements !?

As you probably already guessed, at a certain point in time the document with the requirements should have been blocked so that it would no longer be updated, and, like code freezing, this did not work. At one point, the person involved in the product found that he could copy a frozen document, update it, and link to the new version.

At this moment, it became simply ridiculous and unproductive - distrust increased, as both teams felt that the other team was trying to trick them. The development team believed that they were trying to put the product in half ready, constantly changing functions, while the working group believed that the developers were constantly trying to block everything in order to find new reasons for themselves 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 asked my boss to re-read them and make sure that they were complete and did not contain hidden conditions.

I felt like a lawyer! There is nothing wrong with being a lawyer (some of my best friends are lawyers), as long as it is written in your job responsibilities.

And we were all to blame

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

Looking back at these times, I realized something - the requirements are changing, even in an ideal project, customers tend to change their minds, mistakes are corrected, and new data can make us look at our product from a different perspective. I worked for many companies before and after, and more than once I met mythical projects with requirements that 100% certainly will not change - even with the best in their field.

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

The truth is that code should be easy to change. 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 the appropriate techniques to provide our customers with new features and bug fixes as quickly as possible - instead of complaining that the requirements are constantly changing ...

It is sometimes very difficult to make changes to large and complex codebases. 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 are changing only one thing, and as a result, we inadvertently change other elements, and thereby create new bugs.

Michael Feathers - working efficiently with legacy code

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

Have a happy (and clean) code for you ...