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?"

Comments

Good point

[Duhavid]

Now, how to convince the PHB's and the bean counters?

Re:Good point

[Spectra72]

It's not like programmers just love to dive into maintaining code either you know. They're usually the ones just chomping at the bit to chuck everything and start something new and exciting to put on their resume (or blog about these days).

RAD not necessarily higher TCO

[TheSpoom]

For years I've been working with pure, vanilla PHP outside of any sort of buzzword framework. That's not to say that my code was unorganized (quite the opposite, I'm pretty anal when it comes to code clarity), just that I believed as the original poster did that MVC frameworks and the like weren't worth the time.

I've recently started experimenting with CakePHP, and it has somewhat changed my thinking on the matter.

A lot of things we tend to do, especially in web development, get repeated over and over. Data validation, SELECT statements and their JOINs, administration backends, login systems... I could go on. In my experience, it's been when I've been bored to death of doing something repetitively that errors would start to creep into my code. It's pure probability: the more you do something, the better chance you have of one of those things having something wrong with it.

RAD solutions posit a solution to this, centralizing all those repetitive things so you avoid having to type the same thing over and over, and thereby reducing the chance that there is an error in any one of those repeated things. If there's an error in the actual framework, one can fix it, ideally, in one location rather than throughout a script (though the frameworks themselves tend to be closely scrutinized to avoid any obvious issues).

I guess what I'm trying to say is that coding less can mean coding better, as long as you understand why you're coding less, and not doing it simply because you can.

Re:It's a disposable culture.

[GigsVT]

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.

Re:Justified

[humblecoder]

Actually, being first to market really isn't that big of a deal. There are tons of products which were first to market which have slided away into oblivion because they were rushed out the door. Because they were rushed, they ended up sucking the big one. Then, another company comes out with a better, more polished version of the same product and everyone forgets about the first, sucky product.

The dotcom bust is littered with companies whose business model was, "be first or else", and nobody seems to remember them.

Re:No.

[Kadin2048]

That's a great anecdote, and I don't think that you can hit that point hard enough.

If somebody came to you and said "hey, I've got this great new way to build a bridge! Instead of making up plans, we'll just start building it! We'll build it out of popsicle sticks first, and then we'll go in and add some steel beams, and toss some pavement on top of that," you'd say they were insane. Nobody does stuff like that in the real world -- yet that's exactly what a lot of poorly-managed 'agile' software projects are doing. They're getting short-term prototyping gains but at the cost of maintainability and probably stability as well.

Rather than figuring anything out ahead of time -- actually answering the hard questions like "what do we want this software to do and how do we want to do it?" they just start making something. It's like just giving some steelworkers a pile of rebar on either side of the river and telling them to build towards the center and figure the details out later.

I think one of the biggest problems in software development, and it's really endemic, is an underappreciation of the pre-development work: requirements analysis, specification development, even simple stuff like the clear division of job roles and responsibilities. If you get that stuff done, the actual coding ought to be an academic exercise, not a seat-of-the-pants experiment.

Part of the problem lies with managers who don't understand software, and just take any opportunity to compress schedules and make themselves look better, and another problem is with "programmer culture," where people think the ideal way to solve a complicated problem is just to put a half-dozen developers in a room for a weekend with a few gallons of Mountain Dew, an Amex card, and the number of the nearest Domino's Pizza. (Although to be fair, this attitude seems to be less common among developers who have SOs/families, or are used to 40-hour workweeks.)

While concentrating on "getting it out the door" may solve the problem in the short run, it's almost certainly not going to give you neat, easily-maintainable, well-documented code. And when you're looking at the long-term maintainance costs, it sometimes can be better to not have anything at all, than to have a lot of spaghetti code that somebody is just going to have to rewrite down the road, when they can't figure it all out.

Re:Justified

[msezell]

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.

Redwood Trees and Grasses

[hansreiser]

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.

Re:No.

[mcrbids]

If somebody came to you and said "hey, I've got this great new way to build a bridge! Instead of making up plans, we'll just start building it! We'll build it out of popsicle sticks first, and then we'll go in and add some steel beams, and toss some pavement on top of that," you'd say they were insane. Nobody does stuff like that in the real world -- yet that's exactly what a lot of poorly-managed 'agile' software projects are doing. They're getting short-term prototyping gains but at the cost of maintainability and probably stability as well.


A complex software project doesn't compare well to a bridge. It's more like a city. Nobody goes and says "Let's build a city!", lays out plans, prototypes and discusses what business go where.

That's just stupid; nobody does a city like that.

A bridge is a simple item, an artifact of intelligence, it's an item with almsot irreducible complexity. A city, however, is a highly complex, interactive social organism with bazillions of interactions, many of which you can't easily forsee. It has a very small level of irreducible complexity. Lots of software has much in common with this.

Cities ARE built in a "agile development" fashion. People spec out just enough to get started, to get them by for the next few months/years, slam together a some houses, and maybe a store or two. People like living there, then somebody comes along and thinks "We outta have.... a Newspaper!" and they build a building and buy paper and start writing articles and printing and all that jazz. It's a little different than software because most software has a lifespan of perhaps 10-20 years, cities have lifespans in the hundreds of years.

Changes in this city are incremental; they're small. They happen everyday. Somebody does an extension on their house. The lady down the street gives birth to a son. The corner grocery starts selling sandwiches. The empty lot down the street becomes a movie theatre. And so, the agile development model continues.

You're dead wrong - the bridge is a small, incremental example of EXACTLY how well-done agile software develops!