Slashdot Mirror
Software Dev - Why Rebuild When We Can Retool?
basic70 asks: "There seems to be a strong preference for developing new systems all the time, instead of just refactoring and improving existing ones. Why is that? Modifications such as moving to a new operating system, modifying the business logic, adding a web interface, moving to Unicode etc, shouldn't affect more than perhaps 10-20% (to grab figures at random) of a decently built software system.
I can think of two reasons myself. The first is that consulting firms make more money developing new systems, and the second that existing systems are so badly layered and modularized that any larger improvements are impossible. The second reason is scary, because that means that the modern way of building things with short lifespans is starting to make its way into the software business as well. I saw a system written in 1995 that couldn't handle the new millenium. Can't we do any better than that? The GNU suite says we can, so why is it so hard with commercial software?"
Most of the programs that are available from the GNU library are based upon the idea that a piece of software should do one thing and do it well. This is the "Unix philosophy", and it shows when using Unix-like operating systems. When taken alone, these programs exhibit a single-mindedness. However lay them side-by-side and you can see large discrepancies between seemingly identical features (e.g. the help system).
Software created for business, OTOH, necessarily need to be large and complex and single-minded. The Unix philosophy is still at work, but once the "one thing" that a piece of software does becomes more complicated than grepping text or communicating through a pipe, the applicability of the philosophy begins to waver.
So why start from scratch when software already exists? Any number of reasons:
1) Poor documentation of the old project
2) Unnecessarily difficult code in old project
3) New programmers don't know old implementation language
4) New programmers suffer from "Not created here" syndrome
5) Contractor wants to bill more hours than would be billed otherwise
Obviously it's a lot of useless work to reinvent the wheel every time a project comes along, but think of it as job security. If the only programming being done was stuff that no one ever did before, the developer profession would be filled by only a handful of folks.
Dancin Santa
So said Fred Brooks in his masterpiece on software devolpment.
There is no way to really figgure out how something should be designed without designing it wrong the first time. If you have expirence it means you can throw away parts (ie your ascii module gets thrown away for a unicode module), but the only way to get expirence is to do it wrong.
The system I'm working on now has some problems, but they are not bad overall. Surprizingly, the areas we thought would be a problem aren't so bad, while the ares we all worried (what will happen when the customer does x) turn out not to be a problem. Until software hits the real world you don't know how it will be used, and thus you don't know how it will need to be changed.
The advantage of Open Source and Free Software is that you do have the source in case you need to modify the existing system.
You do if you're developing software in-house, too. Non-extensible software is still non-extensible, and making it extensible and documenting it properly is still a large short-term expense with little tangible to show for it (however valuable it may be in the long term). Look at how much people griped while Mozilla was in rewrite-limbo for an example of the usual reaction to this.
The reason why most software isn't flexible enough to be extended easily is that it's usually easier in the short term to write non-flexible software and to document its design poorly.
In the real world, you are almost never given enough time or resources to finish a software project. Part of this is third-party influence - the nature of the market, trade show deadlines, customer deadlines if you're contracting, etc - and part of this is management that believes in short-term profit above all else.
Sometimes you're lucky enough to avoid one or both of these factors, or to be in a position where you can force software development to take as much time as it needs. Most of the time you can't.
It's hard enough getting a working, tested, and documented product to ship. Getting an extensible product on top of that is a task of Herculean magnitude.
Thus, I think that most software will continue to be difficult to adapt to new tasks.
Exceptions exist, but bear in mind that even Open Source and Free Software projects will feel some of these pressures, so they won't necessarily be immune.
Guess what? Most systems are that bad!
They don't start that way - they start with a clean, well structured design, and then they end up in maintainence mode. Guess what happens then? Yep, it all breaks down. The biggest reason for this is feature creep. We all say it won't happen, but when the end user (who pays the bills - remember programmers are overhead) says "I need X, and the fact that I don't have it is a bug", it doesn't do any good to show them a spec, they want the feature. So it gets added. When the end user says "we need this new feature in 3 days, OR ELSE", what do you do?
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
Yeah, this site is good. Thanks
"We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds."
The article: Things You Should Never Do
Modifications such as moving to a new operating system, modifying the business logic, adding a web interface, moving to Unicode etc, shouldn't affect more than perhaps 10-20% (to grab figures at random) of a decently built software system.
You assume most software is decently built. More often than not that's not the case. Many existing systems are not flexible enough to withstand modifications.
This also assumes the the existing system is documented, and therefore the programmers can figure out which part does what, how it will affect the rest of the system, and why things were written the way they are. Once again, this is also not the case. If there are docs, they are almost always out of date.
When faced with such a mess as this, it's often just easier to rebuild from scratch.
I can spell. I just can't type.