I've worked with Ovid before on a couple of projects. We've consulted for several companies before, so we've seen companies succeed and companies struggle. If you asked him for tales of bizarre project management failure, he and I would eventually get around to telling the same story.
When he wrote ditching a language, I'm sure that his experiences on one of our shared projects came to mind.
In the decade-plus we've worked together off and on, I've come to see the business reasons for making project decisions that wouldn't necessarily make sense from the purely technical viewpoint. (I also want to write great software and hate deadlines and like pure abstractions, so I see how my tendencies would frustrate business users.) You have to read Ovid's post with one question in mind: How can I identify and minimize the risk to my business if things go wrong?
Good programmers are paranoid. They catch exceptions. They check the return values of system calls. They vet and validate user input. They make their assumptions explicit and clear, and usually this serves them well when things go wrong. (Things tend to go wrong less often with good programmers.)
Good programmers should be able to understand business risks the way they do technical risks. Similarly, good businesspeople should be able to understand technical risks. Sometimes we have to put these technical/business risks in terms businesspeople will understand:
Before you approve a fullscale rewrite of your software, ask yourself if it will destroy your business.
You have to make one assumption first. If you don't believe this, there's no hope for you. You have to assume that software costs time and money to get right. If you think software is free—if you think that programming is merely transcribing a feature request described vaguely by a user—then you have no business running a project and you've already failed.
If, however, you can acknowledge that getting things right costs time and money and requires talented people who know what they're doing, then you can ask yourself several questions to figure out if rewriting software from the beginning will destroy your business:
- Why do you want to rewrite the software?
- Does it have any users?
- Is it making any money?
- Are you going to tell the users?
- If you told them, would they go away? (If you're not going to tell them, what are they going to do when they find out?)
- Why are you rewriting the code?
- If it's a mess, what makes you think it'll be any better this time?
- No, seriously. If it's a mess, what have you changed in your development process to make it better this time?
- Do you know what the existing software does? Do you have a list of features?
- Do you know which features are used? Do you know who uses them? Do you know how often they're used? Do you know which customers would leave if those features disappeared?
- Do you have a semi-objective measurement of how much duplication the existing software has?
- Do you have a semi-objective estimate of how large the replacement system will be?
- Do you have test cases for the features the new system needs to implement from the old system? How comprehensive are these test cases? Are any of them executable?
- Will the existing developers be performing the rewrite? If so, what makes you think they'll do any better this next time? (What has changed to help them do a better job?)
- If a new team will be performing the rewrite, will they have access to the original developers? (If not, are you in a position to resign? If you don't know why you should resign, how do you even have a job at all? If you think so, but you're laying off the old team, do you really think they're going to help you out without charging you an arm and a leg?)
- Will the developers have access to customers, or at least to a project manager who understands the necessary features?
- What's the timeline for the rewrite? Do you have an estimate based on the complexity of the project and the features? (It doesn't count if you say "Well we can probably shrink the SLOC by an order of magnitude, and it took two years to write, so probably two to three months.")
- How are you going to deploy the new version?
- Is there a flag day at which everyone will switch over?
- What if you find a missing feature?
- What if the new version has a bug?
- If you're hiring a new team, do they have experience with businesses like yours? Do they know customers like yours? Have they written software like this before?
- Do you have a plan for the new software missing its target date? Have you prepared to talk to customers about that? (Have you even notified them?)
- If you have customer support staff, have you prepared them for the switchover? Have you set staffing levels appropriately?
- Do you need to migrate data? How are you going to do that?
- If you need to run two systems parallel in while, which system is the primary repository of the data? How are you going to synchronize it between the two systems?
- Are you certain that you have to throw everything away and start over? Is there a grown-up somewhere in your organization with software experience who says the same thing? That there's absolutely no other option? Maybe someone who's read Working Effectively with Legacy Code?
There may be other questions, but answering these questions in detail would have helped every rewrite I've seen. There are two special cases, but the same questions apply.
What If the Code is Completely Unmaintainable?
Why is it unmaintainable? What circumstances produced that situation? Until and unless you identify and address those, you're going to spend a lot of money and time getting yourself back into the same situation. It's wasteful to throw out a working mess only to replace it with a different kind of mess.
What If I Can't Hire Developers in the Original Language?
Then you're probably not paying them enough and either your business model is broken or it will be. (Alternately, hire good developers and train them, because you're going to have to train them in your business anyway. Sure, it takes some perks to convince people to stick around to maintain a crufty codebase, but if you make it a real, actual priority to clean things up in place, you can find good people who specialize in that.)
Sometimes the right solution is to throw away everything and start over, but usually when you have customers and competitors and are making real money for your business from software, the risks of things not going 100% right are real and important.
(It's software. It's complicated. It never goes 100% right. That's why you're in this mess. Let that sink in for a while.)
