Software Psychology

Why Good Project Management Can Destroy Your Project

Okay, the title for this post is misleading, I admit. But I wanted to catch your attention.

One irony of software development is that the consulting companies I’ve worked for always want me, as project manager, to have documentation to prove I did every reasonable thing possible to make the project succeed. Is that so bad? Actually, sometimes, yes.

Now the thinking is obvious. If things start to go wrong on a project and the customer starts to blame us, at least we can prove it’s not our fault. Now, of course documenting everything is impossible to begin with due to the law of lossy requirements. Besides, you can’t really know in advanced what minor detail at the time will turn out to be perceived in retrospect as obvious negligence. But those problems aren’t the ones I’m writing about today. For the sake of argument, let’s pretend it was actually possible to document every possible issue that might later come back to bite you.

The problem is that proving something ‘isn’t your fault’ is probably going to be perceived as equivalent to ‘blaming the customer’ instead. As it turns out, proving your customer is at fault isn’t always what’s best for your project – even if it’s the truth.

…And then a Miracle Occurs by Bruce Nielson

There is an old Far Side comic where a professor is working complex math on a white board. At one point he’s written “and then a miracle occurs” and then successfully finishes his difficult problem.

I’ve talked to a lot of programmers that feel software actually tries to do just that. They complain that that no matter how many problems in the past we have, we just don’t learn our lessons. We always assume that just because our approach failed last time that this time it will be different.

This sentiment has even lead to another joke I often hear: what’s the definition of insanity? Doing the same thing you did last time but expecting a different result.

But Miracles are Real!

Both of these jokes underscore to me that we’re missing something. And, of course, it’s the psychology of software projects we’re leaving out. If we are continually doing the same ‘bad’ things over and over, there is probably a reason for it. If it really was all bad and we just kept repeating the same bad behavior merely expecting a different result, then we’d really be collectively insane.

...

Software is Not Coding, It’s A Cooperative Game of Communication by Bruce Nielson

The Law of Lossy Requirements by Bruce Nielson

Lossy Compression

In computer science, compression is an indispensible tool. Anyone familiar with .zip files knows what I mean. Interestingly, there are two kids of compression, lossless and lossy. Lossless compression is like .zip compression, you put a file of, say, 100kb in and the end result is a file of, say, 50k. But when you reverse the process, you get back your original 100kb file.

Lossless compression relies on the fact that in real life information contains patterns. Just imagine taking this post and finding the most common used words in it. Then replace the most common word with a the tag “<1>” and the next most common with “<2>”, etc. The end result would generally be a smaller file, yet by replacing “<x>” with the original words you could recover the original file in its entirety.

I used to wonder what possible use lossy compression could ever be. Why in the world would I ever want to save off a compressed version of my files if I couldn’t get them back to their original state ever again?

...

Comprehensibility vs. Precision by Bruce Nielson

Abstraction vs. Precision in Requirements

I used to be an instructor for Rational Software’s RequisitePro software, which included a class called “Requirements College.” This useful class helped teach people how to elicit requirements from their customers.

Three things that really stuck with me from the class were, first, the idea that one does not “gather requirements’ per se, but elicits them. If taken literally, “gathering requirements” implies that requirements are readily available and you just have to pick them up and take them. This flies in the face of reality; requirements have to be created from nothing.

The second was the idea that How and What are relative to a point of view. I’ve written about this in the past.

The third was that, according to the course, abstraction and precision form a spectrum that affects comprehensibility.  The idea was that if you are too abstract, your writing won’t be comprehensible at all. But if you are too precise, it’s also not comprehensible. The following graph illustrates the idea:

...

Proper Use of Overtime by Bruce Nielson

What Constitutes a Change of Scope? by Bruce Nielson

The Prime Mistake by Bruce Nielson

Code is Design by Bruce Nielson

The Story So Far

Let’s return to the primary concern with Software. We’ve talked about how most software projects either fail altogether or run significantly over budget. Along with that thought, we considered the statistics that show that the development team itself plays little role in the success and failure of the project in comparison to users and sponsors. However, contrasting that we’ve looked at how software development is really developed in “thought units” more so then actual code.

These two facts seem on the surface to be at odds with each other. If software is really developed in “thought units” then why do users and sponsors have more control over the success and failure of the project then the developers?

Coding As Design

I will now explore this question further in a series of posts. But first, we need to look at the concepts of “software design” vs. “software coding”

...

Tell me What to Do, Not How to Do It! by Bruce Nielson

Software Schedules as Budgets by Bruce Nielson

The Blame Game by Bruce Nielson

I want to discuss the need for blame on software projects. “Ug! The blame game! I hate that!” I hear you groan.

But it's an all too familiar game for all of us. We all know that software (or all human endeavors actually) end with what we call “the blame game” where we all point figures at each other and claim the failure was someone else's fault. We say we are mad when this happens, yet we participate in said game with uncanny gusto.

I think it's a mistake to overlook the human value of “the blame game.” Frustrating though it is, the end result of the blame game is usually that blame is redistributed around to the point where it's impossible to blame anyone, because everyone (or no one) was at fault. And I'd argue that this end result is generally the accurate one – there really was no one person at fault more so than just about everyone else.

...

How Do You Estimate for That?! by Bruce Nielson

Does Robert Glass’ Formula for Estimation Success Actually Work? by Bruce Nielson

Sure It’s the People – But Which People? by Bruce Nielson

So if we admit that software is really about human intelligence, not tools, then we know that human factors matter the most.

Tom Demarco and Lister, in their famous (infamous?) book Peopleware, were the first to make popular the idea that it was people that mattered the most.

But I can't shake the sneaking suspicion that they missed something. You see, I've taken top notch programmers and had them succeed on one project and failure miserably on another.

I remember one client that, whenever he called, I'd cringe. I knew – knew – that no matter who I assigned to the project, it was already a failure from the moment he called. But when his counterpart at the same company called, I knew – knew -- the project was going to succeed no matter what.

Somewhere along the line the thought occurred to me: could it be that the customer was the primary success or failure factor on my projects?

...