Skip to main content

What term best describes your software development process?

Extreme Programming (XP)
20% (178 votes)
5% (47 votes)
Dynamic Systems Development Method (DSDM)
2% (18 votes)
Rational Unified Process (RUP)
10% (92 votes)
11% (99 votes)
Something else
8% (71 votes)
No process ("Cowboy Coding")
43% (378 votes)
Total votes: 883



I use IAD or Prince2, with IAD being my favorite as it is specialised to deal with application devellopment.

20+% XP?!

I find it surprising that over 20% of respondants claim to be doing XP. As a consultant responsible for promoting XP/Agile I saw numbers lower than this even within groups that had an organizational commitment to doing Agile and seeing it succeed.

I wonder if many of those who claim to be doing XP actually mean that they are doing some form of agile, iterative process in which TDD plays a significant role (Which is not sufficient to call it XP.)

To really be doing XP, you must at least be doing short iterations of no more than two weeks and delivering working code at the end of each iteration; know who your customer is and have nearly continuous contact with him; play the planning game which includes writing requirements as stories, having those stories prioritized by the customer, having those stories estimated by the developers, and tracking velocity per iteration; performing customer testing, test-driven design/development (Including refactoring), pair programming, and continuous integration. Doing all of these things is the minimum necessary to actually be doing XP.

Something else is a bad option...

I would call our team coding ethic Extreme Cowboys. (not of the Brokeback variety). To be fair though, our business team lately has been making a monumental effort to define requirements, even though are somewhat shorthanded.

Do these process' really help?

I have both seen, and read, many times; the overwhelming majority of software projects fail. Could it be that these process' merely slow things down; and may in fact have even higher failure rates than no process at all?

From my two decades of experience, I think the answer is: yes.

Were this not the case, there would have been an inevitable and widespread commercial adoption of any effective process.

These are all trying to address the problem of low success rate in software development, and that is worthy. This does not mean that any of them are particularly effective at it.

Do these process' really help?

Almost any process is capable of being successful if it is truly followed. The difference between agile and non-agile processes has nothing to do with whether or not they are capable of success. Rather, it has to do with how they measure success. Non-agile processes tend to measure success by measuring if they delivered what they said they would deliver - "delivery by contract" if you will. Agile processes measure success by thier ability to adapt to changing customer requirements. That is, they measure their ability to deliver what the customer wants right now very quickly rather than what the customer said he wanted at the beginning of the project at the end of the project.

Maybe the question we really need to ask is: why, if there are so many good processes out there, do we continue to fail? I think the answer is that the customers are too willing to accept our failure. If failing meant that we did not get paid we would not fail. We fail because we can get away with it. When the software industry is in a place where customers are unwilling and/or unable to fund unsuccessful projects then we will improve. As long as there are a lot of big companies and big governments out there willing to throw money away we will keep selling them the "Emperor's New Clothes."

Do these process' really help?

Just wanted to add an analogy. Bear with me:

When John Kerry was running for President in 2004 he said something that bothered me a lot. He was talking about his strategy to deal with the "war on terror" and he said that he intended to double the size of the Army Special Forces. This is a very bad idea. It is something that we tried in Vietnam, and it didn't work. In fact, it is the reason why as recently as Desert Storm guys like General Norman Schwarzkopf did not trust the Special Forces to do their job (Though this attitude has completely changed since.)

The problem is that you can't just make experts. Some people are very good at what they do and others should be doing something else.

In the business world software is in great demand. When demand is up you increase supply. The problem is that good developers are not a commodity. You *can* just make more, but you cannot assure that they will be any good. Good developers are like Special Forces in the sense that they can't just be produced at will, they have to be found. But businesses think in terms of supply and demand and they think they can throw bodies at the problem. The result is a lot of really bad (and highly paid) programmers who write really bad code and cause projects to fail. No process can address this. It is a matter of how we think about development and how we hire and retain good craftsmen.

Do these process' really help?

My experience is just the opposite. Ad hoc cowboy coding almost inevitably leads to project failure. The only proviso I would add to that statement is that it applies to larger projects (say 3+ developers) or long running projects (long enough for original developer(s) to have moved on to other projects) or both. Time and again I have seen the following: 1) Cowboy coders hack together v1.0 w/designs that exist only in the developer's mind and little in the way of documentation. 2) Manager's decide to go for v2.0, thinking it will be inexpensive and quick because "we are just adding these new features to the app." 3) Coders (often not the original authors) start the work and eventually realize that the existing design (or lack thereof) will not support the requested features. Something close to a complete rewrite is required. Project runs over budget and schedule or fails outright. Putting some sort of process in place from the start does improve the probability of success for both v1.0 and v2.0, at least that is my experience. BTW, the developers of version 1.0 are often not at fault. It is typical for them to be operating under a very tight budget and schedule that promotes a go-for-broke attitude.

Do these process' really help?

Just a couple point to add: I do agree that an overbearing process can also lead to project failure. Particularly stifling are approaches like "we aren't writing a single line of code until the requirements document is signed off by all parties." My own approach is a bit more agile - every process activity should pass the return-on-investment test.

Do these process' really help?

In my experience, a basic iterative process seems to be prevalent... but I have found that scope is a bigger prediction of success than the process. If the project takes more than 3 months to finish, it will probably end up over time and over budget. If the project takes less than 3 months to finish, it will probably be on time and on budget.

Do these process' really help?

Stupid question.... doesn't it make sense to adjust the process to the type of project. If the project is something you've done many times before, perhaps the waterfall is more appropriate. And if there is a lot of risk, perhaps an iterative approach would be better.