… TLDR; Almost never
I have worked with a few engineering teams and managers that expressed something like this:
Our current system is so buggy and problematic, if we could just throw the whole thing out and start over we wouldn’t have all these issues!
This sentiment expresses a common human desire for a fresh start, a do-over. Our legal system accommodates this through personal and corporate bankruptcies. For a brick and mortar business like a Salon or a Restaurant, this might take the form of moving locations or wall-to-wall demolition. Why can’t we do with this our software projects?
The answer is quite unintuitive to those who have not spent a lot of time in the Software Industry but the do-over is almost never a good idea.
The Source of the Desire to “Start fresh”
These are some rationales I have encountered for why we should throw everything out and start over:
- The engineers who started the project are no longer with the company. They didn’t know what they were doing!
- The software was written for one business model but now we are trying to support a new one.
- The system was written with old technology, nobody writes code with [fill in language/fill in framework] anymore.
- There is no test coverage on the system. We can’t make changes without everything breaking.
- We know much more about the problem now than when the original system was written.
- We have a larger budget now. Why not spend the money to get it right? (getting it right being defined as a new system)
The true source of the problem
The problem with the above sentiments is that they do not get at the root of the problem. They only point to symptoms and outcomes. The real source of the problem is often closer to home. Often the place to look is not in the software but the company culture that created the software.
Software reflects the organization and culture that created it:
- Disorganized companies create buggy, rushed software.
- Top down style management that restricts autonomy and independence results in software features that satisfy acceptance criteria but don’t advance the team’s technical capabilities.
- Teams always operating in “Crisis-mode” develop bad habits of patching things together to please their bosses while not make the long-term investment to build a sustainable system.
- An entire software team that has left the company reflects costly turn-over, poor communication between workers and management and probably low morale.
- Teams working on strict, artificial deadlines fosters burnout that ends up costing more to clean-up later.
I had a another consultant that I was working with on a large project once say to me:
How can a company create software that has no tests, documenation and breaks on every deploy? Write up a list of features, create an arbitrary deadline and force everybody to march toward that.
Your users are the key
A final reason why you should reconsider starting over:
If you have users who are deriving value from your software and you are making money from them, you have the key to fixing your current system.
In other words, the most valuable asset any software has is people using the software. A good product owner can see what the users need and how to get there from your current system. A team of talented engineers can make this happen if they can hear what their users are saying about their ouput.
The new system is coming in …..
Final point.
Once you go down the “new system” path, while your engineers are working hard on your new systems with your users are still using the old system, you will encounter this inevitable challenge: somebody has to maintain the old system.
However, you won’t have many volunteers to do that as everybody on the team wants to work on the “cool new system”. Your old system may evolve beyond the capabilities in your new system. The project for your new system will most likely fall behind schedule, over-budget and have a deliver date so far on the horizon that your users might simply abandon you for a competitor.
The good news
The positive message here is, almost any product is salvageable. No matter how bad it seems to be, it can always be worse. The key is to shake up company culture and set realistic expectations. Adding tests takes time but it is a long-term investment. Most of us don’t put money in our 401k because we want to buy a Lamborgini next year.
From a culture perspective, these values are the key:
- Trust – A company must trust their engineers are competent and adept and will make the correct long-term decisions.
- Self-organization – Engineers do best when they have influence over priorities. Learn from the best that top-down can stifle innovation.
- Focus – Focus sprints or iterations on small pieces of value rather lumping together an unrelated wish lists.
Software is Hard
I think every Software Company and Engineer should read the long for Fortune’s http://fortune.com/longform/medical-records/. I would like write an entire article about this but the general takeaway is “Software is Hard”. It is hard to get these things right.
Requirements and acceptance criteria are excellent tools for describing things. UX designs are great for sales pitches and demos. Dwight D. Eisenhower once said “In preparing for battle I have always found that plans are useless, but planning is indispensable.” In the same vein, designs, requirements and roadmaps are important but they are not working software. Users hold the key. If your engineers do not use your software themselves or know somebody who regularly uses the software, you might be in serious trouble.