Build fast, Break fast

There is nothing in this world called quick solution. If something is going to be built quick , it is going to break quick. Our experience in building good quality softwares is a good example for this... I remember first time our interaction with our then Product Manager Karin.... we discussed on a feature where the estimate given by a developer to add a new feature was given to be a couple of weeks... a similar feature done earlier in couple of days...

Big Question come to the minds of Product Owners , Project Managers and even Developers when certain thing is going to take time... but the fact is that what takes time, comes with a certain level of quality... and we have to go by the fact that something built quickly can not necessarily be the best...

On our current project we faced a scenario where the framework we use gives a quick support on building JSON components...some engineers chose to go with it easy to use , easy to build.. quick to use and quick to build.. today I took time to read through the code base and that is what makes me write this today....

We in our past projects used JSON.. the only reason that the tool was supposed to be built and delivered quickly... we used it , it worked well initially.. the moment we started using it with our actual projects it started failing badly.. eccentric characters, complex data structures, variable hierarchy more predominantly the debug and maintainability headaches...for something that we delivered in 1 month took 4 months to fix in phases...

As Project Managers... we expect our teams to develop and deliver quickly... but is that worth? Is it what you are looking at in long and short term of your roadmap? the answer is and should be NO....So next time when your developer comes to you as says that he can build something very quick for you, or your estimate says that something is going to be built very quickly answer these questions....

1. What is the proportion of Build vs Maintenance

2. Can anyone in your team build the same thing that quickly?

3. Have you seen the design and are you Happy about it?

4. if your competitor says that same thing what would be your arguments to it?

5. Can it be maintained and / or rewritten that quickly?

6. Does the work reveal good quality? or just fast work?

7. Can the developer who built it stand up and say that its one of the best maintainable code?

8. Did you choose to do it because its easy to do?

9. Did you do it because there was no other better way to do it?

10. Did you think of other best practices that lay there?

So many more... but you begin with these.... As a developer however you have other more things to think...

1. Can I fix all bugs in it if it comes to me in future, as quickly as I built it?

2. Can I revert, upgrade , roll back and commit the fixes as confidently as I built it?

3. Can the weakest developer in your Team handle the bug fixes?

4. Is it quick because its a technology benefit or it is because its a way you have done it?

5. If you are out of the project mid way , can your counterpart do the same thing with same effort and have the same feeling about it as you?

Answer it.. and you may choose to do the same or other wise.....