When I say “Agile” I mean what I think Agile “can be”. This part can become very complicated, so let me outline some things that I mean when I say “Agile”.

  • Not a defined process, but a way for people to discover an appropriate process for them. (Thanks, Alistair Cockburn.)
  • A toolbox of helpful techniques which I sometimes use as a starting point when we don’t know where else to start. (Thanks, Kent Beck, Ron Jeffries, and other early XP authors.)
  • The basic assumption that when we don’t know what else to improve, then we try to earn more value sooner. (Thanks, Mary and Tom Poppendieck.)
  • The basic assumption that learning is the bottleneck in delivering products. (Thanks, Taiichi Ohno and Eli Goldratt, among others.)
  • The basic assumption that what’s good for people will be good for projects, products, and companies. (Thanks, Jerry Weinberg, Tom DeMarco, Tim Lister, Brian Marick, and so many others.)

Q: What is the most often-overlooked risk in software engineering?



A: Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

David Parnas, quoted by Jeff Atwood in Nobody Hates Software More Than Software Developers 

When I want to rescue legacy code, I reach for Mockito. When I want to design for new features, I reach for JMock.

By default, JMock assumes that a test double (a “mock”) expects clients not to invoke anything at any time.

(…)

On the other hand, Mockito assumes that a test double (sadly, also a “mock”) allows clients to invoke anything at any time.

(…)

When I work with legacy code, I mostly write learning tests to discover how different parts of that legacy code behaves. Usually legacy code has obscene and overwhelming levels of interdependency, and Mockito helps me manage that, by allowing me to worry about one crazy dependency at a time.

When I design for new features, I mostly write design tests that describe the new behavior I want to implement. With the nice green field of a new interface, I need JMock to encourage me to clarify the interaction I need. Whenever my production code attempts to use a collaborator, JMock effectively reminds me to ensure that I want that interaction. Most importantly, JMock stops me from introducing dependencies that I don’t need.

(…)

Mockito helps me tolerate high accidental complexity while I work to reduce it.

JMock tries its best to stop me from introducing accidental complexity.

‘Human error’ points to individuals in a complex system.

In complex systems, system behaviour is driven fundamentally by the goals of the system and the system structure.

People provide the flexibility to make it work.

The use and abuse of ‘human error’, Safety Differently via @gleicon

‘Human error’ points to individuals in a complex system.

In complex systems, system behaviour is driven fundamentally by the goals of the system and the system structure.

People provide the flexibility to make it work.

The use and abuse of ‘human error’, Safety Differently via @gleicon