Browse by Tags

All Tags » Estimation (RSS)

…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

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...

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?


Proper Use of Overtime by Bruce Nielson

It seems to me that “overtime” is a much talked about subject, both in literature and just around the water cooler, but that people tend to take one of two extreme views on it. The first view is that overtime is immoral unless the development...

How Do You Estimate for That?! by Bruce Nielson

Trying to estimate software projects is difficult to say the least. But sometimes, it’s just impossible. I just finished resolving a problem on my project that I spent the last two days working on. The task was to issue a Purchase Order (PO) to a vendor...

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

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...

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?