We start a project, without the complete specs for it (of course). We make choices based on an incomplete view of the project. The choices could be whether or not to re-use existing software, which framework to use, or whether a custom framework should be written. Of course somewhere in the middle of the project we start to receive more functionality requirements. We start to patch the software to make it work. We do it again and again. Then we start to reflect on better ways we could have done the project. Better choices that could have been made along the way. We start to wonder how long it would take to rebuild it with our knowledge and the full spec.
Have you ever been in this situation? Depending on the size of the project, it can sometimes be doable and advantageous. The trick of it is sneaking the work past your boss. They never see reducing future work, just that you’re stopping the forward progress to re-code something that was already done.
This is the coding equivalent of cutting your losses and re-investing.
I’m currently in the middle of a large project that would require so much re-tooling it would just not be possible to switch to a more suited framework or methodology. However, had someone six months ago said, ”go ahead and scrap the current design and do what is right”, it would probably be done now.
In all fairness, it seemed as though the project would be done any day now. With that in mind, what manager would approve even a partial rewrite?

Recent Comments