Alert! Daniel Kahneman’s new book coming soon!

Thinking, Fast and Slow

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.

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.

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.

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?

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.

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

Sapiens Lacuna (from Vince Lombardi)

“I have never known a really successful man who deep in his heart did not understand the grind, the discipline it takes to win.”

- Vince Lombardi, American Football Coach

A friend sent this in an e-mail. The theme of discipline and hard work keep coming up. Hard work is not enough, it must also be the right kind of work (with attention to execution of a process) but hard work is a necessary component. See Anders Ericsson’s work on Deliberate Practice.

Does it have to work?

Anything that goes with saying is something that someone will go without.

Read Glen Alleman’s post on marking progress to plan. I want to focus on the “What does done look like?” part about meeting operational paramters.

That the product has to work is often implicit, rather than explicit. Glen’s statement makes it explicit. But you also well defined functional and non-adequate funtional specifications. (performance, security, uptime…)

I’ll take it one step further make it even more explicit, working means absense of major or extreme defects. By major I mean it can fail to satisfy functional or non-functional technical specifications. By extreme, I mean the kind of defect that makes me pull the battery out of my mobile phone. By this standard, a large fraction of the products I use regularlly are not “done”. IMO, shipping undone products (without explicit customer agreement) is unprofessional. In some domains, it is criminal.

Carp per diem

On a software development project, he relationship between time and money can be a complex function. That is not to say it’s complicated, but often some of the numbers are imaginary.

Sapiens Lacuna (wise words from Arnold Kling)

from Arnold Kling The methodology flawed

 

My father always said that there were three iron laws of social science.

1. Sometimes it’s this way, and sometimes it’s that way.
2. The data are insufficient.
3. The methodology is flawed.

On politically sensitive topics, the tendency is to apply (3) to the other guy’s methodology, never to your own.

Replace “social science” with software engineering and it’s not far off the mark.

 

The hard questions

were posed recently. I still don’t have easy answers.