Our Bad

One of the first lessons that you learn as a programmer is failure: the program you just wrote doesn't compile or it doesn't work.

We're not talking nuances here, it's not that your program "mostly" works - this is a black and white failure - it just won't compile or run for whatever reason. This is sort of unusual, as in many other diciplines you don't get any instant feedback of rejection.

Compare the english student writing a paper. There's no "publish button" that you click when you think you're done. In this case failure is in the eye of the beholder (or whoever's grading it) - but a gaggle of typos, full-page sentances or a sprinkling of emoticons doesn't give any instant feedback of the fact that there's going to be a big red "F" on the top of the page when you get it back (although it probably should)

As CS Students, most of the time if the computer doesn't reject what you're trying to do then you're usually most of the way there. Sure, your professors will mark some style points and want to see some comments, but if it runs and full-fills the techinical requirement, you're probably going to pass.

This give developers in the real world a strange failure dichotomy. We accept constant failure as a fact of life - as long as it's coming from a machine. But we have a tougher time dealing with failure if it's coming from a living, breathing individual.

Developer: "What do you mean it's wrong? It has 100% test coverage and fullfills the specifications to a T?"
Client: "But no one here can figure out how to use it"

Failure in the real world doesn't always give a black and white compile-time error - it sometimes comes at you in shades of gray. This means that sometimes, like our developer above, you might disagree with other's definition of failure as for developer's there's really only 1 type of project failure we implicitly accept:

#1  500 - Internal Server Error

But on consulting gigs there are plenty of other types of failure out there:

#2  Users can't use your software.
#3  You didn't explain to the client what you were building and it's not what they wanted.
#4  You didn't force the client to figure out what they wanted and instead built what they thought they wanted.

#2  is a development failure - it's pretty clear that you need to be able to build something that's usuable by whoever the end user is. Now doing so and doing so well is a skill that takes learning and experience. It's a failure you can really only avoid by experiencing it a few times and eventually come out richer for the experience. Accept that unless you are your own demographic (e.g. programming stack overflow must have been kinda fun) you're going to have to put some legwork in to develop something that works at the level of your audience, but that's a long discussion for another time.

Compared to #2, #3 and #4 are project managment failures caused by not putting in the time upfront to figure out the requirements.

#3  happen much more often than they should because as everyone knows - programmers are lazy, tiny gods. They are lazy in that stuff that's not fun - a.k.a. anything that doesn't involve programming - is going to be skipped:

"Programmers will not keep themselves honest. If left to their own devices, they will skimp on anything that is necessary but not fun." (Phillip Greenspun / Design Review)

They are tiny gods because they reign supreme over their tiny project-specific domains like entitled, angry tyrants, refusing to accept that what they are doing might not really be what's best for the project.

This means that developers are happy to spend hours and hours of time developing the wrong product and will take umbrage upon being told of this failure - when a hour-long meeting early in the process would have put everyone on the same page.

Unfortunately clients are people too - and they suffer from the same desire to skimp on the un-fun. Once they've hired someone they'd like to believe that their work is done and the developer will take it from here. But since the only true metric of success in consuling is a satisified client, and since clients often don't know what they actually want until they've seen what they thought they wanted, there's a chicken-and-the-egg loop that makes it difficult to succeed right at the start.

These two issues can sometimes lead to first-iteration-failure, where the first iteration of a project is a complete throw away because it doesn't match the client needs.

Sometimes there's no way to get around it. Creating the first iteration gives you and the client a domain specific language to actually discuss the project that no amount of specifications or poking and prodding of the client would work. But oftentimes a few hours of the unfun work on both the client and developers part can lead to a quicker happier project conclusion. Time spent on user stories and blocking out pages in design usually pays for itself many-fold down the line.

Failure is a fact of a life as a developer, but sometimes we need to accept that failure as not just coming in black and white but in shades of gray as well.  And clients, your need to remember: programmers are people too.