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!

  1. 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.

  2. 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.
  3. 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.

  4. 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.
  5. 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.

Good luck!


About johnnywey

Welcome to A Regular Expression. This blog is designed to reflect my thoughts on life, music, software design, Apple, faith, philosophy, and whatever else I can think of.

Posted on December 5, 2010, in Programming. Bookmark the permalink. 3 Comments.

  1. IMO #4 is the most critical. Actually building what you should be building is difficult, and rarely happens especially in larger organizations.

  2. This might be a topic for a future post, but there is often a third option between total rewrite and continuing to add features w/o addressing infrastructure. This is a key concept addressed in Fowler’s Refactoring book. Of course, to do this properly, the first step needs to be add tests.

    A plus to this approach is that you get the entire feature set of the legacy app, and nothing freezes, instead it evolves. But it also means you have to deal with crap code in the interim.

  3. @Joe: I wholeheartedly agree. However, sometimes refactoring in this manner isn’t possible and a complete rewrite is required. Just for some backstory, I started this small series of posts by thinking about bank systems that have been running for decades on the same platform and how often the rewrites of those systems have failed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: