Quote de jure

“In the absence of clearly-defined goals, we become strangely loyal to performing daily trivia until ultimately we become enslaved by it.”
— Robert Heinlein

Yes, I’ve seen it.

BTW, yes I know the difference between “du jour” and “de jure”, it is is a pun on the latin “concerning law” and the similarly sounding french “of the day”.

Posted in Uncategorized | Tagged , | Leave a comment

Quote(s) du jour

“If you don’t know where you’re going, any road will do” – Watts Humphrey

“Would you tell me which way I ought to go from here?” asked Alice.
“That depends a good deal on where you want to get,” said the Cat.
“I really don’t care where” replied Alice.
“Then it doesn’t much matter which way you go,” said the Cat.
– Lewis Carroll, “Alice’s Adventures in Wonderland”

Plans begin with clarity on the goals. Building on the travel metaphor, you must know “where you are going”.

Next, you must now when you have arrived. The goal must be measurable to the extent that you will know it when you see it. If you have more than a very small number of stakeholders (like more than one), you need this clarity.
The Plan helps to assure that you have the necessary resources, can overcome impediments, and actually measure progress.

A plan does not mean unchanging devotion to the original plan. When conditions change, I change my plan. What do you do?

Posted in Uncategorized | Leave a comment

Don’t reinvent the wheel when you only need to apply some grease.

Process improvement is usually gradual, a series of small improvements that add up to a large improvement. James Watt’s breakthrough innovation of the steam engine doubled the efficiency of the suddenly obsolete Newcomen engine. But subsequent incremental improvements quadrupled the efficiency..

It’s not that hard, but it takes discipline and knowledge. Understanding what to change requires knowledge. You must know the steps in the process, what each step does, and what the results look like. With some modeling one can then foresee the effects of a change. Changing only what needs to be changed requires discipline. Don’t try to do too much at once.

Posted in Uncategorized | Leave a comment

How NOT to identify constraints

I came across a very problematic example of addressing a software development problem using the theory of constraints at http://www.agiledesign.co.uk/2010/theory-of-constraints-for-beginners

So, an example of applying these steps in a software development context might be;

Our goal is to construct, test and deploy software.
Our constraint is in system test, this is apparent due to a build up of software that has not been tested.
We identify exploit opportunities by considering where we loose test capacity e.g. recording timesheets. Since test is the bottleneck, time spent doing administration is directly reducing the output of the system.
We subordinate the system to the bottleneck by changing responsibilities e.g. PM to take on some administrative tasks from testers.

At this stage we return to assessing where the bottleneck is. If we run out of exploit / subordinate opportunities we may choose to elevate the constraint. This is where we consider adding resources, automation or training.

There are several big problems with this.

First, most product approaches insist that the source of the defects be responsible for the the costs, this provides valuable feedback and the right incentives. Shifting to the PM hides the problem.

Second, it assumes that bugs will just happen. This is wrong, they can be prevented or removed earlier in the process.

Third and biggest is assuming that this is a testing problem. It is far more likely a construction problem. Stop sending so many defects into test and you the paperwork won’t be so severe. It is common for 40-50 percent of project effort to be consumed with rework. World class organizations get this to under 5 percent. They don’t do this by having the PM write up the reports or adding testers. They do this by preventing defects or finding them before they get into test.

Posted in Uncategorized | Leave a comment

Alert! Daniel Kahneman’s new book coming soon!


If you were disappointed with “Blink”, this promises to be the book that tells you when to think fast and when to take it slow.

Posted in Uncategorized | Leave a comment

Behavior Trumps Outcomes!

A <a href=”http://www.i2i-align.com/2011/07/why-behaviors-matter-more-than-results.html” blog post over at i2i-align /a> scrateches an old itch.

If we care about results, why not measure by those results?

One answer is that if people have some control over the final numbers, and those numbers are important, they will find ways to hit them, even if it undermines your best intent. Dan Ariely’s narrative about teachers manipulating scores, or worse reminds me of Robert Austin’s warnings about measurement dysfunction. There is also a significant element of Dan Pink’s emphasis on mastery and autonomy, where outcomes based incentives were counter productive to actual production.

For a non-trivial task that requires even rudimentary cognitive skill, creativity, and choice, focus on the process at least as much as the outcome. A good outcome requires a good process. Focus on the process and if it doesn’t give you the results you want, improve that process.

Outcomes can be off for a variety of reasons. But behaviors will get you the outcomes you want more often than not.

Posted in Uncategorized | Leave a comment

Software Architecture, What does it look like?

I am a small part of a project of a project empirically investigating how documented software architecture can positively affect a project. In this case the project is the open source Hadoop distributed files system (HDFS). <a href=”http://blog.sei.cmu.edu/post.cfm/measuring-the-impact-of-explicit-architecture-documentation” title=” Rick Kazman’s SEI Blog Post” > describes some of the background and goals.

I’ve been asked recently “what does a design or architecture document look like?” Well, part of this project was document the architecture for Hadoop, and that document can be found here

<a href=”http://kazman.shidler.hawaii.edu/archdoc.html” title=”Hadoop Architecture Doc” > .


Although we often think of Architecture as a high level design, that isn’t really quite right. In design we often have to jumb between high levels of abstraction to more detail, then back again. In short, Architecture tries to capture design aspects most important to satisfying the non functional goals. Some of the description will capture the physical layout of the code modules, e.g. modularity or class structure. Other views may include run time views of data or process flow. Some of the tactics developers might employ could affect architectural properties of the system. They need to have some understanding of those design considerations. That’s the goal of Architecture and architecture documentation.

Posted in Uncategorized | Leave a comment

Quote of the day

“I sell software, not defects”

I was speaking with Isabel Margarido, a Ph.D. candidate, earlier today when she made this remark about her former job in industry. It is a strong statement about personal commitment, quality, and professional engineering responsibility. I’m going to remember and use that line, or some variation, in the future. Customers pay you for the software not the defects, so what do you plan to give them?

Posted in Uncategorized | 1 Comment

Weinberg’s second law

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.


I came across this again in David Rice’s Geekonomics. Rice also use uses the “bridge” as an example of physical infrastructure that one can see. Software is infrastructure, but it’s not visible. It’s weakness is not readily apparent.

In principle, we could certify software by testing, but by then it’s rather late, it’s already been built. Quality must be built in, that requires real engineering.

Posted in Uncategorized | 5 Comments

Quote of the day – Watts Humphrey

To mature software engineering, we must learn from history, and to learn from history, we must define what we do when we develop software and how we do it. When we produce a process specification and define measures for the key process parame-ters, we are beginning to build the basis for reliably and consistently recording and learning from history. That is why the process revolution is so important.

from CrossTalk, August 2008

Posted in Uncategorized | Leave a comment