Programmers and IT failure
Summary: Let's not forget the role of programmers when analyzing and examining IT failures.
IT failures are often rooted in hidden, almost tectonic forces — organizational, political, and so on — that are difficult to measure or control. However, this focus can obscure those special folks who actually create the technology we implement and use. I'm referring to programmers.
At their best, programmers are the dreamers, visionaries, and skilled artisans of technology: the real creators. In the truest sense, these great ones have advanced knowledge and human well-being in science, medicine, and many other important domains.
However, we can also point to unskilled, inexperienced, or self-centered programming behavior as a direct source of project cost overruns and delays on some projects. How many programmer-led initiatives have gone late or over-budget because developers created cool software with scant business value?
To learn more about the many faces of programmers, I sometimes turn to the Coding Horror blog. In a fun post, Jeff Atwood somewhat-jokingly describes eight levels of programming achievement:
- Dead Programmer. Your code has survived and transcended your death. You are a part of the permanent historical record of computing. Other programmers study your work and writing. Examples: Dijkstra, Knuth, Kay
- Successful Programmer. Programmers who are both well known and have created entire businesses -- perhaps even whole industries -- around their code. Getting to this level often depends more on business skills than programming. Examples: Gates, Carmack, DHH
- Famous Programmer. This is also a good place to be, but not unless you also have a day job. But being famous doesn't necessarily mean you can turn a profit and support yourself. Famous is good, but successful is better.
- Working Programmer. You have a successful career as a software developer. But where do you go from there?
- Average Programmer. At this level you are a good enough programmer to realize that you're not a great programmer. If you are an average programmer but manage to make a living at it then you are talented, just not necessarily at coding.
- Amateur Programmer. Being an amateur is a good thing; from this level one can rapidly rise to become a working programmer.
- Unknown Programmer. The proverbial typical programmer. Joe Coder. Probably works for a large, anonymous MegaCorp. It's just a job, not their entire life. Nothing wrong with that, either.
- Bad Programmer. People who somehow fell into the programmer role without an iota of skill or ability. These people have no business writing code of any kind -- but they do, anyway.
It's easy to stereotype anyone, placing them on a pedestal or tearing down their contributions as meaningless, although neither extreme provides much value. Having said this, what do you think about the role of programmers in causing or preventing failed IT projects?
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Flawed Discipline
Development is a trade, a craft. It requires senior craftsmen to apprentice -- PMs are not senior craftsmen, nor is their discipline.
In larger construction efforts, the problem lies in not going through the architecture phase with a cadre of various architects to build resolved, synthesized blueprints -- across the 6 Zachman columns (Zachman himself has a model that only details the view of 'technology').
Not programmers, but requirements analysts
Worse than requirements....
Its because these types of stakeholders think anything and everything is as simple to add into a piece of software as it is for them to say it. I had one group tell me about some MAJOR exception to the business rules of a project in production only when its affected someone. They had smiles on their faces saying "oh when situation X happens we don't want to do Y". Mind you the project had no means of handling these types of things because we asked about it day after day and were told it was not necessary.
Programmers? Try management.
Estimation of hours ignored by project managers when setting a delivery date or other milestones.
Design documents, supposedly "set in stone", suddenly altered by a boss a few rungs up who wants to please the customer. "Just throw it in there". Thanks, that's 40 hours more not accounted for in the timeline.
"That's not what we meant" customers, regardless of the fact that they signed off. Again, the design docs change after they complain to higher management, without a change to hours or dates of delivery. This usually happens at the end of a cycle.
Project Managers that don't know the word "no" exists.
"Yellow sticky" designs. Basically, you get a sticky note with a few lines scrawled on it, and you're supposed to code that with the expectation that it will come out just as they like.
Now, obviously I'm biased, but it's rarely programming or bugs that delay a project, and most often poor management.
Been there, done that.
Thus are project timelines set...
Same as any profession
Keep in mind, in a class of 100 students, some one finished at the bottom.
Indeed
Goes with Roger's rule of government
SPECIFICALLY about the programmers
NOTE: I do agree with others here that point out the flaws of the other people involved (PMs, management, etc.).
Iterative
In both cases, there will be a high-level design that encompasses the system which will include both the data dictionary and business logic of the program, then both facets of the design evolve and become more detailed together.
Client vs. Architect vs. Carpenter
The role of a pure programmer is to take the overall project design as given and put it into action. Programmers doing their job correctly, regardless of skill, rarely would have enough power to cause a project to fail, unless they were filling more than the programmer's role.
To bring back the construction analogy, if a building were to collapse because of faulty design, the carpenter would be far less likely at fault than the Architect. The architect in a business system is really the Project Manger and Business analysts, and they should be skilled enough to identify weak areas in the business system, and define the system clearly enough so that the programmer can do his job correctly.
Letting an unskilled programmer define the system is the same as letting an unskilled carpenter design a skyscraper.