Slashdot Mirror
Too Much Focus on the Beginning of Software Lifecycle?
rfreedman asks: "Most of the buzz on the web about software development tools, languages, and practices seems to concentrate on getting software developed as quickly as possible. Take, for example, the current huge hype about Ruby on Rails, and how it allows the creation of a CRUD web-database application x-times more quickly than every other environment. It seems to me that this concentration on initial construction of software ignores the issue of total cost of ownership. Most people who develop software also have to maintain it, and have to support changes to it over long periods of time. As has been discussed many times over the years, maintenance is the most expensive part of the software development life-cycle. I think that the software development community would be better served by discussions of how to build more robust, flexible, and maintainable software (thereby driving down TCO), than by the endless discussions that we currently see about how to build it quickly. What do you think?"
Terrible idea. Happens a lot though. Not created here syndrome doesn't help.
My personal policy is that unless the requirements change radically, or you are facing serious obselence, you should never start over from scratch.
Even if you wind up rewriting 95% of the code, you'll prevent yourself from making the same mistakes that the original developer already sorted out.
It goes something like this:
You find a chunk code that looks entirely unnecessary.
You take it out, replacing it with the obvious solution.
You run your testing stuff, it's easy since you were starting from a working system, it's all regression testing.
You often find that the code actually did do something important, something subtle usually.
You rewrite it in a better way, that accomplishes the same thing.
The alternative, starting from scratch, means that you will likely miss the subtle need for that particular thing. You don't have the benefit from starting from something that works.
It seems like it would take longer, but it goes a long way to prevent requirements and their subtle implications from falling through the cracks. You basically have a cryptic book telling you all the little tricky things. If you throw that book away then you have to rediscover them yourself. And even if you keep it, you aren't going to seriously read it in a deep way if you are starting over completely. By the time you understand all the old code fully you could have been rewriting it incrementally.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
If you take a closer look at many of the platforms that are hot right now you will notice that the concepts that give them the ability to quickly create well designed websites also make much easier to maintain these sites. With standardization and the use of modular construction, or what some call tiered programming, you have separated the logical processes and are able to change any one part without having to reinvent the entire website. When you need to rewrite the script calls to the backend, you don't have to worry about what the output of the data will look like in the front end because they are two separate processes that hand off data to their suspected components. Think of it like Cascading Style Sheets, one change to the file and all pages using that definition are changed in on fell swoop. This has a major impact on TCO when changes can be address in a single place that will impact across the whole site.
Each approach has a place in the ecosystem. Reiser4 could only have been developed the slow way, but that was because we were going into a mature market with solutions that worked already in place. We needed to architect for maintainability because we knew it was a long hard road ahead, and we weren't going to be quitting soon, so we made a plugin architecture.
The problem we have is when the grasses dis the trees and the trees dis the grasses. The Linux Kernel Community, and the rest of society, have too much of that going on.
Respect those who are nothing like you, and see that they have value to society that you cannot match but might complement.