Time for a Rewrite Part 2: 5 (Minimal) Requirements for Success
This is the second part of a short series in rewriting legacy software. To be clear, I’m not talking about creating a new cron job; these posts are about completely rewriting a complex mission critical application that is either “shipped” to customers or used internally in the enterprise.
Yesterday, I wrote about having the right motivations for a rewrite. Today, I’m going to detail the things I believe are required for actual success. It’s important to note that this list doesn’t guarantee success and that these types of projects often fail regardless. However, if you’re going to go down you might as well go down swinging!
- Do you have the right people? The importance of having the right engineers cannot be stated enough and if only one thing can be taken away from this post I hope that’s it. You’ve got to spend the money and hit the network(s) to get the best you can possibly find and recruit them to the project. I’ll leave the definition of a “good” engineer to a later post (although a Google search provides a plethora of information on this topic). I will say that it’s important that the people you find are outstanding both socially and technically as software development is a social activity. The intersection of those two qualities on a venn diagram is rather small and these people are in high demand. Expect to work for it.
If you’ve already hired the head counts you need, is your existing team motivated to do the work? Are they the type of people that energetically solve problems and are excited to take on such a big challenge? If not, reconsider your team. Seriously.
If you’re using a vendor to do the work rather than an internal development team, the same rules apply. Make sure you get to know the personalities behind the actual development work. If the vendor is offshoring the work, it’s likely you’ll experience some of the pain associated with that despite how abstracted the project manager might claim it to be. A past record of success is important in selecting a vendor, but it’s even more important to be comfortable with the current development team and imagine yourself working with them for a long period of time.
More than anything, your engineers will decide if this project succeeds or fails.
- Do you have the right process? As the Agile Manifesto states, people are more important than process. While processes known as Agile are the current trend de jour for sure, adopting some or all of them doesn’t guarantee success. For many reasons, however, Agile does help create a framework that encourages success more than most previous methods. It also helps create a system of expectations to interface with other groups and management in the company (see more below). Adopting an Agile process and doing it well will help you succeed.
- Do you have the right expectations? One of the difficulties of rewriting software versus creating something brand new is that there are explicit and implicit expectations right from the start. “It should do everything [the legacy version] can do.” You have to understand that there are likely a lot of people already used to getting things done in the old system. The UI might be atrocious, but it’s familiar.
So don’t kid yourself or the company: the new version is going to bring some pain. It will require new training and perhaps a bunch of CSRs or even customers to relearn and retool their understanding and workflow. This is the social cost, and it’s important not to underestimate it.
There are also technical hurdles such as how to stage the rollout. Do you expect to simply flip a switch one night or gradually migrate over? How will the migrating from the old database to the new database work? Beware of creating “legacy bridges” to help stage a migration as too many of these will kill your velocity.
If possible, try and freeze feature additions in the legacy platform so you have a static target of functionality to chase rather than attempting to keep up with another development effort.
Finally, give as much insight into your development process as possible. Be transparent. If you’re behind where you think you’d be, admit it. This is where adopting an Agile process can really help as it automatically sets these process and velocity expectations with the constituents and product owners.
- Do you have the right product direction? You can have a great team of engineers and a wonderful process, but still fail without a good product owner. You need someone who can understand the requirements of the legacy platform and translate them into stories. You need someone who can decide what features are necessary to get a version 1 release into the field so real iteration can start. You need a person who can shield the engineering team from any political issues that might arise. These types of people are just as important as good engineers and should be sought after with the same sense of urgency.
- Do you have the right support? Does the company fully support your effort to perform the rewrite. Attempting to do something this big without the support of (almost) everyone in the enterprise will be very difficult. You need cooperation and a certain level of forgiveness from your internal constituents. You might need help from other groups for integration efforts. You’ll likely need lots of testing help.
These types of projects in large organizations can get bogged down in political mire. Having the support of key people, especially on the C level, will help shield that from happening.
Finally, don’t be a jerk to other groups. What you’re doing may be important, but acting as if it’s more important than anything else will blow any positive capital you have. Remember that development like this is largely a social exercise. Just like in “real” life, treating people with respect will buy you a lot more in terms of help than talking down to them.