Just imagine yourself being the world famous painter Rembrandt van Rijn. Somebody hired you to prepare a nice painting of his company. Once you show him your almost finished painting, he requests you to remove a person and to move another one. And of course in his opinion this isn’t a big job.
Are you still there? How would you feel? Who’s the artist here? Who can decide whether something is easy or not?
We will all agree that in our daily software practice the above is happening rather often, it’s not an exception. Maybe we shouldn’t compare ourselves to Rembrandt, but to some extent software developers are artists. Out of letters they create words, with these words they create the code that delivers the requested business feature. More about this process can be read in a previous post about Business Driven Development.
Quite often a client has a “simple” change request, not realizing the impact of the change. Meanwhile disturbing the described feature generation.
Such changes very often lead to functional changes, database rebuilds, development of new test cases, new integration tests, etc. And this sooner or later leads to the delay of the project and/or a budget increase as described before.
Such things just have an impact. One layer of paint has to be dry before you can put the next one on it, at least if you want to prevent a mess.
That’s why we have implemented SCRUM, an Agile way of software development. It’s a fact of life in today’s world that clients will have to be able to change their needs on the fly. They need to be able to adjust very quickly to market changes. Time to market is key. And we understand that. But meanwhile we still want to write poetry.
Dear clients, code should be: easy to read, nicely structured and may be in contrary to poetry it should be easy to understand, code has to be self explanatory. Writing such code takes time, but it will prevent issues in the future.
Please understand this.