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