In this month’s edition of Dr. Dobb’s Journal, there’s an article about IT project management (and I can’t be arsed to look if there’s an online version.) The age-old axiom that software development cannot be compared to for example electrical engineering is brought up and questioned. The common idea seems to be that:

1. Managers think that software development can be estimated and calculated in the same way that other engineering tasks.
2. Software developers claim that there can never be an analysis in the same way, since software is complex and there are no proper ways of defining discrete individual components. (For example: in electrical engineering you have to work with currents and resistances and whatnot. If you bring in a resistor, you know its parameters and what effect it will have on the circuitry. However, if you change a line of code in software, there are no formal parameters for defining the overall effect.)

Now, the article questioned this view of things; I’m not quoting, but one comment was along the lines of: “software development isn’t as fully darn special as you think.” (I love this! I have to paraphrase from memory more often; one has such freedoms when one’s not citing any sources.) This would seem to indicate that the exception-to-the-rule view is due to a combination of sloppy requirements from management and sloppy discipline from the developers.

My own view is that everything - literally everything – can be formalized and calculated, but this would be futile in software development; it’s too complex a job for a person, and not comparable with having a sheet of statistics over electrical components. However, I fully believe that better tools for code analysis will come; and will become common practice to use.

On another note, I saw a nice article about flawed IT processes today. To sum it up in a sentence: mis-management and a lack of understanding for the big picture is why so many IT projects fail, even though the best and brightest minds are used. Good point, and an interesting read.

But what is the common thread through all of this? Everyone thinks that IT management is flawed, but few offer any constructive examples in public of how to solve the specific problems.

“We’ve got to get the business process right first [and] you’ve got to think of the processes all the time,” he said.

“From that we can define the required business outcomes.”

It’s this end-to-end process visibility, and recognition of the need to keep going back to that big picture, that will help IT achieve better project outcomes.

I’m sure that Jed Simms (quoted above) has a very good plan concerning how the process can be improved. But how can one agree with his generalized comments if one doesn’t know the details? The article, in essence, says nothing more than that management and the IT processes are flawed. And, of course, now I have done nothing more constructive than comment on the flaws of the article bringing up flaws. Meta-criticism is amusing.

This entry was posted on Monday, May 22nd, 2006 at 12:48 pm and is filed under Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.