"Make it do what it already does." That’s a tempting and simple way to view software requirements on a rewrite project. After all, the system already exists. The question of "what should it do when…" can presumably always be answered with: "what it already does".
There are two major problems with this assumption. The first, and most disruptive, is that the programmers don’t know what questions to ask. This is especially true if the programmers weren’t the original developers of the system (most often the case on a major technology shift), but even a programmer who did the original implementation of a product won’t remember every nook, cranny, and edge case. What’s worse, with the fragile safety net of an existing implementation, programmers can easily oversimplify the interface, and assume they know the capabilities of the system. If a combination of drop-down selections results in a whole new corner of the system, how are they to know without stumbling onto it (or performing an exhaustive and expensive test cycle)?
If the software you’ve built is complex enough that it needs to be rewritten, it’s probably also so complex that it’s not discoverable in this way. This means that domain experts are going to have to be heavily involved. It means that requirements are going to need to be communicated in much the same way they are on a green-field project. And it means that, unless it’s only used as a supplement, the existing system is more a liability to the rewrite than an asset.
Optimistic programmers might think I’ve missed something important here. If you’re rewriting a system, you’ve already got the code. The code can serve as the spec, right? Probably not.
Based on my own experiences and conversations with thousands of software developers around the planet, I unscientifically conclude that almost all production software is in such bad shape that it would be nearly useless as a guide to re-implementing itself. Now take this already bad picture, and extract only those products that are big, complex, and fragile enough to need a major rewrite, and the odds of success with this approach are significantly worse.
Existing code is good for discovering algorithms—not complex, multistep processes.
Sorry, comments are closed for this article.
January 3rd, 2007 at 01:37 AM
In my experience, Johnny Developer can’t read code. That’s one of the technical reasons why he loves to rewrite code and, ironically, one of the major reasons why Software as Spec fails to work.
January 3rd, 2007 at 02:16 AM
chromatic, interesting point. JD is probably worse at writing readable code than actually reading it. I guess it’s a cycle. Still, I think the main reason Software As Spec fails is that software that does something doesn’t tend to make a good spec. As software gets more and more declarative (via DSLs and more expressive general purpose languages), it gets more and more spec-worthy, but I don’t think much of the industry is even close—-good programmer or bad.
January 8th, 2007 at 04:04 PM
Great thoughts !. The biggest problem when we consider software as spec is because of the fact that an programmer is probably not a good reader. As pointed by Weinberg in Psychology of Computer Programming that:- Programming is, among other things a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads.
But how many of us can claim that we have read programs written by Stroustrup or Gosling ? So project ends into nightmare when we have bad readers considering software as spec for the rewrite.
January 8th, 2007 at 11:59 PM
January 10th, 2007 at 06:18 PM
Mining code for the business rules that are embedded, whether to re-write the code or implement it as business rules is one of the persistent mistakes people make when rewriting components. It’s a big problem and one that generates a fair amount of debate.
January 12th, 2007 at 02:16 PM
One of the reasons why developers don’t want to read the existing code is that the code is NOT clear or is even bad. And why the code is bad ? Because if the code is clean, beautiful, does what it is expected to do then we have no need to re-write the application. The tidiness of the code depends on the experience of the developer. A newbie always has the tendency to do thing the complex way (maybe because he’s not very sure of what he does). Personally, I usually find that my code could be made better, simpler, clearer, ... with a cycle of about 6 months (that means after 6 months from the day where I wrote the code, I want to re-write it, and I know that maybe I will want to re-write it in 6 months, ...). It is my own experience at the low level (code). I suppose that at the higher level (architecture, requirement, functionality, ...) the cycle could be longer, but we all want to re-do thing when we understand it better. But the problem is we must work with the code of others (who might be not there at the time of the Rewrite). And if there is no document at all (like at my company), we have no choice. Usually, I have to read the old code to try to understand what happens. And believe me, when I read that code, I really really have a strong desire to write a new code and throw the old one away.