Software Development

Programmers and IT failure

Read Jeff Atwood's tongue-in-cheek descriptions of eight levels of programming achievement. Then consider this question: What do you think about the role of programmers in causing or preventing failed IT projects?

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

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:

  1. 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
  2. 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
  3. 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.
  4. Working Programmer. You have a successful career as a software developer. But where do you go from there?
  5. 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.
  6. Amateur Programmer. Being an amateur is a good thing; from this level one can rapidly rise to become a working programmer.
  7. 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.
  8. 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?

30 comments
moosa12
moosa12

getting prgramming sites is not a real one but...........

redux
redux

Well, your list is entertaining, but it doesn't have much to do with your question. IT projects never fail because of programmers, good or bad. Ill-conceived plans with good code will fail; well-conceived plans with poor code will work (they might work better with better code, but they won't NOT work -- or, the flip side to not working -- go WAY over budget.

Datacommguy
Datacommguy

"IT projects never fail because of programmers, good or bad." Working along side of programmers for four decades, I've found that a poor choice of assigned programmer along with an unrealistic assigned time frame will kill a project quicker than management can change their minds. Many projects are user driven and a never-ending cycle of test, hit a show-stopping bug, test, hit another bug, etc, etc will get the plug pulled in frustration almost every time. And in some cases, it's not entirely the programmer's fault. A good (and experienced) programmer has already figured out what old program he/she can modify to accomplish what's required before leaving the planning meeting. A newbie (or coder) will start from scratch without knowing what's really needed and slide downhill from there.

Saurondor
Saurondor

"I've found that a poor choice of assigned programmer along with an unrealistic assigned time frame will kill a project quicker than management can change their minds." If management didn't choose the team and it didn't set the time frame. What's it getting paid for?

Tony Hopkinson
Tony Hopkinson

Poor choice of programmer, or choice of poor programmer. Not the programmer's fault unless they had a choice of being chosen, not something I've seen though I'm admittedly junior to yourself with a mere two decades. :p

HavaCigar
HavaCigar

It must be a programming language, it's not a spoken language, but the World was just informed that it exists...maybe that was a security leak?

Tony Hopkinson
Tony Hopkinson

Try VB6 in french. :(

KSoniat
KSoniat

I worked for a Japanese/German company and many of the programs were written by Japanese programmers (in RPG). The only time we ran into a problem was in the documentation. There would be a word they didn't know how to translate so they would leave it: "Update file ITEMAS from the transaction and move Watashi to a new field." (I don't know what word it was - and this work means "I" for those of you who must know - you know who you are) Watashi wa skoshi Nihongo de hanashi masu. (I speak a little Japanese)

Tony Hopkinson
Tony Hopkinson

so when they cut and pasted it, it didn't need maintaining. Wakarimas ka? Wakarimasen. :(

coderancher
coderancher

It was to avoid a conflict with a reserved word.

rods
rods

There those that are smart enough to program, but shouldn't. Being smart isn't the only qualification for being an excellent programmer.

cssatx
cssatx

Two thoughts ... First, an adage ... A programmers ego is often directly proportional to the amount of maintenance his code requires. And ... Don't forget the Zen Programmer: One who meditates quietly on his project and then returns to the temporal plane to produce brilliant, esthectically pleasing, intuitive and maintenance free code.

Tony Hopkinson
Tony Hopkinson

in his own opinion.... No one knows how good their code is until someone else has to change it.

redux
redux

Nobody has to change it if it is good code.

Tony Hopkinson
Tony Hopkinson

Even "Hello World", can be internationalised, interfaced for the partially sighted, passed to a mobile, printed.... Change is a given.

Ed Woychowsky
Ed Woychowsky

Always write your code as if the person who is going to maintain it is a homicidal maniac that knows where you live. Thinking about it, that one phrase, homicidal maniac, pretty-much describes most of the developers that I know.

Tony Hopkinson
Tony Hopkinson

