Friday, July 26, 2013

Three Steps to Safer Development

Eric Ries has suggestions on why/how to move your engineering practice forward and gain speed and reliability while you're at it:

So how can I help the engineering manager in pain? Here's my diagnosis of his problem:
  • He has some automated tests, but his team doesn't have a continuous integration server or practice TDD. Hence, the tests tend to go stale, or are themselves intermittent.
  • No amount of fixing is making any difference, because the fixes aren't pinned in place by tests, so they get dwarfed by the new defects being introduced with new features. It's a treadmill situation - they have to run faster and faster just to stay at the level of quality/features they're at today.
  • The team can't get permission from the business leaders to get "extra time" for fixing. This is because the are constantly telling them that features are done as soon as they can see them in the product. Because there are no tests for new features (or operational alerts for the production code), the code that supports those new features could go bad at any moment. If the business leaders were told "this feature is done, but only for an indeterminate amount of time, after which it may stop working suddenly" they would not be so eager to move on to the next new feature.

Sound familiar?


Read The Engineering Manager's Lament 

No comments:

Post a Comment