Software Psychology

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?

...

What are Water Breathers? by Bruce Nielson

In Robert Glass' excellent book, Fact and Fallacies of Software Engineering, one of his “facts” (I.e. Qualified opinions) if that “Most software estimates are preformed at the beginning of the life cycle... before the requirements are defined and thus before the problem is understood.”

He goes on to say that, unlike many of his “facts” in the book, there seems to be no controversy on this one; there seems to be general intellectual agreement that we lock in on estimates too soon. This being the case, he says, “Someone should be crying out to change things. But no one is.”

He then adds:

At the very least, you need to know what problem you are to solve. But the first phase of the life cycle, the very beginning of the project, is about requirements determination. ... Put more succinctly, requirements determination is about figuring out what problem is to be solved. How can you possibly estimate solution time and cost if you don't yet know what problem you are going to be solving?

...

Tools or People? by Bruce Nielson

Software Psychology Blog