Search results matching tag 'Requirements'

Physics and the Law of Lossy Requirements

BruceNielson — Fri, 05 Nov 2010 19:11:44 GMT

This post over at The Eternal Universe is a physicist complaining about how he’s not seeking a computer science degree, yet he has to keep learning computer languages just to publish physics papers.

He should have read my previous post about the Law of Lossy Requirements. The cheapest way to capture all of the details of an algorithm is in code. English language specs never capture all the necessary details. So of course physics papers are often written in code.

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

BruceNielson — Mon, 20 Sep 2010 06:04:25 GMT

In my post on “code is really design” post, I mentioned that I would further address the paradox that software is created in “thoughts units” but the most important people to the success or failure of a project are the sponsor and customer. In this post, I’ll explore that paradox further by discussing Alistair Cockburn’s idea of Software as a cooperative game.

In Agile Software Development, Cockburn says:

Software development is therefore a cooperative game of invention and communication. There is nothing in the game but people’s ideas and the communication of those ideas to their colleagues and to the computer.

In Crystal Clear: A Human-Powered Methodology for Small Teams, he writes:

[Successful teams] view developing software as an evolving conversation – an economic-cooperative game, actually. In any one move they go forward and create reminders for each other.

But in what sense is software a game and how does this help us understand software development better?

I’ve never been fully comfortable with Cockburn’s calling it a “game.” I’m not sure images of Monopoly and Halo (which is what comes to my mind, anyhow) is what he intended.

It’s helpful to refer to other non-software examples that Cockburn uses. One of my favorite of his examples is making laws in a legislature.

Can You Estimate How Long it Will Take to Pass a Law?

Imagine if the republicans asked the democrats, “How long will it take you guys to pass that new health care law of yours?”

Now in theory, the democrats should be able to estimate this. It’s just a bunch of words on a pieces of paper, right? Someone has to sit down to write it, they have to talk to experts, they have to run a few numbers and come up with a budget, then they have to pass it through a committee, then bring it to the floor, and finally get a vote. So the question the republicans are asking seems reasonable on the surface.

But in reality, part of what the democrats have to estimate is how long it will take them to convince enough republicans to pass a version of the bill. If this step were unnecessary, making an estimate would probably be easy. But if the democrats need to actually convince some key republicans to vote for the bill to get it passed, then part of their estimate will have to be an estimate for how long it takes to keep revising the bill until the republicans accept it – if ever.

Once we realize that is the case, the republican’s question seems less legitimate. The Republicans have a significant say in determining when the bill is “done” and the democrats don’t actually control that part of the process. The democrats cannot, even in principle, make an estimate for how long it will take to pass the law.

I see software much like this. We have customers and sponsors on the one hand and the development team (programmers, testers, designers, project managers) on the other hand. But instead of capturing ideas into specific laws to be interpreted by other humans, they are cooperating together to capture business rules into an automated programs that will be interpreted by computers.

There is nothing else going on when we make software. There is no analogy here to building a house or a wall, or anything else physical. When my customers ask me “how long will it take to program the fitz-bart module?” I am literally incapable of answering them because part of my estimate would have to be how long they will choose to iterate before they accept the software as matching their needs. There is literally no limit to how many times they might choose to keep tweaking the requirements and I’ve been in cases where they never become satisfied with it.

If I didn’t have to worry about customers having to accept the software, estimates would be a lot easier. But with customer acceptance required, it’s impossible to estimate anything beyond the first iteration of the creation of the module.

An Alternative – Cooperation

Now consider an alternative example. Lets say that both the republicans and democrats both are anxious to pass a health care bill and they both have more or less synchronous goals. Now is it possible to estimate how long it will take to pass a health care law?

Absolutely!

Why? Because now both sides are working together to meet a target date. This means both sides are motivated to make the date and, more to the point, both will be willing to accept some compromises to meet that date.

Software works the same way. If the customers/sponsors and the development team both want to make a certain release date or a specific budget target, there is almost always a way to come up with a workable (though usually manual, and thus less than ideal) solution to any software problem such that you can meet those goals. It just requires both sides to agree that they will make the target date or the target budget and to be willing to negotiate on scope until they match those goals.

The Law of Lossy Requirements by Bruce Nielson

BruceNielson — Thu, 21 Jan 2010 19:15:00 GMT

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?

Of course for files, lossy compression is useless but for computer graphics it’s quite useful. Because the human eye is not capable of picking up all the details in an image it’s possible to reduce the details in the image without the human eye being able to tell the difference.

What’s even more interesting is that you can continue to increase that lossy compression on an image until the human eye can tell the difference, yet the brain will still be able to tell what the image is. It just looks a bit more blurry.

In fact, you can continue to compress and compress using lossy compression to any size. At some point you end up with a single solid color, of course, which isn’t useful, but even if you take a very large image – let’s say 1024 x 1024 pixels – and shrink it via lossy compression down to the equivalent of a 16 x 16 image, the human brain fills in the details and still makes sense of the image.

