A Tale of Two Agilists

This is a continuation of my attempt to deepen my understanding of life before and after I encountered those with an agile mindset in 1997, two years before Martin Fowler's Refactoring book was published and four years before the Agile Manifesto was written. Specifically, this will be a comparison of how Frank seems to operate and how I have operated in the 14 years since I met him, with the pros and cons of each approach.

Wherever he goes, there is often an extraordinary group of developers and architects who congregate. They're great to begin with, and, when they encounter bad design / bad code / bad smells they start howling and bashing heads. Any offenders promptly fall into line, and suddenly, you're staring at a well oiled piece of machinery slicing through the water like a great white on the prowl. At least, until the next time someone stumbles on something stinky, and starts howling again. I do the same with myself in that as soon as I see something I don't like in my own code, I will refactor it. I do this all day long.

The difference is when someone starts to head down a path I suspect may be the wrong direction. The approach I will take is as follows. I will say something, and if we are able to have a discussion on the matter, then wonderful, we usually both end up learning something from it.

If, on the other hand, I feel as if someone is speeding toward a brick wall at 200 mph, I try and say something, and that person gives me a huge grin and says: “no problem! I've got it all under control!” then I will shrug my shoulders and move on. I know what I am like when I am not ready to listen to something, and I imagine other people are no different. I won't get between a person's actions and the resulting consequences if they aren't ready to hear what I have to say. The only thing that happens then is the other person gets mad at me, and rightfully so, even if a part of them may realize I am right. I am stopping them from learning something, and they have to get there in their own way. So I won't get between a person's actions and the resulting consequences, and, I take full responsibility for the consequences of my own actions.

Because I prefer to keep myself on a short leash, I rarely get into trouble, and my designs and code tend to be fairly simple and robust. So when others start to head down a path and I don't agree with it or understand it, my thought is: if you want to head there that's your business, not mine. There are a lot of different ways to skin a cat, who's to say you don't know what you're doing? But once someone gets into trouble, sometimes it's hard to help, because I would never have gone there to begin with.

Then it's one baby step at a time, with Subversion and snapshots all along the way, and tests to validate that changes in structure did not change the testable behavior of the code. It's doable, it's just that it ends up taking a lot longer than had it been done right to begin with

Why do things get so far out of hand? Because there are so many gifted developers out there who can build a Taj Mahal on a foundation of toothpicks faster than I can recite the design principles in the Agile PPP book.

Here is something else that just occurred to me. Throughout the 14 years I've known Frank, I've heard a fairly steady stream of complaints that he whines like a little old woman, and then delivers anyway. Which I find amusing.

It is Because he whines and complains like a little old woman, stays conservative, keeps himself on a short leash, is relentless and merciless about following the refactoring/agile/clean code principles – it is That which enables him consistently to deliver to a roadmap, with no rework necessary, on time, and in budget.

Whereas for those who laugh at him, smile and say "yeah! No problem!" I can both see and hear the fallout. Ding! Ding! Ding! That is the sound of alerts, of one incoming JIRA issue after another after another, ad nauseum. Death by a thousand mosquito bites.

Everyone needs to sit down and read Refactoring, Agile Principles, and Clean Code.