“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”.
“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?
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.
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.
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.
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.
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.
“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?
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.