Tag Archives: testing

Poppendieck: implementing lean software development

notes from implementing lean sw dev, from concept to cash (amazon.co.uk) , by Poppendieck, ch 2 on infoq
(my emphasis)

Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation. Practices can and should differ as you move from one environment to the next, and they also change as a situation evolves.

Principle 1: Eliminate Waste

A big form of waste in software development is “churn.” … we’ve often encountered “requirements churn” in the 30 percent to 50 percent range, and we’ve seen many test-and-fix cycles that take twice as long as the initial development time. We’ve found that software development churn is always associated with large inventories of partially done work. When requirements are specified long before coding, of course they change. When testing occurs long after coding, test-and-fix churn is inevitable. Unfortunately, these types of churn are often just a precursor to the ever larger churn created by delayed (aka big-bang) integration.
But far and away the biggest source of waste in software development is extra features.

Myth: Early Specification Reduces Waste ….

Principle 2: Build Quality In ….

Myth: The Job of Testing Is to Find Defects ….

Principle 3: Create Knowledge ….

MacCormack has identified four practices that lead to successful software development:
1. Early release of a minimum feature set to customers for evaluation and feedback
2. Daily builds and rapid feedback from integration tests
3. A team and/or leader with the experience and instincts to make good decisions
4. A modular architecture that supports the ability to easily add new features

Myth: Predictions Create Predictability

Predictable outcomes are one of the key expectations that the marketplace imposes on companies and their senior management, and these expectations eventually flow down to software development. Unfortunately, software development has a notorious reputation for being unpredictable, so there is a great deal of pressure to make it more predictable. The paradox is that in our zeal to improve the predictability of software development, we have institutionalized practices that have had the opposite effect. We create a plan, and then we act on that plan as if it embodies an accurate prediction of the future. Because we assume that our predictions are fact, we tend to make early decisions that lock us into a course of action that is difficult to change. Thus, we lose our capability to respond to change when our predictions turn out to be inaccurate. The solution to this problem, it would seem, is to make more accurate predictions.

We forget that the predictions of the future are always going to be inaccurate if they are 1) complex, 2) detailed, 3) about the distant future, or 4) about an uncertain environment. No amount of trying to make these kinds of predictions more accurate is going to do much good. There are, however, well-proven ways to create reliable outcomes even if we cannot start with accurate predictions. The idea is to stop acting as if our predictions of the future are fact rather than forecast. Instead, we need to reduce our response time so we can respond correctly to events as they unfold. In order to increase the predictability of outcomes, we need to decrease the amount of speculation that goes into making decisions. Decisions that are based on facts, rather than forecasts, produce the most predictable results.

Principle 4: Defer Commitment ….

Myth: Planning Is Commitment

…. But in the commercial world, wise businesses (such as Toyota) realize that sticking to a detailed plan is not healthy, and measuring process capability against ones ability to do so is measuring the wrong thing. Let’s not succumb to the myth that planning is the same thing as making a commitment. We should plan thoughtfully and commit sparingly.

Principle 5: Deliver Fast

Myth: Haste Makes Waste

…. Caution: Don’t equate high speed with hacking. They are worlds apart. A fast-moving development team must have excellent reflexes and a disciplined, stop-the-line culture. The reason for this is clear: You can’t sustain high speed unless you build quality in.

…. There are two ways to achieve high quality. You can slow down and be careful, or you can develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors.

Principle 6: Respect People ….

Myth: There Is One Best Way ….

Principle 7: Optimize the Whole

…. Vicious Circle No. 1 (of course, this would never happen at your company):

  • A customer wants some new features, “yesterday.”
  • Developers hear: Get it done fast, at all costs!
  • Result: Sloppy changes are made to the code base.
  • Result: Complexity of the code base increases.
  • Result: Number of defects in the code base increases.
  • Result: There is an exponential increase in time to add features.

….  outsourced call centers working under the traditional revenue model have no incentive to find and resolve the causes of customer problems.
Crossing organizational boundaries is expensive.  ….

Myth: Optimize By Decomposition

…. People have a tendency to decompose complex situations into small pieces, probably a legacy from the efficiency experts who divided jobs into miniscule tasks. After decomposition, each piece is measured and each measurement is optimized. You would expect that when all of the individual measurements are optimized, then the overall system would be optimized too. But you would be wrong. If you break a value stream into silos and optimize them separately, experience has shown that the overall system will almost certainly be suboptimized.
We can’t measure everything ….


is TDD dead?

UPDATE: A few updates from Martin Fowler:

original note: background:

  • DHH: TDD is dead. Long live testing. “Test-first fundamentalism is …. [a]n unrealistic, ineffective morality campaign for self-loathing and shaming.  It didn’t start out like that.”
  • Kent Beck: RIP TDD “…now I need to hire new techniques to help me solve many of my problems during programming”
  • Martin Fowler: Hangout on TDD… “a series of video hangouts to discuss TDD, and the trade-offs around testing and architecture”
  • Hangout 1 (G+)
  • Hangout 2
a few tweets from hangout 1

watching @dhh, @martinfowler, @KentBeck on #istdddead. 1st @dhh on microtesting all the things, not necessary useful (my words)

basic q: as a programmer, do you deserve to feel confident? @KentBeck (@dhh: programmer happiness) #istdddead #techsafety

i have to have a feedback loop, and the feedback loop has to be repeatable. @KentBeck not mocking much, even when tdd n/a #istdddead

the case for continuous delivery

from www.thoughtworks.com/insights/blog/case-continuous-delivery by @jezhumble (emphasis mine)

many of us are aware of the wide adoption of continuous delivery within companies that treat software development as a strategic capability that provides competitive advantage. [Amazon, Facebook, Google]
Still, many managers and executives remain unconvinced as to the benefits

Continuous delivery is a set of principles and practices to reduce the cost, time, and risk of delivering incremental changes to users.

high performing organizations ship code 30 times faster (and complete these deployments 8,000 times faster), have 50% fewer failed deployments, and restore service 12 times faster than their peers.

Implementing CD has second-order effects that reduce the costs of software development

For me, perhaps the most interesting effect of continuous delivery is the cost reductions it brings about by reducing the amount of time spent on non-value add activities such as integration and deployment. In continuous delivery, we perform the activities that usually follow “dev complete”, such as integration, testing and deployment (at least to test environments) — continuously, throughout the development process.

By doing this, we completely remove the integration and testing phases that typically follow development. This is achieved through automation of the build, deploy, test and release process, which reduces the cost of performing these activities, allowing us to perform them on demand rather than on a scheduled interval. This, in turn, enables effective collaboration between developers, testers, and systems administrators.

This change in process has extremely powerful second-order effects on the economics of the software development process.

my note:

a big part of this is due to reduced delay in the lifetime of a work item, since increased lead/cycle time for work will lead to increased amount of work for the same output, for a variety of reasons.