Agile Otter Blog

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

How to use  microphones (pay special attention to (3) and (12)!!!! : NEVER NEVER NEVER point your microphone at a speaker. Not even accidentally. Don't drop your hands so the mic points at the on-stage speakers. Don't walk in front of a loudspeaker while holding a mic. The feedback will be piercing and can damage the system (as well as the audience's hearing)! If you are afraid of feedback, hold the mic closer to your face . The further away you hold it, the more the sound person has to raise the sensitivity of the mic (making feedback more likely). Don't cup the head of the mic. Cupping causes feedback, for technical reasons -- just don't do it. It is okay to hear yourself; it means others can hear you. That's what the mic is for. Let the sound engineer make any necessary volume adjustments. Now that you are hearing yourself, you can adjust your pitch and pronunciation to sound better through the sound system. If you're singing, you will hear your own pitc...

Imagine I have to work in an unfamiliar and tough passage of code. Unprofitable Code I spend time and effort to puzzle it out, and all I get from it is that now I understand that tough passage. If it was written in the most primitive way possible, using no interesting language or library features (which might have made it less puzzling) then it is unprofitable .  I have invested my time in "playing computer," simulating every line of code and tracking each value in my head, or perhaps I walked through every line and watched every variable in a debugger.  I have expended this effort of will and focus but received little in return. I know what this bit of code is doing (for now) but I won't be any faster to write or read other code because of it. That knowledge will be lost in months, possibly weeks or days. The unprofitable code, left in its original form, will require as much effort next year as it did this time. It is a productivity speed bump. Profitable Code OTOH, if I...

 I've done it. You've seen me. You've done it. I watched you do it. We've probably argued about it. The Defining Dysfunctions I published a blog post some time ago on the Industrial Logic website about programming together vs programming under surveillance. It's a relatively simple piece, and it identifies a problem we have in the world when it comes to just about any technique or discipline. When I suggested that people mistake group programming for working under surveillance, an incredulous reader exclaimed  “How could it possibly be anything else!?” So here's the thing: a person had a bad experience where instead of actually researching what pair programming is and how it works, they just sat down at a keyboard with another person and tried "doing pair programming" without any pre-study or preparation. They ended with one person bored, watching the other program.   This is a widely-known dysfunction or "failure pattern" known as "Work...

Some article links related to solo vs group, flow, productivity, and predictability. Stop using Per-Person Swimlanes Swarming Pitfalls of solo work Programming Under Surveillance , or in groups? Faster and More Predictable Managing Interruption s Work To Be Interruptible Scatter-Gather software development What is your First Time Through ratio? Squeezing Vs Slicing Managing Programmer Productivity Over-Starting and Under-finishing