Requirements Are Lossy Compression

If Code is Design, one of the most under appreciated points of software development is that requirements are equivalent to lossy compression of graphics, only in reverse. (See also Tell Me What To Do, Not How to Do It for an example of this.)

What we call “requirements documents” (or even “design documents”) are really a blurry picture of what is to be built. In other words, requirements and design documents by definition do not contain all the details.

Why do we do this? There are actually many reasons, but here are two key reasons:

1. Until the software is actually built, it doesn’t exist. So there isn’t really a choice but to imagine it with broad brush strokes and then refine it into reality.

2. As was discussed in a previous post, human beings more easily understand abstractions rather than precision. If we didn’t have abstract and blurry views of the design, no one but the programmer would ever understand what is to be done. Actually, even the programmer would only understand it in chunks and not holistically.

The Law of Lossy Requirements

If you followed my argument so far, then The Law of Lossy Requirements will now make sense to you. This law states:

All requirements documents are a lossy compression of the business rules. If you made it non-lossy, the cheapest way to document it would be in code.

Therefore there are two corollaries to this law:

Corollary 1: There will never be a point where you know all details of what software is to be created until the software is completed.

Corollary 2: There is no such thing as documenting everything in the software because to do so would require synchronizing essentially a second copy of the code.

Comprehensibility vs. Precision by Bruce Nielson

BruceNielson — Thu, 14 Jan 2010 19:13:00 GMT

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:

Legalese is a good example of this. Legalese is very precise wording for legal purposes, but because its so precise, it’s difficult for anyone but a lawyer to understand – and that’s not a fair comparison because the lawyer at least gets paid to slog through it.

Therefore, according to the course, requirements should seek the sweet spot of maximum comprehensibility, where it’s neither too precise nor too abstract.

Useful, but Misleading

This idea of avoiding too much precision to increase comprehensibility is a useful idea. But I couldn’t help but feel it also somewhat mislead.

I kept thinking to myself: but what if that level of precision is what you need to come to an agreement on?

Imagine dumbing down legalese so that it’s more “comprehensible.” Would that be a good thing? It’s not like legalese was created to keep lawyers employed (though sometimes it might seem that way.) On the contrary, legalese was created because a more comprehensible abstraction would also have multiple possible meanings. In a court of law, that’s precisely what we’re trying to avoid. Ergo, the need for legalese.

Are Software Requirements Like Legalese?

Now if the point of requirements documents is to get everyone going in the same general fuzzy direction, I can see that a comprehensible abstraction would be the best way to handle it.

But if the point of the requirements is to come to agreement on how to specifically implement something, there is no substitute for precision in details. I believe “requirements” (and also “design”) must therefore be considered as something closer to legalese in such a circumstance.

In an ideal world, we’d probably want both. We’d want to start at the highest level of abstraction and work our way down, keeping every stakeholder informed and involved as we take the fuzzy abstraction and turn it into something specific and detailed.

But in reality, the Marketing People drop out after the first details start to be filled in, Management’s eyes begin to glaze over once the “requirements document” is complete, and even the Technical Lead might to nod off once we get into the really nitty gritty details.

Conclusions

I see an essential tension between “comprehensibility” and the need to come to agreement on an actual implementation, which requires comprehending the actual details. I think this is one of the hardest problems in software development and I do not expect this to be a problem that can ever be overcome because it’s the essential nature of software itself.

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

BruceNielson — Wed, 30 Dec 2009 09:00:00 GMT

Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity. – George Patten

This sounds like good advice doesn’t it? It is, actually, but we need to understand it correctly.

The first thing we need to notice is that there is no objective difference between ‘what’ and ‘how.’ The difference is purely relative.

If I’m a marketing guy, I’m going to give you a ‘software spec’ that might be a series of bullet points that says:

Make the Whiz-Bang 50% faster to improve the user experience
Add the Gog Widget everyone keeps asking about
Enhance the Dribblium feature to automatically look up user information

If I’m the marketing guy “what” I’m doing is increasing sales. “How” I’m doing it is by the feature improvements listed above.

But to the team manager, this looks a lot more like a list of “what” needs to be done with no details on “how” to do it.

So the team manager takes this list of bullet points and creates what we (mistakenly) call “detailed requirements.” He now carefully lays out the details of “what” needs to be done but decides to leave it up to his tech lead on “how” to accomplish it.

The tech lead then creates what is (mistakenly) called a “detailed design” where he makes a bunch of UML and designs out exactly “what” he wants his programmers to do but still leaves it up to them on the specifics of “how” to implement that design.

Interestingly, the programmer then writes the code which, from the compiler's point of view (do compilers have points of view?) is really a specification of “what” the software needs to do, but leaves it up to the compiler of “how” to do it.

