Greg Young [MVP]

Yeah, I've got several swarmy comments to make.

1. Is this guy saying that IT projects fail and it's the programmers' faults?  Uhmmm.  No.

2. You get what you pay for. When you buy your programmers from Big Lots, you get Big Lots quality code.

3. No one's life is on the line when your e-commerce site doesn't get updated on time. Deal with it.

4. Lemme see, the solution to overly-bureaucratic software projects is to inject an overly-bureaucratic standards body into the equation.

5. After your government spends millions creating a unified standards body and you hire only certified programmers, who are you going to blame then when your IT projects fail?

I'm currently maintaining a poorly written body of code.  To be "good" code, it probably should have been written in twice the time and at twice the cost.  But, that isn't what the business wanted.  They really prefer lower cost structure.

I disagree with the idea that "At the time of the punch card, it would have been almost impossible for a developer to get by with lousy practices. " and "Is this guy saying that IT projects fail and it's the programmers' faults? Uhmmm. No." I realize programming existed way before the internet, but it seems to me that one of the things that programmers have said since programming existed (and which can be found on the Internet, look for debates about Cobol vs. Fortran..it's fun reading anyways) is that other programmers suck, and explain why. I think bad programmers have existed since programming was started, and bad programmers can definitely help kill an IT project. As a (hopefully no longer bad, but nowhere near as good as the great programmers I have worked with) programmer, I'm pretty confident about this. Are there *more* because of, say VB (since that's a typical target)? Maybe. But I'm not really convinced of that either.

The problem isn't the quality of the code. Big projects fail because of a host of other reasons:

1) Unclear objective. People like having grand visions, but nobody wants to consider the detail. Poorly defined requirements leave a gap between what they customer wants, and what the specification says to build. And nobody ever reads specifications in that much detail - after all, the customer has told the development team what they want, why should the read the same things back?

A shoddy spec results persistent mission creep and endless change cycles.

) Excessive Complexity. Trying to implement business processes that are complex is a nightmare, and with large systems, this is nearly inescapable. Invariably the "Well Defined" business processes do not cover the total range of cases, and there are exceptions that are currently dealt with by work-arounds or manual intervention on a daily basis.

) User resistance. Lack of customer buy-in = dead project. If you build it, they won't necessarily come. Often people don't feel they've been adequately consulted, or because the changes don't benefit them, they aren't interested.

) Internal Politics. Power struggles within the organisation resulting in resistance from part of it - and they can make your life merry hell. Conflicting requirements is, of course, mandatory.

) Politicisation. Large projects are visible to the project, and so politicians bugger around with them so they can be seen to be doing something. It doesn't matter that they can't access Hotmail, they know how to fix the problem.

) Political change. Ongoing and persistent changes to the processes within an organisation result in a constantly moving target, spiraling costs, and failure.

) Lack of feedback to Management. Some organisations are totally unwilling to tell their CEO/Boss/Senior Civil Servant that their wishes are completely impractical, or excessively expensive. These people are God, and the will means it must be made so.

That's just off the top of my head, what I've seen in projects and the papers. I'd estimate that maybe 10% of big project failures (the type that make the papers) fail for technical reasons. I'd say that most fail because nobody took the time to sit down and think in detail about what the system should do - and then draw up a decent list of requirements

Most software projects are written by teams of people, so who are you going to go after?  Who is the person to disbar when a 12-month effort takes 18-months?  Who takes the fall when one module uses miles per hour and another uses kilometers per hour?  Who is responsible for that null pointer running around?

Yes, I am concerned about software quality, but I have never seen a project get into trouble because of a single person.  How do we find the individual to disbar?

@camera:

I agree with much of what you said.  The fact is, even experienced, professional, honest, intelligent develoeprs often have failed software projects.  Software is H A R D.  Sometimes its the programmer's fault, sometimes the client, sometimes just dumb luck.  I don't see how getting the government involved will help since even the best developers don't always know how to keep projects from failing and clients or management can sabatoge it themselves.

That being said, i do often wish there were some minimum basics required to be learned for one to become a programmer (at least one working unsupervised.)  Things good databse design, code reuse, OOP, etc.  

@David

There are times where the choice is between more features vs quality in a given amount of time.  But what happens is that when a business does that over and over and makes it their MO, productivity slows when the poorly written app needs to be altered and maintained.  Things get more and more time consuming and expensive each time something changes.  So the extra "time & money" they saved in the beginning will cost them more overalll, and often sooner rather than later.   I think we have to educate business people that they aren't really helping themselves when they do this or drive us to do it on their behalf.  

They are accumulating "Technical Debt":

www.martinfowler.com/.../TechnicalDebt.html

This is the best way i've seen to describe the issue to non-technical people.

In response to jdn: That there are good programmers and bad programmers is a given. This is true for the sales dept, the accounting dept, and the IT department. Just as a bad sales team can bring down sales, a bad IT department can churn out sloppy code. A failed IT project is a management failure and not a programming failure. Management should build their department for success: in staffing, in tools support, in training and mentoring. It's management's responsibility (I'm taking CEO here) to build a competent IT department to support the goals of the business. If the management team inherits a set of unqualified programmers, then they need to (a) reset expectations for projects (b) set in place a plan to build competencies (c) support the team with the latest tools for the job, and (d) hire in qualified programmers to establish best practices and structure to programming projects.