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

[Duhavid]

I've known more than a few programmers like that,
unfortunately. I dont consider them the ideal,
just the ones that management hires because they
dont know what to value. The better programmers
of my acquaintance know the value in the existing
code, and are not hot to continually reinvent
the wheel.

Re:Good point

[TapeCutter]

Just nitpicking the point, but the begining of the SDLC is requirements gathering not development. If you nail the requirements acuurately (eg: write the user manual first and make sure the PHB's agree in writing) your maintenance and testing battles will be half over before you write any code.

In other words: If both the sponsoring PHB's and the developers fail to communicate to others "what the software is supposed to do" every user/tester complaint becomes a bug and the software rapidly deteriorates into a costly white elephant.

Justified

[Umbral Blot]

The emphasis on fast devlopment is justified, at least from a business perspective, because first to market gives a huge advantage in software, not to mention the network effect. Sure the ability to maintain and upgrade software is somewhat important, but it doesn't matter so much if it takes a long time if you are already dominating the market. Similiarily start-ups don't care about these issues since they plan on being bought out before they matter. Yes these attitudes create serious problems and lead to poorly made software, but what can you do about it? (besides using open source)

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:Justified

[cyber-vandal]

No but getting the new project out of the door as fast as possible to score political points with the board is equally as important to senior management. They don't care that the crappy code will cost the company a fortune once it's in they just want to be able to say that they managed to get a system in in X amount of time.

Re:Justified

[stonecypher]

The saddest thing about this is how correct you are, and how it hinders you. If you and another team developed Product X, and both went 33% over schedule, the other team would hit early milestones, declare progressive success, change the schedule to fit the new needs, allow bloat, hammer in new features to justify the lag, and end up coming in 200% over budget. You would come in 33% over budget, but since you didn't dance around acting like the schedule was the only important thing, your lean and nearly on-time product would be seen as disasterously over-budget, and you wouldn't be allowed to manage again.

It's a pity that what you said is correct, because it encourages a kind of myopic and nearly religious devotion to what is really just a measuring tool, and the results are a massive drop in actual quality in exchange for the feeling of success. What you said is right, but remarkably counterintuitive, and it is my belief that what you're correct about is the primary basis for most of the problems in this industry today.

I wish more people were like you, and were willing to take the up-front hit instead of playing self-deception games to feel better about slippage. You plus a real estimating tool like the PSP/TSP (see propoganda video) are exactly what this industry needs, but facing the problem is so difficult and fixing it so superficially expensive-looking (despite the remarkable cost benefits in the long run) that I think your kind of actual observant development is a long time in coming.

Pat yourself on the back. You've made all the old people proud today.

Most Businesses Only Consider Initial Cost

[Anonymous Coward]

It seems to me that this concentration on initial construction of software ignores the issue of total cost of ownership.

Unfortunately that's how a lot of businesses think and they later regret it if they didn't consider the whole picture before settling on a solution. In lot of cases they just want to have something up and running fast, in some cases, the up-front cost doesn't matter.

Different Strokes

[Anonymous Coward]

The point of rapid development is the proof of concept. Pretty much every rapid development mantra is centered around.

1) Make it work
2) Make it work right
3) Make it fast.

If you want tightly designed and thought out, the extreme programming style might be more your style. (Or the style of a properly run business..)

