Re-writing software from the ground up
There was an interesting article on Slashdot (normal warning: evil time-waster, etc) - but not interesting in my opinion for the reasons I think you might think. That is, that rewriting or refactoring is something all software developers face at some point so it should be interesting - but that's not the only thing that's interesting to me. (I'm ignoring the outsourcing and manager suggestion angles totally in this short blog entry.)
First a link to the article:
"Moving a Development Team from C++ to Java?" http://ask.slashdot.org/article.pl?sid=06/05/18/0154213
It's related to a good (old) article by Joel ...
"Things You Should Never Do, Part I" http://www.joelonsoftware.com/articles/fog0000000069.html
My Standard Statement
So what do I believe? Well my standard (simplified) answer is: Re-writing is a very bad idea for anything that is not tiny. Throwing out all your code throws out many hours of design, development, testing (developer, tester, customer), bug fixes, customer requirements, established quality, etc, etc. Refactoring all your code bit by bit is a better option - and I always say don't be afraid of change. Rewrite a 'module' at a time - the worst first. Be careful to change the architecture where necessary with scaffolding where necessary. Of course this will lead to bugs in that changed 'module' but usually that outweighs the bugs you'll get if you are changing a bad module anyway and especially if it's really unmaintainable. I usually follow that up with a link to Joel to give extra weight to the 'don't re-write' argument.
There is another minor point: in companies, it appears a lot of re-write projects can cancelled and the previous code-set get's advanced. Elsewhere they just never get finished. Of course, I have to say that, you have to be very careful this isn't the reason you don't re-write. Avoiding all risks is dangerous as well and avoiding risks is a bad reason, IMHO.
Complications in Reality
However, as it turns out the situation is a lot more complicated than never re-write. Sometimes (as maybe the Joel's Mozilla case might or might not be) it's your only option. Either the code is obsolete (language, API, machine, etc) or doesn't do what you want - not just that it isn't maintainable. I still think you should not take it lightly at all - in my experience usually it's the wrong choice. A couple of warning signs are is if it was written by someone else (or yourself a long time ago) then the effort to learn the code and structure always looks hard. That doesn't mean the effort to re-write won't be longer.
Another good reason to re-write might be if you are doing it for fun and not money. For exmaple, people critise some open-source projects for being rip-offs of other projects. But if they are doing it purely for fun then why shouldn't they re-write? Usually they learn at the same time. However, if they want to use the functionality of the program for something else and/or want to do it in the shortest time - then it may well be the wrong option.
There are other options, for example, sometimes you can develop in parallel another version. Call this a "test version" or a "feasibility study" or the "medium to long term version". You don't stop developing the current version in this model. Both are moving. Of course, this takes double the time and extra money, can leave you with two versions to maintain (especially if you get as far as customer testing). But all routes have risks. It does reduce the damage that stopping the previous version or killing the new version can have.
It appears as if this would take longer - and it probably does. But time is not the only constraint - it's especially good if you are trying to achieve a slightly different goal. Say you want a single general version (code-set) and all you have are 2 different versions, that do different things in detail and approach but are basically similar in the problem they are solving. A superset program might be impossible to achieve via merging - in fact that is very likely the bigger a problem gets. And, in this case, it does save time - eventually. In this case it's because, whilst you have two versions, if you need to need to add a feature to both then it may well be you might need to add it twice with two totally different pieces of code.
Languages are Probably Minor
Taking another point off the slashdot article, which a lot of people mentioned, you can, of course, switch languages (both fast and slowly - there are plenty of ways to patch together two languages whilst the transition happens) but the differences between languages usually don't give enough advantage on their own to produce a better program. Sometimes they lead to a new technique (e.g. OO or application specific languages) which suite the problem domain and really do lead to big advantages or they might allow use of a specific library or framework to add functionality you don't currently have. However, I digress.
Did Joel Choose the Wrong Example?
Someone (kupci) on in slashdot comments that "Joel's article seems to be the defacto standard against rewriting software, but funnily enough, I think he's been proven completely wrong, in hindsight, by the very example he used to prove his point. Think of Mozilla [mozilla.org]? Mozilla originally started from the Netscape codebase, but they got a lot of flack from folks like Joel for rewriting it. " Is this right or wrong?
Conclusion
So where am I leading with you in all these random bits?
When to re-write is a complicated question, in which a lot of questions need to be asked, thinking, looking at the exsting code, judging not just the technical merits but the requirements outside of the code (e.g. business requirements), possible other approaches (e.g. code refactoring) and investigation into the real problems with the code-set need to be looked at.
It's therefore probably too difficult for the knowledgeable slashdot readers (I'm not being sarcastic) to make a good decision because someone can't summarise all the necessary (and quite often subtle) information. Someone will say it's good and someone will say it's bad. They could be right - depending upon the situation.
This is what I find the most interesting!
First a link to the article:
"Moving a Development Team from C++ to Java?" http://ask.slashdot.org/article.pl?sid=06/05/18/0154213
It's related to a good (old) article by Joel ...
"Things You Should Never Do, Part I" http://www.joelonsoftware.com/articles/fog0000000069.html
My Standard Statement
So what do I believe? Well my standard (simplified) answer is: Re-writing is a very bad idea for anything that is not tiny. Throwing out all your code throws out many hours of design, development, testing (developer, tester, customer), bug fixes, customer requirements, established quality, etc, etc. Refactoring all your code bit by bit is a better option - and I always say don't be afraid of change. Rewrite a 'module' at a time - the worst first. Be careful to change the architecture where necessary with scaffolding where necessary. Of course this will lead to bugs in that changed 'module' but usually that outweighs the bugs you'll get if you are changing a bad module anyway and especially if it's really unmaintainable. I usually follow that up with a link to Joel to give extra weight to the 'don't re-write' argument.
There is another minor point: in companies, it appears a lot of re-write projects can cancelled and the previous code-set get's advanced. Elsewhere they just never get finished. Of course, I have to say that, you have to be very careful this isn't the reason you don't re-write. Avoiding all risks is dangerous as well and avoiding risks is a bad reason, IMHO.
Complications in Reality
However, as it turns out the situation is a lot more complicated than never re-write. Sometimes (as maybe the Joel's Mozilla case might or might not be) it's your only option. Either the code is obsolete (language, API, machine, etc) or doesn't do what you want - not just that it isn't maintainable. I still think you should not take it lightly at all - in my experience usually it's the wrong choice. A couple of warning signs are is if it was written by someone else (or yourself a long time ago) then the effort to learn the code and structure always looks hard. That doesn't mean the effort to re-write won't be longer.
Another good reason to re-write might be if you are doing it for fun and not money. For exmaple, people critise some open-source projects for being rip-offs of other projects. But if they are doing it purely for fun then why shouldn't they re-write? Usually they learn at the same time. However, if they want to use the functionality of the program for something else and/or want to do it in the shortest time - then it may well be the wrong option.
There are other options, for example, sometimes you can develop in parallel another version. Call this a "test version" or a "feasibility study" or the "medium to long term version". You don't stop developing the current version in this model. Both are moving. Of course, this takes double the time and extra money, can leave you with two versions to maintain (especially if you get as far as customer testing). But all routes have risks. It does reduce the damage that stopping the previous version or killing the new version can have.
It appears as if this would take longer - and it probably does. But time is not the only constraint - it's especially good if you are trying to achieve a slightly different goal. Say you want a single general version (code-set) and all you have are 2 different versions, that do different things in detail and approach but are basically similar in the problem they are solving. A superset program might be impossible to achieve via merging - in fact that is very likely the bigger a problem gets. And, in this case, it does save time - eventually. In this case it's because, whilst you have two versions, if you need to need to add a feature to both then it may well be you might need to add it twice with two totally different pieces of code.
Languages are Probably Minor
Taking another point off the slashdot article, which a lot of people mentioned, you can, of course, switch languages (both fast and slowly - there are plenty of ways to patch together two languages whilst the transition happens) but the differences between languages usually don't give enough advantage on their own to produce a better program. Sometimes they lead to a new technique (e.g. OO or application specific languages) which suite the problem domain and really do lead to big advantages or they might allow use of a specific library or framework to add functionality you don't currently have. However, I digress.
Did Joel Choose the Wrong Example?
Someone (kupci) on in slashdot comments that "Joel's article seems to be the defacto standard against rewriting software, but funnily enough, I think he's been proven completely wrong, in hindsight, by the very example he used to prove his point. Think of Mozilla [mozilla.org]? Mozilla originally started from the Netscape codebase, but they got a lot of flack from folks like Joel for rewriting it. " Is this right or wrong?
Conclusion
So where am I leading with you in all these random bits?
When to re-write is a complicated question, in which a lot of questions need to be asked, thinking, looking at the exsting code, judging not just the technical merits but the requirements outside of the code (e.g. business requirements), possible other approaches (e.g. code refactoring) and investigation into the real problems with the code-set need to be looked at.
It's therefore probably too difficult for the knowledgeable slashdot readers (I'm not being sarcastic) to make a good decision because someone can't summarise all the necessary (and quite often subtle) information. Someone will say it's good and someone will say it's bad. They could be right - depending upon the situation.
This is what I find the most interesting!
posted by RobZed at 9:32 pm
0 Comments:
Post a Comment
<< Home