Agile Otter Blog

When programmers complain about the "pressure to produce more," I usually describe this as a positive thing. Programmers, managers, software companies, and consumers all want more and better software. It is the basic axiom of our field. When I say "if I could find a way to produce 10 times as much quality software in a day, I would do it in a heartbeat," all the programmers' heads nod in violent agreement. Most of us came to this field because we really like writing programs, solving problems, and making things work.  Learning algorithms and data structures was a small part of the answer, as was learning programming languages and idioms. But the underlying drive is still to make things that work using logic and flow and structure and all the IQ we can muster. We build because we love to build. There is more than productivity to consider in software, such as building the right thing (product management), and building things well (craftsmanship), but produc...

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

Agile is not against documentation. It is merely lean, in that we don't want to maintain piles of documentation that don't actually help us product value for customers. We maintain the least non-test, non-code documentation we can afford. To be minimalist, we recognize that a conversation is better than a whiteboard, a whiteboard a poster is better than a white paper, a white paper is better than a tome -- provided it's enough for us to be able to produce good, working code and collaborate. Here are all the rules I know about agile documentation: If the document is contractually required, of course we do it. If the need is immediate and significant we create a document (UncleBob's law). In other words, we don't build documents in case someone needs them in the future, and we don't draw a document when a conversation or whiteboard will do.  There might be other rules. To date, I don't know them.

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

The part of the effort-over-time we know from studies is that illness and  fatality  are  clearly influenced  by effort over time. We find that overtime tends to reduce true productivity, though it tends to increase raw metrics of output. According to the  Scheduled Overtime and Labor Productivity: Quantitative Analysis ,  the most commonly reported factor is worker fatigue, both mental and physical. Ron Jeffries also noted in  his article on sustainable pace  that: A common effect of putting teams under pressure is that they will reduce their concentration on quality and focus instead on “just banging out code”. They’ll hunker down, stop helping each other   so much, reduce testing, reduce refactoring, and generally revert to just coding. The impact of this is completely predictable: defect injection goes way up, code quality goes way down, progress measured in terms of net working features drops substantially. From my own article,...

Dr. Tsuda is saying that Western industry is satisfied to improve quality to a level where visible figures may shed doubt about the economic benefit of further improvement. As someone enquired, “How low may we go in quality without losing customers?” This question packs a mountain of misunderstanding into a few choice words. It is typical of management’s misunderstanding in America. In contrast, the Japanese go right ahead and improve the process without regard to figures. They thus improve productivity, decrease costs, and capture the market. Deming, W. Edwards (2011-11-09). Out of the Crisis (p. 2). MIT Press. Kindle Edition.