A few months ago I had the opportunity to rebuild the way we operate the services branch of our company. If you’re not familiar with my background I lead a team of the security consultants to help software companies reduce their overall risk in relation to hackers and data breaches by performing software security assessments.
Security Innovation is a very dynamic company, we are still relatively small (although medium to large if you compare us to other companies in the industry) and full of very, very smart individuals who can be trusted to do the right thing no matter what. So when I was tasked with making changes on how we operate on a daily, monthly, and annual basis I had two options: One. Use my Continuous Incremental Improvement model I wrote about earlier, or try something new, tear everything down and rebuild it knowing what I know now from the ground up. I chose the latter.
This was actually a difficult decision for me, I usually lean toward repairing the current solution rather than starting over. This has probably come from my years as a developer when my instincts were to start everything over and after years of feeling the pain of starting from scratch I adjusted my thinking to repair whenever possible. However, there are times when starting over is the right decision, this post, hopefully, will give you a guideline on when that’s the right decision.
hint, in software, starting over is almost never the right decision, this post is about process, or something that doesn’t have legacy users
I looked back at the process we had in place, and realized this is what we had, as the status quo since the company’s inception. We’d be doing things this way not because they were the best they could be, but rather because this is the way we always did them. This was, in turn, built from processes from our previous companies (Microsoft, Universities, etc.) that means that we didn’t really think them through in the beginning either. This was my first hint that it was a good choice to build from scratch.
The Current Process was not Actively Architected If somebody really thought about what you’re working with now, and really tried to anticipate challenges and tried to mitigate those issues early, then it’s important to keep as much of that original thought as possible. That represents hard work that can likely be applied to the next version. Don’t throw the baby out with the bathwater, as they say, in your haste to get a new process in place quickly. Don’t miss out on the wisdom of the previous architects.
If, on the other hand, things were not actively architected that may be a good sign that it’s time to do the work.
Things have really changed
Another reason I chose to start from scratch is that my team and the industry as a whole had changed significantly from when we built our model. We started over ten years ago as one of the first software security companies in the industry, we came directly out of university and industry, but largely were making the rules up as we went. Other companies over the last three or four years have sprouted up that could draw on the lessons we learned and apply them to their process. We had been so busy focusing on our technical expertise and building our business that we hadn’t reflected on a process that was working “pretty well.” If we had made those adjustments as we went along we could have applied the Continuous Incremental Improvement philosophy.
By the time we realized a change needed to be made the delta between what we had and where we wanted to be was too big and the timeframe to make the change was too small to try to make incremental changes.
I think it’s important to mention that when I say “things have really changed” I really changed. I believe that incremental improvements are better, when done in place.
You can afford to rebuild
The final point to think about when considering rebuilding something from scratch is whether or not you can actually afford to take everything offline for enough time while you rebuild your process or system from scratch. In software this means splitting the team up while one part reacts to bugs in the existing version while the next part builds the next new thing. In process improvement this means setting almost everything else aside while you focus on this completely.
It’s possible you don’t have to rebuild from the ground up, and you can make a few immediate changes that have a big impact on the process. Look for these things first; if everything fits this bill, then you may be looking at a rebuild.
Estimate how much time you think it’ll take you to rebuild your current process from the ground up, now double it because we’re naturally bad estimators (trust me, you may want to triple your estimate if you’ve never done this before). Ask yourself, do you have that much time to set aside to focus on this? If not you may find yourself sinking time and effort into a project you’ll later abandon because you’ve simply run out of time. Your current process will stay in place and you’ll have wasted the time you’ve dedicated to the new green field process.
So, when should you throw everything out and start from scratch? Only when absolutely necessary. There is certainly a time for it, and to build something unencumbered by the previous version is a great feeling, but remember you may be losing all of the bad kludgy pieces of your previous process; you’re also potentially losing all of the good stuff too. Of course, if you’re smart you’ll identify each area you want to improve and decide if you want to bring that piece of the process forward, rather than rebuilding everything.
The Current Process wasn’t Actively Architected - What you have now was built haphazardly or without a clear direction.
Things have really changed - If a lot has changed since the old process was developed it may be a good time to re-architect. The landscape may have changed, your team, your life, your goals.
You can afford to rebuild - Rebuilding takes a lot of time, double or triple what you think it will. Make sure that you have the time to undertake such an endeavor. Make sure you can finish what you’ve started.
Posted By: Joe Basirico