5 Reasons Why You Should NOT Rewrite Your System
Published on
After many years working in your system, building, tinkering, improving, breaking and reassembling, you decide that what is really needed is a full software rewrite. After all, what can go wrong?
If you were ever involved in a full rewrite project, you know the answer. Absolutely everything can go wrong.
Why you think you want it There’s plenty of reasons for developers to advocate for a full software rewrite, but the most common is the software complexity and cost of maintenance.
There are hundreds of interview techniques, thousand of tools, each with a corresponding required knowledge to work with, countless “classic” algorithms and a myriad of different types of projects to try to evaluate a Software Developer. Yet, it is not easy to, nor formally or mathematically, separate a good Developer from a bad one. Why?
As always, there’s no easy answer to this question. The main reason for this is, perhaps, that we don’t know what a Software Developer actually does.
There sure is a lot of talk and work about estimates in software development. Whether you are in a big company, a small agency or a “one-man army” project, the idea that you can predict how long will it take to build a system is widespread and adopted by all.
Any management principle or project schedule has it as a bare minimum to operate. This is useful so you can plan in advance, and tackle the projects in a sane order, avoiding obvious trap holes and business errors.
When I started my career I quite never understood the idea of settling down with some language/technology. It always sounded wrong to do it because you have to “use the right tool for the right job” and “if it doesn’t look like a nail, don’t use a hammer”, but today I think that, as always, the reality is a bit more complex.
I still think that, as a developer, I am more capable and productive learning more and more languages/platforms/tools/frameworks/etc.