Let's face it if your programmer isn't up to the job, why is he your programmer? You want something for your business, you get a suitable programmer, he does it. What denotes suitability? Did he understand what you wanted? Did you understand what you wanted. Did you understand the impact of what he thought you thought you thought you had said waht you wanted? A programmer is able to be that point of failure or success, only in as much as any other member of the project team is. It's the business that defines success, it's the business that aims the programmer. It's the business that constrains him. The only time how good I am really counts, is when I can wave my wand and pull a success out of failure despite the business. Being good doesn't help if you are constrained by perfectly reasonable business objectives. Quality programming and successful programming are not even close to the same thing. Quality costs money, is it necessary for success? How many programmer led initiatives?. Where have you been? What programmer led initiatives? There should be no such thing. If I come up with a plan to say refactor an app to improve the applicability of the software, to ease maintenance and enhancement, to give a usability or performamnce improvement, to reduce support costs and got the go ahead. It is now a business led initiative. It isn't being done because Tony fell out with windows, or thinks Forth is a great language, it's being done beacuase there is a business advantage. If it turmed out that my idea sucked, then leadership was sadly lacking, again. Any decent programmer can recognise when their idea is not going to pan out. In fact the real scale of ability is how quickly and cheaply you can recognise this. Generally programming failure in IT projects, is when the guy, who says can't be done or shouldn't be done is ignored. Don't get me wrong I've seen the results of bad programmers, (note bad programming doesn't necessarily mean bad programmer), but what idiot employed them. What idiot didn't recognise their mistake? It's business that insists on turning programmers into glorified clerks, so any eejit can do it and thereby reduce labour costs. If they want success they should bin Messr's 7 and 8 and starting payng for more 4 and 5s....

HavaCigar
HavaCigar

You rock dude! As my Dad always used to say "Yesterday I couldn't spell injuneer and today I are one..."

Jaqui
Jaqui

business doesn't want to hear how it is a failure in management rather than the incompetent they hired. :D

Tony Hopkinson
Tony Hopkinson

and I personally consider that suspicious. Almost as if some halfwit consciously decided to hire a cheap idiot to save money.....

Saurondor
Saurondor

I like your comment, may I add it to my running definition of outsourcing? tr.v. out?sourced, out?sourc?ing, out?sourc?es To send software development to a cheap outside idiot in order to cut costs.

rob mekel
rob mekel

Automating a bad process still leaves you with a bad process ]:) Adding a "bad"-programmer to do the job won't make it a succes. And ... programmers now-a-days ain't the same as they used to be ... Then in the old days, sheesj am I getting that old ... there was info analysis, technical analysis/specs/design and only then came the programmer. Now a days it's often: Info-analysis, programming. This doesn't help on getting the project to a succes. Arghh the good old day's, 2 byte of memory, programming on a papersheet, having one hour a week to test the works on a real computer ... wow ... those were the day's. :D ;) mmm ... guess not

Tony Hopkinson
Tony Hopkinson

Computer time was so expensive, that you did a lot of preparation work. Designs, dry runs, test straps. Now the time is comparitivley cheap and the perception is that it uses less resource to suck it and see. And it can, known problem, experienced developer, entire thing can be done before you could start on the documentation. What still hasn't happened, is figuring out to cope without all the other good things that came out of that detailed design and planning process. Throw in cookie cutters, analyst/developers, and RAD (QAD), and you get the mess we are in now.

jkameleon
jkameleon

Guy, who deals with necessery evil soon to be outsourced somewhere far away.

Geek3001
Geek3001

Donald Knuth may fall into the 'dead programmer' category because of his seminal books on programming, but I don't think he is dead yet. Addendum: Add Alan Kay to the list of the 'not dead' but influential. Of course, in computer years, both of them are older than the hills.

smithjohn1285
smithjohn1285

Hi every body this is Smith i this it is not true Please mix the anchor text up and choose one below use a different anchor text every blog placement when you have used all 5 start again education help uk education information uk education job education UK education jobs careers ================= Smith visit education jobs careers

adam.cox
adam.cox

when i develop work i consider the process of development itself. it's evolutionary. therefore, i should take into consideration that someone else will need to evolve it. if you are a selfless, lazy programmer like me, then good work will result. however, that being said, we need to consider what is the definition of programmer. the smaller the team, the more responsibility any one programmer has. in fact, the 1 man team is common place as budgets are restricted to insance limits. i believe that the business ought to think long and hard on the value of the project. if they can't allocate budget (the investment) then they should expect poor return. 'nuff said. ;) ~ Adam

GTGeek88
GTGeek88

"Donald Knuth may fall into the 'dead programmer' category because of his seminal books..." That doesn't make sense. These books are still seminal and still valuable as are his other contributions to this industry. And he is definitely alive and kicking.

Geek3001
Geek3001

I was commenting on the fact that the original article put Knuth and Kay into the 'dead programmer' category. There aren't too many disciplines where the people who produced the seminal works are alive and kicking. IT happens to be one of them.