(This article is part of the Big Rewrite series.)
While we’re all in the back creating the next revision of a product, who’s tending to the day to day issues of the existing product? Typically, it’s the domain experts and the original implementers of the product.
Regardless of our intentions, day to day life and in-your-face time-sensitive issues can very easily steal all of the attention from a Big Rewrite. Screaming customers need their problems solved. Outages and serious bugs need to be fixed. Enhancements have to keep rolling in if your project takes as long as projects tend to take. Somebody has to do these things. Training new people is hard and doesn’t seem to make sense. If we’re getting rid of a system, why would we train someone how to maintain it?
So, the experts keep the old system running while the new system is being built. So, who builds the new system? Not the experts, that’s who. Usually, it’s people like me: technology experts. And while we’re banging away at the existing system’s UI, trying to figure out what needs to be coded, the domain experts are doing their jobs. Unfortunately, this means the domain experts aren’t watching the Big Rewrite very closely. Regardless of how good the team, if communication is impaired between the domain experts and the technology experts, things are going to move slowly, and wrong software is going to be created.
Sorry, comments are closed for this article.
January 4th, 2007 at 05:19 PM
Hi Chad,
Thanks for this excellent series of articles “from the trenches.”
I hope you will also lay out some best practices that you have discovered to most effectively deal with these dilemmas.
Thanks, Phil
January 4th, 2007 at 05:58 PM
Hi Phil. Thanks for the feedback. The plan is to now shift gears into the solutions next.
January 4th, 2007 at 11:57 PM
Chad,
I posted a follow up to this on my blog. I would love to hear your thoughts on what we’re proposing with d3. :-)
January 5th, 2007 at 04:45 PM
Having at one time been a trainer for a new software system for a large company, I can totally relate to your Big Rewrite series. I had to learn the business, learn the old system and the new system in a couple of months and after just a couple of weeks found the whole project to be quite illogical. We had the old developers who knew what the business needed for the last 20 years and then the new developers working on the new system who had not a clue and never talked to the old developers. The new group only cared about making it “new”. We called our old system “Premier” and it was a joke around the office that we weren’t allowed to say the “P” word. “Oh no, we can’t do it like that. Premier did that- so it must be wrong”. They threw the baby out with the bath water so to speak. The project was slated for 1 year including implementation. Yeah, 3.5 years and millions of dollars later we were finally done with the implementation. So now I do QA for the new system and I’m not worried about job security. Fun stuff.
January 15th, 2007 at 01:11 AM
Great series Chad. It inspired me to write a bit of devil’s advocacy on the subject. :)