I've now worked with my present employer for 9½ years. In that time, I have redesigned a flagship product twice. For my previous employer, I worked there for only 1½ years and I convinced the company to redesign their flagship product. Did I make the right decisions, and were these decisions made for the right reasons?
"Uncle" Bob Martin wrote a blog article back in 2009 titled The Big Redesign In The Sky. Joel Spolsky has also written an article about this subject as far back as April 2000, which he titled Things you should never do. I'm sure there are many people who have written articles which tell us how bad it is for a company to redesign their product from scratch. These are some smart people who are writing good articles and who make very good arguments for avoiding the big redesign. I'm talking about people who write books and who get paid to attend conferences and give good talks about some very interesting and technical programming stuff. So why do I feel they have all missed something very important?
The two articles I've quoted here span 9 years, and really the message hasn't changed. Bob describes a situation where the code becomes a metaphorical ball of mud. "A big legacy wad" he calls it. This is what happens when programmers come and go, and when there is an attrition of a company's knowledge base as a result of programmers not properly transferring all of the knowledge they have about a product. It's this knowledge-loss over time that managers have always feared, and it is for this reason that we have had to endure over the years the restrictive development methodologies which emphasize the impossible to maintain, highly detailed standard of documentation which makes most programmers want to assume the fetal position at the mere suggestion of doing. Programmers generally don't like having to hold up their development work to document what they did. We generally prefer someone to simply read our code and understand what we did, because - and let's be brutally honest here - programmers are generally lazy when it comes to documentation. It's boring. It puts us to sleep even to think about, and by the time we write about how something is supposed to work in detail, we could have written the code already!!
Bob also mentions in his article the classic tortoise and hare race that occurs when two teams are working on a legacy and greenfield version of a product at the same time. It's expensive, and very difficult to decide when to phase out the older version and replace it with the newer one. It's also very risky for businesses to do so, especially when things go wrong, and I can guarantee they always well. Bob mentions that the new team are always basing their new version on the old specification as a reference in order to ensure functional requirements will be met, and it is this which triggers the race in the first place. Joel's article is very similar to Bob's, however he very correctly points out that it is very risky and expensive to start a project from scratch because of the investment a company has made in getting the product stable, with bugs fixed and a knowledge that even with all of it's faults, large chunks of valuable business logic works. Both authors telling us that writing from scratch will cost more than it may seem at first, because while the effort to create a new implementation will be quite small, the effort to get the code to the same stability as the existing code will very substantial.
So the reason I am writing this article isn't to say that these very smart guys are wrong, but to identify the missing portion of the equation. The years of experience that teaches a software developer that it is actually OK to redesign at some point, but not merely because the knowledge seems lost, or that the code base is a mess to work with.
As an employee, you owe it to your employer to do your very best work all of the time. This means not allowing the code to become a mess in the first place. When you inherit a mess, you owe it to your employer to improve the code carefully and to leave the code a little cleaner than you found it. I'm not saying that it is your job to stop working on features so you can refactor the entire code base, but it is very professional to do a little extra to tidy things up as you go along. You need to do this before you ever decide to redesign a product, because without doing so you will never be able to understand the value of the code you have before you, and it's as Joel mentions, you can make some pretty huge architectural changes without having to throw everything away. When the code base is clean enough, and the system is stable enough, you will find your team suddenly with more time on it's collective hands to do other work. Those 60-hour weeks that you shouldn't have been working will shrink, and you will be able to get more done in a shorter time, simply by having a nice clean platform to work in, and all within the existing code base once it has had the Cinderella treatment.. When you have reached this point, you then get to decide what it is best to do. Should you rewrite, or does the code now have the legs to continue? Is your investment to date enough to justify continuing, or is it time to invest in something new. More importantly, what should be the deciding factor that encourages you to begin that green field project you always dreamed about?
As I mentioned earlier, I have redesigned flagship products 3 times over the last 11 years. In the first case with my previous employer, the product was poorly written and had terrible maintenance overheads. It was horrible to work in and the knee-jerk reaction could have been applied to redesign so I wouldn't need to work in such a mess. The reality however was that the product was being developed with the wrong platform in mind. The product could not scale to meet the demands of the customers, and was missing some key technologies, including the ability to share data across networks. Everything needed to change, and yet all of the math was sound. The company knew it would need something new, but couldn't afford to abandon the old product entirely. I was called in to evaluate the choice to redesign, and implemented an N-Tier product that was modular, and has continued to scale even to this day. I'm rather proud of that little piece of re-engineering, and it only took me 6 months to implement a complete replacement for the old software, because I kept the important bits that had the value of time and maintenance invested in them.
With my present employer, the technology requirements also needed to change over time. The first rewrite was required in order to provide better support for multiple target platforms, and again to allow the product to scale. The second rewrite was because the entire platform was wrong for all of the future business that the company was targeting, and because the problems that needed to be solved were new problems that had never been thought of previously. Do you see a theme developing here? Yes, you've probably guessed it.
The two articles I've quoted here span 9 years, and really the message hasn't changed. Bob describes a situation where the code becomes a metaphorical ball of mud. "A big legacy wad" he calls it. This is what happens when programmers come and go, and when there is an attrition of a company's knowledge base as a result of programmers not properly transferring all of the knowledge they have about a product. It's this knowledge-loss over time that managers have always feared, and it is for this reason that we have had to endure over the years the restrictive development methodologies which emphasize the impossible to maintain, highly detailed standard of documentation which makes most programmers want to assume the fetal position at the mere suggestion of doing. Programmers generally don't like having to hold up their development work to document what they did. We generally prefer someone to simply read our code and understand what we did, because - and let's be brutally honest here - programmers are generally lazy when it comes to documentation. It's boring. It puts us to sleep even to think about, and by the time we write about how something is supposed to work in detail, we could have written the code already!!
Bob also mentions in his article the classic tortoise and hare race that occurs when two teams are working on a legacy and greenfield version of a product at the same time. It's expensive, and very difficult to decide when to phase out the older version and replace it with the newer one. It's also very risky for businesses to do so, especially when things go wrong, and I can guarantee they always well. Bob mentions that the new team are always basing their new version on the old specification as a reference in order to ensure functional requirements will be met, and it is this which triggers the race in the first place. Joel's article is very similar to Bob's, however he very correctly points out that it is very risky and expensive to start a project from scratch because of the investment a company has made in getting the product stable, with bugs fixed and a knowledge that even with all of it's faults, large chunks of valuable business logic works. Both authors telling us that writing from scratch will cost more than it may seem at first, because while the effort to create a new implementation will be quite small, the effort to get the code to the same stability as the existing code will very substantial.
So the reason I am writing this article isn't to say that these very smart guys are wrong, but to identify the missing portion of the equation. The years of experience that teaches a software developer that it is actually OK to redesign at some point, but not merely because the knowledge seems lost, or that the code base is a mess to work with.
As an employee, you owe it to your employer to do your very best work all of the time. This means not allowing the code to become a mess in the first place. When you inherit a mess, you owe it to your employer to improve the code carefully and to leave the code a little cleaner than you found it. I'm not saying that it is your job to stop working on features so you can refactor the entire code base, but it is very professional to do a little extra to tidy things up as you go along. You need to do this before you ever decide to redesign a product, because without doing so you will never be able to understand the value of the code you have before you, and it's as Joel mentions, you can make some pretty huge architectural changes without having to throw everything away. When the code base is clean enough, and the system is stable enough, you will find your team suddenly with more time on it's collective hands to do other work. Those 60-hour weeks that you shouldn't have been working will shrink, and you will be able to get more done in a shorter time, simply by having a nice clean platform to work in, and all within the existing code base once it has had the Cinderella treatment.. When you have reached this point, you then get to decide what it is best to do. Should you rewrite, or does the code now have the legs to continue? Is your investment to date enough to justify continuing, or is it time to invest in something new. More importantly, what should be the deciding factor that encourages you to begin that green field project you always dreamed about?
As I mentioned earlier, I have redesigned flagship products 3 times over the last 11 years. In the first case with my previous employer, the product was poorly written and had terrible maintenance overheads. It was horrible to work in and the knee-jerk reaction could have been applied to redesign so I wouldn't need to work in such a mess. The reality however was that the product was being developed with the wrong platform in mind. The product could not scale to meet the demands of the customers, and was missing some key technologies, including the ability to share data across networks. Everything needed to change, and yet all of the math was sound. The company knew it would need something new, but couldn't afford to abandon the old product entirely. I was called in to evaluate the choice to redesign, and implemented an N-Tier product that was modular, and has continued to scale even to this day. I'm rather proud of that little piece of re-engineering, and it only took me 6 months to implement a complete replacement for the old software, because I kept the important bits that had the value of time and maintenance invested in them.
With my present employer, the technology requirements also needed to change over time. The first rewrite was required in order to provide better support for multiple target platforms, and again to allow the product to scale. The second rewrite was because the entire platform was wrong for all of the future business that the company was targeting, and because the problems that needed to be solved were new problems that had never been thought of previously. Do you see a theme developing here? Yes, you've probably guessed it.
The only valid reason that I can see for committing to redesigning your products is when the problems they were designed to solve are no longer compatible with the product paradigm, and when the platform you are working with is no longer a viable option to solve the problems you will want to solve in the future.Note that I am not arguing for the mythical future-proof product design here. I am however suggesting that the problems you face today will not necessarily be the same in the future, and when that future time comes, you will have the wisdom of hindsight and the knowledge of the present to decide if your solutions remain viable. I am also suggesting that greenfield development is generally going to be rare, and conducted only as a strategic decision that offers the business greater value. Adhering to clean coding standards, and maintaining a highly professional attitude towards the work you do will mean that entirely new projects will become even rarer, while the effort to maintain a difficult legacy mess will hopefully give you an appreciation of the effort required to ensure that a new project doesn't end up a subsequent legacy ball of mud, so that when the time comes to embark on that green field project, you'll hopefully do a better job of it than you might have otherwise done.
No comments:
Post a Comment