(And god help me when someone makes a "4) for profit!!!! LOL WTFASLBBQ" joke, go fuck yourself.

I am not so sure

[raymondmroz]

that the two concepts must be mutually exclusive. Software can be constructed quickly, and still be "robust" and "maintainable". I will not get into specific development "paradigms" here, but I think that there are options that give us both in varying degrees, on a problem-by-problem basis. Market forces demand flexibility, and those that are, make it.
Managerial Buzzword Count: 3

No.

[hsmith]

You have large maintnence costs because no one properly plans up front for the long term. People want to see something and they want to see something fast. No one sits down to write the proper documents, no one sits down to plan ahead, they think for the short term only. Which leads to long term problems down the road. At least, that is what I see as major issues on things i have worked on.

people don't want to make the initial investment to plan ahead, so they end up spending much more in development costs because no one decided where the product should go.

Re:No.

[RingDev]

Here! Here!

The problem isn't high level languages or agile development. The problem is a lack of foresight, planning, and documentation.

We have two major systems at the company I work for. One, that the related staff spent 2 years documenting their business practices and exactly what they wanted the application to do. They took that huge document to a couple of consulting companies and said "we want this." 2 years later the consulting company that won the bid turned over a nearly perfect application.

The other app is an extension of a 3rd party application. This app started development with little to no documentation, no project manager, and no one who had actually worked with the 3rd party application. Flying blind into a short deadline has left us playing redevelopment games for almost 2 years! We finally managed to get the critical personnel together to get the system and processes documented, and after 3 months of business process documentation we should be set to re-write the business layer of the application in 6 months.

Had the user group worked with the 3rd party app prior to launch, and documented their processes, the entire application could have been developed in under 9 months. But with out that work on the front side we will have over two and a half years wrapped up in development from 3 people.

One more project like this, and I'm moving to management. As much as I love coding, I hate inept managers even more.

-Rick

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: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!

Re:No.

[Anonymous Coward]

Please stop comparing software development with building bridges.
Bridge building is usually just repeating what you did last time you build a bridge. That is fairly easy to plan.

When it comes to developing software, you do something completely new every time. That is way harder to plan, since you do not know all the issues before you are done.

Re:No.

[stonecypher]

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

Philadelphia, New Beijing, Taiwan, Seoul, Londinium, Carthos, Constantinople, Phoenix, Chicago, Tampa, Rio De Janeiro, Tokyo/Kyoto, Sydney, Jakarta and Dubai were all carefully planned. All have scaled to the modern world very well, with the exception of dealing with automobiles, something you can't really fault the ancients for not seeing coming. Essentially the entire Roman empire had very careful city planning, and in fact they did well enough that even now, 2500 years later, their water solutions and much of their infrastructure is still in use today.

Cities ARE built in a "agile development" fashion.

Most of them, yes, but certainly not all of them, and those that aren't ad-hoc are having far fewer problems than those which are.

These days, everybody zones. There's a reason for that. The reason cities are moving away from on-the-fly planning is that we're finally waking up to that just because that's how it's always been done in the past doesn't mean that's how it should be done. Several cities, like my hometown of Pittsburgh, are finding out the hard way that that can cause just tremendous problems in infrastructure which can throttle economies. Have a look at a land value map of Pittsburgh some time, and look at where you have good rail coverage. Compare it to another city, like Chicago or Phoenix, which was planned. You'll notice that in unplanned cities like Pittsburgh, the presence of rail has a comparatively enormous impact on land value, because it offloads industrial infrastructure use, keeping the byways open for commercial and residential use. In planned cities like Phoenix and Chicago, the problem isn't nearly as severe. Notice that Phoenix is growing at something like 60x the national average; Phoenix was nowheresville until about five years after the invention of the air conditioner, and now it's one of America's biggest cities.

There's a reason for that. Actually, I've got a pretty good article for you on the topic - it's 45 pages and very, very detailed, but it's a little dry. Still, give it a shot - for someone who feels that city planning is a good parallel to software planning, it may be eye opening to learn why the cities in the US who are doing the best in terms of scaling are the ones who ignore the trends you correctly point out, and who instead go with a strict urban growth plan whose conceptual parallel would arguably be stricter software methodologies.

The thing is, in my admittedly limited experience, most of the people who really stand behind Agile/XP/Scrumm are people who've only ever dealt with Agile/XP/Scrumm or no methodology at all. It is frequently the case then that people see Agile/XP/Scrumm outperforming a complete lack of organization, and quickly begin to believe that to develop without Agile/XP/Scrumm is suicide. There is a reasonable parallel here in your city planning metaphor - most people who look at city planning think it's all ad-hoc, and don't know about the problems going on in city scaling right now. This turns out to be a massive repeating issue to both the Department of Agriculture and to the Department of the Interior. The case can be made that what you are suggesting amounts to Argumentum ad Antiquitatem, and that indeed though this is how it's usually and traditionally been done doesn't mean that it's how things should be done. By extension of your parallel back to software, the way it's always been done might well be described as the waterfall model or the monolithic model, or even by non-planning entirely, and I think we're all to the point of understanding how big of a mistake that would be. (Might as well do some Structured Programming in COBOL, huhuhu.)

Thing is, though, there are methodologies other than Agile. Agile/XP/Scrumm are very good for in-house software in a business environment, because they are well adapted to unpredict

Justified-Handwaving.

[Anonymous Coward]

"Similiarily start-ups don't care about these issues since they plan on being bought out before they matter. "

Gee, speak it like it's gospel or something. I better not start a company, or some uninvolved slashdotter may suspect my motives.

I agree

[The OPTiCIAN]

> What do you think?

Spot on. It's funny to watch people do demonstrations of how quickly Ruby on Rails can be used to build something because it's exactly the same sort of thing that was used to promote WebObjects ten years ago and I know from experience what rubbish it is. For all but the most simplistic applications you have to abandon the mapping of form elements to the database because you need to do validation. If you start off with a RAD approach to problems to these pages and add validation as an afterthought they quickly degenerate into a horrible mess. There will be less of a problem in this respect with ruby on rails because the data layer is so primitive so there are some knots you can't even contemplate being tied into, but - um - what was the point of Ruby on Rails again? :)

I imagine that doing major schema refactors on Ruby on Rails apps would be a nightmare because there's no easy way to check that you've fixed all the breakages. Whereas if you use EOF or Cayenne and get a culture in your software where developers avoid using key-paths except in agreed spots it's quite easy - you make the change, fix the areas where you find compile problems and then its done.

Something I would be interested to see would be some sort of business logic layer that could emulate a JDBC adaptor. Then you could write your application against that and bind to it as though it were a schema, but in the background it would in fact have business logic behind it. This would allow a separation between business logic and presentation but still allow you to quickly bind applications up as you do in the RAD webapp tools.

Re:I agree

[Duhavid]

It's funny to watch people do demonstrations of how quickly Ruby on Rails can be used to build something

And it is also funny to have to take that demonstration code and turn
it into a production ready system. Time is never sufficient, because
management can only see the (poorly) implemented features, and not
the lack of error handling and return value checking, and robustness.

Maybe the beginning gets too little attention ...

[richg74]

I think I might argue that the beginning of the development processs -- or, at least, what should be the beginning, namely the design, often gets too little attention. My experience leads me to believe that most gnarly maintenance problems stem from poor design more than from low-level coding blunders. Think of the well-publicized security issues that have bedeviled Microsoft. I don't think they occur because Microsoft has bad programmers, but I do think that the "tightly coupled" design of Windows is a mistake, and makes problems much more difficult to resolve.

One reason these tools get a lot of attention is that using them produces a measurable effect. It's the "bookkeeping fallacy": things that are easy to measure must be more important than things that are hard or impossible to measure.

I do think these rapid development tools can add a lot if they are used intelligently, which I think means using them to present concrete ideas and prototypes quickly, in order to gain understanding of the problem domain and to get user feedback. But I still think Fred Brooks's advice in The Mythical Man-Month is correct: plan to build the first version to throw away. You will in any case, and it's better not to deliver the rubbish to the customer.

The curse of IT has always been, "There's never time to do it right, but there's always time to do it over."

On the contrary ...

[jc42]

Most people who develop software also have to maintain it, ...

What???? This may be true with open-source software, but I've yet to see a company that did things this way. The norm is that developers, testers, maintainers and users are four separate groups that are kept as far apart as management can manage.

This does go a long way toward explaining why there's so much crappy software Out There.

More important part: the stupid f*&cking busin

[bADlOGIN]

Everyone seems to forget that given enough time and resources, *anything is possible in software. Eveyone forgets how _PATHETICLY RETARDED_ business decisions get made (apologies to the mentally challenged who do manage to tie thier shoes). Snide remarks aside, I'm dead serous here. It takes just as much resources, time, and effort to execut a good business idea as it does to do something so fucking stupid it's amazing it was considered in the first palce.

Bitch all you want about rapid paths like Ruby On Rails not addressing the long term method, but don't forget the ADD nature of the 6 figure mouth-breathers in the board room. By the time it get's done in a 1/2 assed fashion, you can confirm or deny weather it was worth doing in the first place. Worst case scenario, you have something making money that is hard to deal with. In that case _THROW IT OUT!!!!_ and take into account what you now know for sure about the market/customers/some-sucker-who-will-pay and build the _NEW_ thing that will best make money from them. Too hard you say? Won't work you say? Get some test coverage and push ahead. If you don't, just go home now, because your competition will. Adapt or die. In a global market place, you can't affort to buy "what if" engineering dollars.

Arguments like "We need something that will respond to something we don't know yet" is a variation on big design up front and other various sorts of "slow" waterfall mentality to building software. Yes, I'll admit to being one of those annoying agile assholes, but for 80% of the "business decisions" that get made in the corporate IT (and even startup) world, it holds true: the guys in suits don't know what they are doing. There are numerous reasons why Fredrick P. Brooks said in The Mythical Man Month (now over a quarter century old!) "build one to throw away. You will anyways" was because the nature of business hasn't changed. Anyone selling you some path to something you don't need today needs to be avoided like the plague.

I'll agreee with the /. masses: Microsoft are a buch of stupid dicks. However, they do one thing (perhaps only one thing) right: they get version 1 out infront of people to figure out what they need to do. Where they go wrong is assuming that 1.2 can be built off the 0.9 beta code base, but that's marketings fault. Given a company with a strong enough technical staff, these things can be corrected. If no strong technical staff exists, then they are doomed anyways and don't know it yet...

To summarize: this argumet is a load of crap presented by people who want to cling to "proven-to-fail" approaches to building sofware. It's not a bridge, it's not a car, it's ones and zeroes that may or may not see the light of day. The same optimization axion aobut "never prematurely optimize" applies even better to "never assume you have it right". As soon as people drop they fronts of how much they think they know about building products, the better off we all will be. Try, learn, and adapt. Again, if you don't your competition will...

Footnote: * within reason. You're not going to create a miracle, but you know what I mean here...

Re:i think you answered your own question

[joecode]

In other words: The implicit assumption in the original question is incorrect: These frameworks are *not* concentrated merely on getting apps running quickly.

Of course the infamous manner of showing off these frameworks is to make a screencast showing how easy it is to make a simple wiki or todo list. These screencasts can be misleading since they often employ simple CRUD scaffolding, which is useless in the real world. However, taken with a grain of salt, they help you get a feel for the framework.

A good MVC framework helps organize your code in a standard manner, and a you get a lot of mileage from leveraging a supported, tighly integrated, full stack like that of Ruby on Rails. (It's really fantastic: handles everything from ORM to script.aculo.us with blissful ease.)

Pardon my fanaticism, but I decided to learn Ruby on Rails last weekend, and I'm quite certain it'll be the main thing I'll be coding my own projects from now on. (Catalyst looks good if you don't wish to abandon good old Perl.)

Re:It's a disposable culture.

[wtansill]

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.

Ehhhhh -- no. Maybe some trivial applicationm can be thrown away and reengineered every few years, but business generally does not have that luxury. There are data conversions to consider, as well as the fact that, depending on the system in question, an entire "ecosystem" has likely grown up around the core application. You cannot just throw the application away without ripping out and reworking all those other systems that depend on it in some form or fashion. Yes, I know -- Software as a Service to the rescue -- well defined interfaces between applications, etc. Except that in the main, that does not happen, so you are better off having an extensible, maintainable system. Now if I could only sell that idea to the PHB...

Re:i think you answered your own question

[Anonymous Coward]

As Douglass Adams said: the problem with things that can't possibly go wrong is that when they do go wrong, there's no way to fix them. When you accept the "easy" models promoted by some of the higher level languages, you might take the framework your using as far as it goes and realize that it doesn't go far enough. At that point you're stuck. For example, you may have written a powerhouse GUI application for a platform like .NET or Java and now that you've invested millions in development, you realize that there's nothing more you can do to optimize performance on that platform: your application is a memory hog and takes forever to load. It's still a good application, but your choice of development tools has put a hard limit on how far you can go. That's a tough spot to be in.

Re:You misunderstand rapid development

[Duhavid]

Not that you dont have a good point, but I have seen
many cases where the developers want to converse with
the subject matter experts, but they and the management
above the SME's will not commit the time needed to do
this. So, the quick, wrong ( in part anyway ) answer
is given, the system is wrong, and development is
blamed.

And continuous deliverables and agile development can
be a good solution, but only if the users will put in
the time to evaluate the incremental drops. And that,
often enough, depends on the management levels above
them allowing them the time.

I think you got it backwards

[humblecoder]

I think the problem isn't that there is too MUCH focus on the beginning of the software lifecycle. The problem is that there is too LITTLE focus on the beginning of the software lifecycle.

The beginning of the software lifecycle is supposed to consist of analysis and design - both of which can lead to the construction of a superior product if done right. The issue is that many of these "quick start" languages and frameworks make is easy for a programmer to dive right into the coding phase without considering the overall design of the system. Thus, they skip the beginning steps in the software lifecycle.

Re:i think you answered your own question

[skiflyer]

At least that's why I assumed rapid developement frameworks caught on.

There's also the fact that in many jobs a huge percentage of programs are run once, or maybe run once a day for a month... and maintainability isn't an issue. My previous employment was just that, lots of tasks that needed to be scripted, and then they were done. Occasionally a program become popular and had to be scaled up to repeated use, and then we did just that. But the rapid development was great for the ones that didn't, sometimes the code for them was garbage, but worked, and sometimes it was really well organized and easy to transform... but more importantly the tasks where completed in less total hours (programming + running) than if a human had to process the issues by hand.

Now, as someone who's a boss and cares alot about the dollars per hour, one of my constant frustrations is watching someone write a script for a run once application that takes 3 hours to write and debug, 5 seconds to run... while I'm paying them $30/hr, whereas they (or a better yet a $7.50/hr employee) could've done it by hand in 30 minutes.

Re:It's a disposable culture.

[aauu]

The attitude you get when you hire children. Well designed apps are maintainable and last for much longer than the transient early career coders can believe. I have written application components that ran unchanged for more than a decade without any modification. Careful thought, proper design with comprehensive error detection and incremental testing during construction can produce an efficient proper solution that will stand the test of time. Enterprise applications often have lives of a decade or more. Banging out a new application in record time is useless if the design and construction is so shoddy that the application cannot be maintained without discarding the entire pile of crap for a new version. Notably, the high speed coders have moved on to new jobs so that they avoid responsibility for the mess they left behind. Maintenance is inevitable because time is change. I have spent 30 years in the IT industry and my experience that all but small new companies will have an application portfolio with an average age 7 years. This will be longer for core functionality as you do not re-engineer an enterprise in 90 days. When development can take 4 to 5 years and millions of dollars to replace a core application it is very important to consider the life of the application and platform. Most of the surviving dot coms now have 7 year old applications that are straining from the quick implementation that did not consider scalability and flexibility in the haste to get the company started initially. Maintenance also is much more difficult than coding a new application. It is much harder to extend the functionality of an existing production system without breaking anything. Real programmers can do maintenance successfully where others give up and want to discard all previous investments for their convenience.

Shipping prototypes

[Brandybuck]

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?

As someone who started his professional development life maintaining other people's code, I completely agree.

But I must take issue with the title of this thread. The problem isn't too much focus on the beginning of the software lifecycle. Coding is in the middle, not the beginning. A good design comes first, and a good analysis of the problem domain before that. Modern methodologies ignore design, or pretend to do during coding. A quick and dirty hack may come back to bite the heel of a future maintainer, but a hurried design is sure to smother him to death. Way too much emphasis is made on coding, but that's only 10% to 20% of the lifecycle (not counting maintenance).

We're not developing faster, we're just shipping more prototypes.

The difference...

[vga_init]

Where is it? When I have written software in the past, I've seen rapid development and maintainability go hand in hand.

If you want to finish a software project quickly, your code must be written with a certain level of foresight. You can't just hammer things together, but you must also put in some design effort to make sure that the structure accommodates the functionality you're shooting for. When you do this, your software will be developed faster than any other method because software lends itself to its purpose--your project runs the risk of dying before its finished if you don't. Your software will also have its own intrinsic flexibility toward its application. That means that a clean, solid application will come together more rapidly (and is coincidentally easier to maintain).

Release early, release often!

[mcrbids]

We have two major systems at the company I work for. One, that the related staff spent 2 years documenting their business practices and exactly what they wanted the application to do. They took that huge document to a couple of consulting companies and said "we want this." 2 years later the consulting company that won the bid turned over a nearly perfect application.

Wow. Sounds like a ringing endorsement for planning and quality execution.

Unfortunately, though I've tried time and time again, I've never gotten anywhere near the participation required to lay out everything in advance accurately. Worse, the few times I've actually managed to get something together and gotten everybody to sign (in blood) in triplicate, it was rejected on the very first day of rollout because they didn't expect something that was, upon rollout, patently obvious. In my experience, people don't know what they want until they see that you have isn't it. Very few people have the intelligence and foresight to extrapolate what a screenshot will mean to them, in the real world.

So, I've turned my back on the whole idea, and have instead adopted a modified "agile development" approach.

I do just enough specifications to determine how all the pieces are going to fit together, what all the database fields are, and how the constraints, triggers, and foreign keys assure reasonably sound data. I beat the idea in front of a few people and search for objections, until most people approached seem to like the idea, and nobody has any major bones to pick.

Then we code - it goes out the door for public release as soon as it seems stable and workable. I don't bother trying to make it totally bug free, so QA is short and sweet. On rollout, I ask our clients to review it and inform us of any bugs. We never get it right the first time, and we're pretty up front about that. But we fix it quickly, and most importantly, we modify our software towards what the customer actually needs. Stuff that is simply not needed gets dropped pretty fast.

Our software is designed to "fail early" - so that inconsistent or inaccurate data doesn't hurt anything. And so far, we've had only minor issues in over 2 years of heavy, active, exponential growth and development.

Turnaround time for an average modification is less than a week. We issued over 40 releases in the last year alone. Every so often I go over everything in a new perspective, and do a bunch of minor tweaks all at once - that's when UI improvements come down hot and heavy.

The response has been wonderful! A customer who mentions an idea, and sees it implemented a few weeks later is your evangelist for life. You practically become their religeon, and you'll get recommendations and referrals for the rest of your days.

I've heard people talk about it like bargain hunting - they hunt around - just to see what's new!

So far removed from the bleak hopelessness so common here at Slashdot about software projects - it's exciting, intense, fun, and profitable!

Freenlancer pov: keep sloppy code coming, please

[Zaphod2016]

From the freelancer's perspective, there is nothing I love better than a mess of spaghetti code hacked together by interns on crack and then rushed out the door by a PHB.

Where I might normally charge $250 for a few hours of patching, these desperate fools will happily pay 10x that so long as it "works by Monday morning". Of course, that's pretty easy to deliver, especially considering the PHB will almost always elect to avoid all the *real* problems (read: time-consuming). The result? Repeat business!

I used to feel kinda crooked about this (honest). But, in all fairness, a man can only give the same "TCO is relevant!" power point presentation so many times before he just gives up and takes the money.

Spoken Like a True Engineer

[ChronoFish]

Ruby on Rails is not designed for the software engineer. It's designed for the Glue Master who wants/needs an application developed as quickly as possible with as much power as possible. The applications are "quick and dirty" one-offs that will be "refined" by being rewritten. Perfect for Web-UI's that need to be constantly scrapped and rewritten. Typical programming team consists of a single ADD user (not usually a "learned" programmer).

PHP/Python/VB is not designed for the software engineer. It's designed for the programmer who wants/needs an application that is maintainable and will last longer than a RonR app - but is is not going to last indefinately. The applications will have a history and may be revisited and refined for several years. Perfect for heavily used Web Apps that have a short-multi-year lifespans. Typical programming team consists of 1-4 programmers optionally with some support staff and/or managment.

Java/C/C++ is designed for the software engineer and programmer who wants/needs a robust powerful application that will have 5's and 10's of years lifespan - Perfect for building something like a PHP/Ruby on Rails/Web script engine, Apache Web Server, Linux OS, etc. Typical programming team consists of multiple groups of 6 programmers/engineers and staff (managment, testing units) to support them.

It doesn't make sense to over-engineer applications that process simple web-forms. Nor does it make sense to hack together a web-content-management-system. You use the tools, the effort, and the language that makes sense for the application at hand.

-CF

Re:flawed.

[vidarh]

True in some sense, but keep in mind that most software development is not done by software houses, but in house by companies that will use it.

For some of these systems getting it operational quickly may be important, but for all of them maintenance is longer term going to be far more critical. I've more than once built something quick and dirty because we needed something "yesterday", but inevitably a quickly built system will need to be replaced or rewritten to serve long term needs without driving maintenance costs through the roof. Often, planning for a early rewrite is ok - it gets you something up and running quickly and may buy you time AND experience with the actual user needs. But ultimately engineering for maintainability will be needed if your app is going to have a decent lifespan, and engineering for maintainability does take a lot more time than most people think it will.

Three words

[KarmaBlackballed]

Service Oriented Architecture

(SOA)

burn the first one

[Russ Nelson]

The reason you want to be able to build a working system quickly is so that you can throw out the first one. You see, there is no substitute for learning how to do something than to actually do it. Trouble is that, if you invest a lot in the first one with an eye to reducing maintenance costs, you won't be willing to throw it out even though the entire structure of the program is fucked. A program is founded on a certain set of assumptions. If your assumptions are wrong, then the foundation of your program is wrong. Your program can never be fixed. It must be thrown out, and a new program with correct assumptions must be written.

The second system will also be fucked, because you are a sophomore. It, too, must be thrown out. Only until you get to version 3.0 will you actually have a working system which should and will last for the lifetime of the product. THEN you worry about maintenance.

Re:i think you answered your own question

[anon mouse-cow-aard]

I agree with your point, sometimes real-scissors and real glue are better than a word processor... but a it does not have to be all bad... mitigating factor would be that if people like coding, and they keep their practice up by implementing scripts in three hours, that could easily be saving you training hours, keeping their skills up for when they really need it, and improving coder morale... You might be just distributing training costs throughout your budget, and not having to shell out for it up-front in a five day course...

Re:i think you answered your own question

[gblues]

You're ignoring opportunity costs; sure there's a higher cost ($90) for your scripted solution; however, in those three hours, maybe that $7.50/hour employee is occupied with other, more profitable tasks that he wouldn't have been able to complete if he was pulled away for 30 minutes of data entry. Maybe data integrity is critical and the cost of the scripted solution vs. the risk of a $7.50/hr employee mis-entering the data made the scripted solution much less.

Nathan