3 ms·
This is exactly the case where I think starting from scratch is the most difficult to estimate. This thing we need to update is a mystery-box, right? You don't
by majormajor 4y ago
This is exactly the case where I think starting from scratch is the most difficult to estimate. This thing we need to update is a mystery-box, right? You don't know the code. You don't know all its edge cases. Tons of potential bugs could be introduced (or re-introduced) if you change it in the wrong way.
Replace-from-scratch has all the same risk of getting things wrong because of that lack of knowledge and a bunch more new-code-writing on top of it. Estimating new development often fails; estimating it in the face of business requirement uncertainty is even worse.
- WorldMaker 4y agoCan you quantify that to the management in that case? To certain styles of management focused on "always building new products" to guarantee their worth/value, they absolutely will get blinders on and believe "new products are easy and more predictable than maintenance of old products". Those blinders are hard to take off once they get into that sort of pattern. All of their processes are built around "new products". That starts to be the hammer that wants to dismantle old products because they don't do maintenance (that's someone else's problem) but they surely know how to build new products. They are the build new products group, that's what believe they do. Building new products is exciting and they can be passionate about it. I also think that's generally the wrong way to work and does plenty of harm and creates a lot of unnecessary stress on development teams caught in those cycles. But I've certainly seen plenty of management teams that do work that way in the real world and maybe don't question it enough.