Remember the following scenario: you have to develop feature X, which is the part of system Z. It works properly and your product owner gives his/her “ok” to it. But as time goes by there are new features that have to be implemented into Z, say feature Y. This feature depends on X and after you implemented it, you have to work on X again. Now you must explain your product manager and – with some bad luck – your product owner, why you have to work on a feature which was previously labeled as “done”. They might ask you why you have to touch a feature, which they thought you would never have to touch again.
The first thing that might come to their minds is to blame you, the programmer. You didn’t work clean and with too much coupling in your code. Honestly, this was the first thought I had while thinking about this context. However on second thought, I realized that systems got more and more complex. You almost never can ensure that a feature, once implemented, works until the end of time without being touched again (to be honest, you can strike the word “almost”). This shouldn’t sound like an excuse to lame programmers which haven’t learned how to decouple objects and systems. To be clear: it is still a bad sign for your codingskills when you have to change classes across the whole system when a new feature has to be implemented – but sometimes you have no other choice.
So what to answer on the question from above? There are two possibilities:
– Never, ever commit to the phrase “this feature is done” without the appendix “at the current time and with the current scope”. PM and PO won’t like to hear that but anything else is just lying.
– Option B is that your code really sucks and you made a mistake while implementing feature X. It is time to be honest: admit that you made a fault and get yourself a copy of a book about design-patterns and system-architecture.
Happy coding!
jensonjava 