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

Do you remember all those rushed changes that your developers implemented three years ago, and how they complained about the design damage they caused to make that happen? It's all still in the codebase. It never disappears. You may have forgotten it, but they still live with it every day. I'm not saying you were wrong to be in a hurry then; I'm only saying it's not over It Does Not Heal Itself In engineering, software or otherwise, whatever decision we make this month, we have to live with it from now on, or until someone invests additional time in reversing it. That hack is as permanent a part of the product as any well-considered change.  It doesn't refresh with the next month, quarter, or planning period. it doesn't fade away. It doesn't heal. There is no end-of-period reset.  Making new goals doesn't remove the baggage of prior goals. Do the other people have to live with January 2013 for the rest of their lives? Or is it only engineering that has...

There are many ways to collaborate, and pair programming is the first many people consider.  It's a useful practice, though it can be emotionally intense compared to other ways of work like mob programming AKA teaming AKA ensemble, or swarming. It's easier for people like me to work with three partners than only one. The fact that other ways exist in no way diminishes the value of pair programming, and if you aren't able or aren't allowed to go to a more inclusive collaborative technique, pair programming is a great way to work. That is, if you're doing it correctly and don't fall into the key dysfunctions... Here are the resources: BASICS Jeff and I wrote  The ABCs of Pair Programming  to help you get started. Vitaly Sharovetov's  Guide to Pair Programming  might be more your style; it's pretty good! Dragan takes us  from Async Code Reviews to Co-Creation Patterns  with Ben Linders. All I Need To Know About Pair Programming, I Learned In Kindergarten...

Sometimes the argument is made that not estimating is irresponsible . I understand why people say it. I don't necessarily agree. It is arguable that relying on developer estimates is at least as irresponsible. There are interesting counterarguments that I'll summarize here. But First, This: Many arguments lean on "managers need accurate and precise estimates" but if those don't exist, it seems irresponsible to depend on them. Would you build your entire company's operating system on Unicorn Poop? That companies are in business despite needing more accuracy and precision than they get suggests that maybe the pinpoint accuracy isn't as important as we let on. "Before buying a thing, I need to know the cost!" say some. Software development isn't like "buying a thing." It is a collaborative development project. It can't be what it isn't. It needs ongoing management involvement. I don't expect the above paragraphs to put t...