Agile Otter Blog

If we want to see a greater theory of productivity , we have to recognize first that software development is thinking.  Once we get there, we need to understand how we can think better. One aid is to have more information  so that we know what to do . In the 1926 book  The Art of Thought , Graham Wallas explained that having an idea (a creative solution) requires four distinct phases or steps: Preparation (gathering of theory and data) Incubation (letting the idea "cook" by doing something unrelated) Enlightenment (the emerging of an idea, or "connection") Verification (determining the validity of the idea) Wallas noted that stages 1 and 4 may take minutes, hours, days, years, or decades. We are primarily interested in those that work on the sub-week scale when programming, but the fact remains that we need to allow the brain to work by feeding it information, giving it some time to process, and then verifying the ideas as they come. Wallas refers to the ...

There are some special challenges with dealing with productivity of knowledge workers. Most of them have to do with the invisibility of the work and the difficulty in managing invisible work. Programmers and testers don't assemble machinery or bend paperclips or mold parts from molten goo. They don't stack boxes or bricks, or swing hammers. The work they do has no physical manifestation, which makes it both hard to observe and hard to understand. I don't blame managers in the 70s and 80s who counted lines of code. It was one of the few visible manifestations of the work programmers do. It was entirely misguided of course, and several of us have experienced net-negative lines of code in consecutive weeks of work (I've even had awkward and unpleasant meetings with managers for "messing up the metrics," ending in an admonition to stop it). Other attempts to make the work visible count data fields on screens and in databases and on reports. This is a bit...

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. -- "The Retrospective Prime Directive" by Norm Kerth Software, as Dr. Ralph Johnson informed us, is distilled experience. Writing software, Ray Scheufler reminds us, is a process of making decisions. To make decisions, we have to understand the system we're working in, and the consequences of our decisions. That means that most of the work of a programmer is learning, and very little of it actually involves typing. Understanding any existing body of software is involves understanding the domain,  the user being served,  the specific problem being solved,  the solution chosen,  the techniques of safe software development,  the organization producing the project, and  the technology (language, operating system, network...

Queuing  If only one person on the team understands the database, then any work done by other programmers that affects the design of the database must wait up for the one competent individual.  Sometimes that queuing becomes significant and impedes the group. If the expert is not available, the work must wait, or else be done in an inexpert way. Loss Experts can go away. Teams euphemistically refer to this phenomenon as the "bus number" of the team -- the number of people who, if they were hit and killed by a bus, would doom the entire project to failure.  A "bus number" of one is an unacceptable risk. A bus number of 10 represents a well-mitigated loss-of-knowledge risk. Thankfully, few developers are hit by buses in the street. Instead, experts tend to be hired away by competitors or companies working in entirely unrelated industries. When this happens, teams do their best to muddle along, sometimes making poor decisions along the way and damag...