So based on this example, we must accept that “what” and “how” are purely relative to a point of view. They do not objectively exist.

Perhaps this is why we don’t usually make a separation between “what” and “how.” They tend to mingle freely in our minds. Have you ever called your spouse and said “Hey, what time were you planning to be home?” when what you really wanted to know was “How much longer can I stay out with the guys/girls?” I do this all the time.

This is actually useful to know. Because it means that you never have to take an instruction as “how” you have to do your job because what people actually care about is “what” they wanted to accomplish.

I remember a customer that insisted that a certain field, I think a zip code, was to have exactly 6 characters in it. This was a hard fast requirement.

It turned out that they were used to a DOS-based program where the program moved to the next screen upon finishing typing in the last field on the previous screen. The zip code was the last field, so they wanted to be able to enter it and not move to the next screen before having a change to review it. (For those of you under 30, DOS is a quaint little program that lets you type stuff and then it deletes all your files)

Of course in a windows based program (for those of you under 20, Windows is that thing you see just before you click on the browser) this was a non-issue. The correct ‘requirement’ was actually “allow me to review the screen before I move to the next” which is built into windows anyhow.

But that’s my point. You should never just assume that because your customer told you “how” to do something that they weren’t actually trying to tell you “what” to do and just didn’t know how to ask it right.

So don’t just blindly follow requirements. Instead, make a real effort to understand ‘what’ the customer really wants to accomplish and come up with your own suggestions of ‘how’ to accomplish it. Think of requirements as the starting point of the discussion, not the ending point of ‘what’ you’ll finally deliver.

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

BruceNielson — Thu, 17 Dec 2009 15:00:00 GMT

In a previous post I mentioned Robert Glass’ “fact” that estimates are made at the beginning of the project before the problem is even defined, thus the estimate is invalid from the get go.

While I don’t disagree with Glass, I do believe he is under estimating (pun intended!) why we human’s prefer estimates – even known bad ones – over no estimate at all. I referred to this phenomenon as “water breathing” because if you are about to drown anyhow, you might as well see if you can breath under water.

Up front estimates are much the same – if you don’t make them at all, you’ve failed. If you make them and they are bad, you might (and often will) have time to correct them later. So that’s the real reason we make bad up front software estimates regularly. It’s a good reason once properly understood.

I know this probably sounds defeatist and I don’t mean it to be. In later posts I’ll discuss alternatives to making bad upfront estimates, even when you have “no choice.” But before I explore alternatives, I think we could benefit from looking at all of Glass’ “facts” about estimation. (See Facts and Fallacies of Software Engineering, p. 27 – 42)

Fact 8: One of the most common causes of runaway projects is poor estimation.

Fact 9: Most software estimates are performed at beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.

Fact 10: Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.

Fact 11: Software estimates are rarely adjusted as the project proceeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.

Fact 12: Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimates targets. But everyone is concerned anyway.

Fact 13: There is a disconnect between management and their programmers. In one research study of a project that failed to meet its estimates and was seen by its management as a failure, the technical participants saw it as the most successful project they had ever worked on.

Look over that list carefully. I can see everyone nodding their head approvingly. “Yup, it’s all so true! Those stupid pointy haired managers are the real cause of the bad estimates!”

While these facts all seem generally correct to me, I feel like something is missing. Glass seems to be advocating that if we do the inverse, we’ll be fine. Likewise, as you shake your head knowingly and wag your finger at management, you are advocating the same. But is this really true?

Let’s try taking the inverse of all his facts and see if we really believe the software estimation problem is solved. Can you honestly say you’ll agree with the following statement as being factually correct?

You’re software estimates will all be wildly successful if you just:

Make good estimates instead of poor ones (inverse of fact 8) by…
Making the estimates after the problem is defined – so after requirements gather is completed (inverse of fact 9)
Have the developers make the estimate, not marketing or management (inverse of fact 10)
And adjust your estimates when there are clear changes to the scope of the project (inverse of fact 11)

Since all of the above are true for your project, we can then conclude that it’s perfectly acceptable for management to get very concerned if you miss your estimates, since they “did it all the right way” (inverse of fact 12) and so we know there will never be another disconnected between management and programmers again. (inverse of fact 13).

Do you believe it?

I don’t.

Personally, I have never let management or marketing make estimates for the programming team (except to add fudge factor on top), I’ve always performed the estimate after requirements gathering when we’d supposedly “defined the problem”, and I always adjust my estimate for clear changes of scope. But even when I “do it all right” my experience is that programmers still can’t generally keep to their estimates.

So my conclusion is that while Glass has hit on a series of true problems about software estimation – and I’d agree if you don’t at least do the above, you have no hope at all in making your estimates – I feel he is failing to address the true underlying problems with software estimation.

So then what are the real reasons we all seem to suck at software estimation? To find that answer, we need to learn a lot more about how software and human psychology collide before we have any real hope of finding a solution to the problem.