I’m a software developer – not a lawyer

A long time ago not that far away I’ve been hired by Uber-Corp to work on the new and shiny product. We had talent, budget and cool technology on our side, and that project was going to crash and burn (and ultimately cancelled) in less than a year.

Nobody’s perfect – we had our share of problems, some technical and some not. One of which was the way that requirements were managed:

The product guy (or gal) would create a word document describing a new feature. A few meetings would happen and when development agree on the specifics of that feature coding would begin. Lastly testers would use the word document to create test plans and validate that the requirements were met.

It was a good process, easy to explain (and follow) with clear stages (Requirements –> Development –> Testing), and clear outcome of each stage.

Like all best laid plans – this one did not survive its meet-up with the real world.

Since the product persons were “business people” and not “software developers” they did not fully understand the logical way in which developers understood the requirements and since developers were being “developers” we tended to come up with our own solutions whenever we met a “logic hole” in the requirements document.

And mistrust and chaos would follow…

We (devs) would claim that since it was not in the document we had to implement was we saw fit – and so a young bright manager came with the solution: quickly update the document five minutes before a meeting and then point it out that “it was definitely in the document!”.

Now we had a new problem – it was impossible to write software with a constantly changing requirements and so the “requirement freeze” came to be.

Requirement freeze!?

As you might have guessed at a specific point in time the requirement document would be locked and cannot be updated again, and just like code freeze – it didn’t last. Once a product guy discovered that he can make a copy of the frozen document, update it and link to it.

At his point it was just ridicules as well and counterproductive – mistrust grow as both teams felt that the other team is trying to cheat them. The development team felt that product was trying to shove half baked, constantly changing features while the product team felt as if the developers were always on the lookout for new excuses to avoid work.

And so every single stage in the process felt as negotiation between opposite sides – I got to a point where I refused to sign on requirements before reading them several times and then asking my boss to read them to make sure that they were complete and did not contain any hidden conditions.

I felt like a lawyer! There’s nothing wrong in being a lawyer (some of my best friends are lawyers) as long as it’s in your job description.

And it was all our fault

We (both teams) forgot that it was our job to create software according to the demands of our customers.

Looking back at that time I realized something – requirements change, even in a perfect project customers tend to change their minds, bugs are fixed and new data can cause us to look at our product differently. I got to work for many companies before and since and not once did I meet the mythical 100% true never changing requirements project – even with the best of the best.

We were fighting reality – where projects tend to change over time. If only we’ve used the same passion and energy to make sure that we could change our code as easily.

The truth is that it should be easy to change your code. Refactoring, unit testing, code reviews and other software development best practices can help you get there and as good, experienced software developers
it was our job to use the right practices in order to provide our customers with new features and bug fixes as quickly as possible – instead of complaining about the fact that requirements always changed…

It can be very hard to make changes in large complicated code bases. When we make changes it’s important to know that we are making them one at a time. Too often we think we are changing only one thing but instead we end up changing other things unintentionally: we end up introducing bugs.

Michael Feathers – working effectively with legacy code

It’s as simple as that – simple code equals easy to change. So make sure you’re doing your job before trying to change the world.

Happy (& clean) coding…