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

It's a disposable culture.

[aussersterne]

Maintenance? If you can lower the cost of creation enough, it's cheaper to just start from scratch every couple of years. It's the same phenomenon seen in blenders and automobiles. Send it to the landfill and get a new one made.

This phenomenon is only bound to accelerate as software labor costs go through the floor due to offshoring.

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

[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:Release early, release often!

[nightowl03d]

In my experience, people don't know what they want until they see that you have isn't it.

You don't say what your target market is, so what I am going to reply here has a relatively small probability of applying to your situation. But this is slashdot so I don't have to worry about a silly think like relevance, so here we go....

If you had this experience, chances are the person who fell down on the job is not the user, the PM, or the developers, but the software architect for not identifying a fluxional feature. In fact the sole justification for the Agile methodologies is these fluxional features. Many, (but not all), "Agile" projects I have been called in to clean up have made this mistake. In most of these cases, the principal performing the architect role was a true technology wizard, but who would filter everything the business people said to conform to the principal's pre-conceived notions or more subtly falling into the "one true answer" trap.

When a contentious topic comes up in analysis meeting, a technology focused architect often seeks to resolve it and record the resolution, and hard-wire that behavior into the requirements. This is death. As this type of error multiplies, the seeds have been sown for disaster. What should have happened, was a contentious point should be used as an indicator of a volatile feature that should be designed with ease of customization in mind.

Volatile requirements are the norm and the identification of fluxional features is the key to knowing when to address them.

In my market these areas often require extreme flexibility.

1. Screen details, and screen workflow on the UI side. Keep the UI shell stupid using an MVC/MVP paradigm. (.Net 2.0 does a fairly good job with this if you use their binding framework judiciously, .Net 3.0 does a better job, JSP sucked donkey balls in this area, JFC and JSF are better, ROR is pretty good for simpler web sites). Oddly enough navigation is usually pretty stable once the stakeholder meetings have been conducted. Be ready for this.

2. New commands will be added. (Commands in this sense are persistence operations or new features). Work out early how all of those contentious points that came up in your continuous interviews with your stakeholders can be resolved with an appropriate plug in approach. What meta data will be needed for future commands? Be ready for this.

3. Your input formats and medium will change. Be ready for this.

4. Business rules will always change, never allow anything structural in your system be governed by any business rule stated in a stakeholder meeting. Keep them behavioral. Construct/purchase an appropriate rules engine who only knows about business rules. Be ready for this.

5. New persistence mechanisms will be desired. Be ready for this.

Sounds a lot like Agile doesn't it? The only difference is that be ready for this changes to react to this. Putting the effort in it to think about these and other volatile issues up front finds the trolls sooner, which enables refactoring efforts to be more local than they would have been otherwise. This list isn't comprehensive, so remember that outside of mathematics, and mathematical physics, there is almost never a one "One True Answer". My personal rule of thumb if that an issue can't be resolved via a thought experiment it should be made a fluxional point.

Very few people have the intelligence and foresight to extrapolate what a screenshot will mean to them, in the real world.

If you are using screen shots to walk through your scenarios, it is no surprise to me that you have gotten bad results. Paper prototypes will let the stakeholder see the consequences of their actions much easier. But that isn't enough either. You should also make efforts to communicate the state of the system and processes at each point in the screen shot. Designing a good walk through is more of an exercise in psychology than a technical exercise . Wal