Agile Otter Blog

  This is probably too snarky, but bear with me: If I fill my fuel tank with non-fuel or the wrong fuel, it will damage my car and fail to perform. Is that because fueling the car is a bad idea? If fueling a car is a good idea, shouldn't there be a million ways to do it so that it's easy for people? This "petrol only" rule = is too restrictive to be useful in the real world. Every time I put diesel in my petrol vehicle, the mechanic pulling my gas tank and cleaning the fuel lines tells me I'm doing it wrong. Don't they realize there's more than one way? Just because my way consistently fails doesn't make me wrong! Why should all of those elite gate-keepers put down people who choose their own fuels? Why are they so petty and close-minded? Don't you think that people should get to choose to put whatever they like in the gas tank? This top-down mandate by car makers is undemocratic! It's authoritarian! Where is the psychological safety? Who ...

  i will submit that the problem of scale is mostly that you Have to deal with divergent, incompatible SW development paths Might not be able to handle losing fine-grained control of every element of the business. Are likely to accumulate heavy processes with a lot of inherent delay and unpredictability in them. Have to deal with "the law of the 2nd floor" (LO2F) The Law of Two Floors The first few points may be obvious enough to not need explanation, but too few people know the LO2F. Nobody two levels  ABOVE OR BELOW you on the org chart really knows what your days are like. I think this may well be a proper "law" and not just observational comedy. It doesn't happen in the small, scrappy startups where there aren't three levels on the whole org chart, or where the entire programming team can sit in the same conference room. It is a problem of scale. You all have enough production work, customer management, finance, regulatory, and technical work every d...

I'm Tim Ottinger. You may already know me. I'm a long-time developer, agilist, XPer, CI/CD, teaming/ensemble, TDD, and general software delivery specialist. I wrote the second chapter of Clean Code .  I am the originator and co-author of Agile in a Flash with Jeff Langr, and I wrote Use VIM Like a Pro . I'm mentioned in the "acknowledgements" sections of many other books on Code Craft, Agility, Design Patterns, because I’ve been heavily involved in the tech community and have done reviews and edits of their pre-publication materials. I worked with "Uncle Bob" Martin at Object Mentor (twice). With his company, I taught physicists at Stanford Linear Accelerator Center how to improve software design for high-energy physics. I worked with companies like Caterpillar, Xerox, and many others. I worked with Ian Murdoch (who founded the Debian Project) in his company, Progeny Linux Systems . We created software to aid in the creation of custom commercial Linux ...

How much failure demand and rework do you feel is appropriate in your system? Rework in software is the correction of unacceptable code. That doesn't include refactoring, which corrects only the design and expression of ideas without changing what the code does. This is limited to "something does not work correctly and we can't let it be released."  So, we don't want any of that, right? It delays releases and costs money. It distracts developers from doing new feature work. It raises the costs of release. Clearly, this is a bad thing, right? No.  This is a less-obvious question than it first seems.  Obviously, nobody wants to have errors and failures in their system. We would like to see 100% success rates, right?  Well, hold on... Pass Rates How would you feel if your QA/QC department did not report a single defect in the past 3 quarters? Not one! What if all the code reviews passed with "Looks good. Nice work!" and nothing was ever returned for repair?...