A full rebuild — how do you know it’s time? At a certain point in any software product’s lifecycle, the question has to be asked: Is it time for a full rebuild of our software? It may not be in a month or a year or 5 years… but eventually, the question has to be asked.
No software product exists in its original form indefinitely. At some point in time, a major code refactor and/or full rebuild occurred (even if the software carries the same name). It’s a daunting prospect, but one that every company has to face at some point. So, we put together a list of questions to help you evaluate whether your product’s time has come…
Now, a yes to any one of these doesn’t mean you shouldn’t necessarily kick off a full rebuild right this second. Rather, it’s a framework for thinking about your software’s lifecycle. We want you asking the right questions and understanding what the implications might be if you’re answering “yes” to too many of these.
Are you spending more time trying to keep your system running and maintained than you are building new, valuable features or improving the product? A good rule of thumb: 20% of budget time/resources should go toward maintaining a product and 80% should go to adding value to the product. If you’re not there or if your time/resource usage is inverted from that, it may be time to rebuild.