Agile Programming: Why Bother?

I’m working on a series of posts that outline a book’s worth of suggested curriculum on how to learn some of the technical practices that Agile Programming involves. The first post is here.

The Myth of Affordable Technical Debt

Along the way, I’ve re-discovered that too, too many software professionals still misunderstand, fundamentally, what Agile Programming and Software Craftsmanship are about, and why we bother with them. So I’m summarizing my view on that here. I’m not recapitulating the history now (later, perhaps). I’m just trying to gently make the case that sufficient long-term quality is something we can never not-afford.

In the heat of the production pressure to get a User Story out the door by hook or by crook, the discussion about “how much craftsmanship can we afford here” does keep arising (with the best intentions on all sides, no doubt). That’s my context for how and why programmers should learn deep craft. I suggest that almost no-one in software is ready to ask that question.

By Agile Programming, I Do Mean Computer Programming

My definition of Agile Programming is computer programming done at a high level of craft. (Note that in this series of posts, I am not talking about the entire superset of Agile Software Development practices and principles, some of which are technical, and some of which are not.)

Another definition of Agile Programming is Clean Code. These are ways to think about what it is. But why do we do it? It really is all about the smoothest flow of value through the code and the team. It is about highest ROI, and lowest TCO. Put another way:

Any programming practice or choice that does not make or save money for someone, somewhere, someday is not agile, and is not software craftsmanship.

Truly: Why Do we Bother? Are we Being Quality Fanatics?

We are not being fanatics. We are avoiding lots and lots of pain.

To a new regular-army combatant fresh to Guadalcanal in 1942, it may appear that the combat-veteran marines are completely obsessive-compulsive about cleaning their weapons. That’s because those fresh arrivals have not had their weapons jam frequently enough in heated enough battle in a nasty jungle. Field stripping a weapon in a way that appears obsessive and fanatic is just pain prevention. Pure and simple.

The idea of the high software craft inherent in true Agile Programming is to provide exactly, and only, the highest short-term ROI and long-term ROI, and the lowest short-term and long-term TCO for a codebase as simply another asset to be managed (around which, for example,  CAPEX and OPEX expenditures must be carefully predicted and managed these days).

Too frequently, we are asked to build straw houses when only brick houses will do, and we have no way of making it clear how false an economy this is. In a comment thread on a great blog post of a friend of mine’s, the debate rages about, essentially, the economics of Clean Code (“CC”) versus Quick and Dirty (“QD”).

Two things: I have frequently found that the advocates of QD have not bothered to learn CC deeply. They are arguing from at least partial ignorance and fear. (That is not true, BTW, of Naresh Jain, who is a very advanced Agile Programmer.) If you really are as good at Agile Programming as Josh Kerievsky, or Ron Jeffries, or Mike Hill, or Naresh Jain, then yeah, I’m willing to have User-Story-specific discussions about specific short-term “speed vs quality” tradeoffs. Otherwise, I’m not willing to have that discussion with you. All these guys have spent more than 10,000 hours test-driving. Once you’ve done that, let’s talk about CC vs QD again.

Only if you are deeply, deeply expert at test-driving clean code does it make sense for you to talk about breaking the rules. Only then do you have a feel, and deep knowledge about, the rules for breaking the rules.

The other thing is that QD experts (the Duct-Tape Programmer) are not taking long-term ROI and TCO into account fully enough. Yes, I want to ship product as regularly and quickly as I possibly can, with least thumb-twiddling. But no, I don’t want an asset in my portfolio made of duct tape and WD40. What’s the duty cycle on that thing? One release? Two?

The QD experts are arguing that QD works for a User Story, or an Iteration, or a Release. Well, yeah, you can have a roof over your head faster if you build with straw. So what? Is that a way of saying “I don’t believe in storms.” ? In the specific context of getting good-enough releases out the door for startup ventures, are we making it clear enough when we are distinguishing between prototypes designed to win investment capital, and production code designed to live for 25 releases?

The questions “How much craftsmanship can we afford for this Iteration? or this Release? or this User Story?”,  when asked about anything but spikes or prototypes, are nearly always premised in false economy.

As my friend Dave LeBlanc says: Later == Never. You will never be able to “Refactor” your straw house into a brick house. It will need to be rebuilt from scratch, eventually. Factor this into your ROI and TCO estimates. Oh, again, in the context of CC vs QD for startups, there is another sad corollary I’ve seen borne out time after time:

Every prototype ships, and becomes long-term production code. Especially for boot-strapped startups, whose investors will not agree to purchase or fund prototypes.

High software craft, Agile Programming, are not knob polishing, or gold plating. Agile Programming is about getting it right the first time, and getting it right over and over again. It is about optimizing the long-term return on an investment.

How come our codebases cannot last as long as our best cars? Why do most codebases that have not exhausted their business value end up going through expensive, dangerous rewrites?  Aren’t these rewrites fundamentally avoidable? You bet they are.

The fundamental unit of waste in software development is also the fundamental unit of denial: the gigantic codebase rewrite.

We can do much, much better than that. That’s what Agile Programming and software craft is about.

This level of dedication to quality is very much like Honda dedication to quality. It’s not about burlwood on the dashboard, or spoilers on the trunk, or pinstripes down the sides (though if you want those in the GUI, we can do that too, as in an Infiniti). It’s about a 300,000-mile-duty-cycle drivetrain, come hell or high water. It’s about the industry growing out of its addiction to rewriting business-valuable codebases after a few releases, because we can’t work them anymore.

How many 1993 Chevies does anyone in Michigan see out there on the roads, still purring along with few issues? Few. But you know what? There are still lots of 1993 Toyota Camries out there on these snowy, badly-maintained roads. Until recently I drove one every day (and I still own it as a spare-loaner-beater). It’s a little dinged up. And the AC just gave out (after 18 years!). But it also still starts in 6 degree weather, and runs smooth at 80mph, and gets 30mpg. Because those Camries were made with highest long-term ROI and lowest long-term TCO in mind.

So, throughout the series of “How To” posts, please keep this definition of the what and why of Agile Programming in mind.

I am a Member of a Community of Thinkers

Jean Tabaka and others devised this statement, and I love it. I heartily endorse it. To my mind, community provides the best mechanism for continuous learning, for continuous improvement, and for whatever safety we can expect from the world. Were I asked, I would add the meme of Network Weaving as an essential evolutionary mechanism for any community of thinkers, but that’s just the hippie in me.

Well done Jean, Liz, Eric, and others. Good stuff:

A Community of Thinkers

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

  • reflect and honor the practitioners who make its existence possible;
  • provide an excellent experience for its members;
  • support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
  • exemplify, as a body, the professional and humane behavior of its members;
  • engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
  • embrace newcomers to the community openly and to celebrate ongoing journeys; and
  • thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under aCreative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

Coaching Birds, Bats, and Squirrels from the House

Ever Had a Client Stuck in a Nasty Situation?
Ever Had a Bird Trapped in Your House?

I’ve had both. In both cases, I learned not to mess up in the following way: trying to grab the bird and toss it out of the house. Birds hate that, and are really skillful at resisting the attempt. You or the bird can also get badly injured that way.

As a Shu-level, novice coach, I did the classic wrong-headed stuff, and still work hard to resist temptations to do the same stuff: pushing, pulling, badgering the client from a bad situation to a good one. It really is like chasing a bird around the house, brandishing a tennis racket. (Note to self: No!)

Releasing Attachment to the Outcome

We cannot truly control whether, indeed, the bird leaves the house, much less how fast or how well. There are no shortcuts for us or the bird. We can, however, strongly influence how the whole thing unfolds.

It really does have to be the bird’s idea to leave the house, if it will ever in fact happen. This may take a few seconds, a few minutes, a few hours (a few weeks! a few months!  a few years!). Take your time.

Those of us who have (as I have) released birds, bats, and squirrels from the house have learned (A) how to open and close doors, and leave seed trails, in a way that invites the unhappy bird or squirrel out of the house; and (B) patience. With one bat, who flew along walls at 2″ from the wall, straight to each corner, then turned an abrupt 90-degree turn at the next corner, over and over, in perfect silence, it really took awhile. That bat took 30 minutes to notice that there was a door open along one of those walls (if the door had opened in, instead of out, it might have taken 1 minute).

When he finally flew through it, I pounced up and shut that door, preventing regression. I had been sitting there, drinking a beer, and tracking him as he flew these perfectly rectangular room circuits (not easy: bats indoors are flying about as fast as your neck muscles will allow your head to pivot).

Once he had found that first door, he seemed to sense that other open doors were good things, and flew straight through the remaining rooms out to freedom, bugs, and no doubt a well-earned nap. In classic coaching fashion, I had reached that tipping point where I had won enough trust to say goodbye.

Close Some Doors, Open Others

If you close doors to the inner part of the house (example: removing folks from their cubes and placing them in open workspaces, or not engaging in thermonuclear email exchanges about the New Agile Initiative),  you can invite clients to not worsen their situation.

If you open other doors and windows to the great agile outdoors, you invite clients to try inviting, healthy, addictively fun, cool new things (example: tweaking the card wall to reveal blockages or gaps in value flow; helping clients write their first few storytests).

Asking Gently Provocative Questions: Opening Windows in the Mind

By this, I don’t mean “Where the hell are all of your unit tests”?  (BTW, you know the question I REALLY don’t mean?  It’s this one:  ”Don’t you realize testability is vastly more crucial than encapsulation, you dolt?”)

I mean, instead, questions like “Has Rob paired with Lily recently?”  or “How did method-level cyclomatic complexity change this past iteration?”  or “How do you think that business verification went?” or “What do you think about the size of that test?” or “What do you think of that class name?” or “Did we see this retrospective improvement item in the last retrospective?” or “What do you really enjoy doing most on the team?”

If the Bird Blogs About How Cleverly I Let Him Out of the House,
I Probably Messed Up

The best of my personal coaches model for me, and counsel to me, the art of the client never discovering that the great idea was not originally theirs. Smart subordinates have been leading their managers from below in this fashion since the dawn of command and control, no doubt.

Not only is it OK, in a coaching position, to be a peer-to-peer influencer, as opposed to a top-down manager, it is typically preferable. People who I coach end up taking leaps of faith and trying scary new things, in good faith, not because anyone, including me, commands them to do them, or to try them. They do so because they trust me, like me, respect me, and happen to have had this cool idea pop spontaneously into their heads, unbidden.

The coaches I most respect, and most seek to work with, are those who help me as I refine my Ha and Ri in this coaching by question, coaching by seed trail, coaching by patient, engaged, gently provocative observation.

If you see me badgering someone to just shut up and do this Super Advanced Best Agile Practice Thing, please bust me on it. I will likely thank you (eventually, anyway).

Agile Team Lead : Useful New Role?

My pal Abby Fichtner, the HackerChick, blogged today about emerging agile team leadership patterns and practices, as had been reinforced for her by a recent presentation by David Spann. She lists beliefs and behaviors that, according to Spann, when held by whomever actually manages an agile team, tend to help or tend to hurt. These resonated with me strongly.

Premise: It Ain’t Project Management

Meanwhile, coincidentally, I had been in conversations for the last week with stakeholders about how, in an agile transition, old patterns of Project Management are not a good fit. Traditional Project Managers are typically insufficiently team-focused and insufficiently portfolio-focused, while too top-down and imperative. Agile teams and systems have long lifecycles and broadening authority and responsibility that traditional Project Managers cannot typically see. With all due respect to Spann (with whom I think I agree nearly entirely), I would claim that, adaptive or not, neither the adjective “Project” nor the noun “Manager” helps the person trying to lead an agile team. The old culture and terminology are equally misplaced in an emerging agile world.

So, true, the agile community has not had great answers to questions about who leads and manages agile teams, much less how. So, last week, when I was asked by my best Pillar pal and mentor what the main responsibility, the main tools, and the guiding principle of agile team leadership might be, I realized, after some reflection, that I have been baking these in my head for awhile, semi-consciously. David Spann and Abby Fichtner helped me bake them a bit further.

Premise: It Ain’t Tech Leadership

The Agile Team Lead (for lack of a better role term) is not the tech lead. Many teams need formal technical leadership; many teams may grow out of this, into a pattern of entirely emergent tech leadership and architecture. In any case, the tech lead role is not the right role (nor is it typically, as Abby implies, the right skills match or personality-type match) for team leadership overall.

Premise: It Ain’t Scrum Master

As Abby claims at the start of her post, focus on methodology alone, even while there is frequently a temporary place for a certain style of such coaching, is again not the right focus for an Agile Team Lead. This is another focus that is too narrow, and too short. The team should outlive its Scrum Master by years; that may be a measure of a Scrum Master’s skill: the ability to leave the team in a cohesive and self-improving state. No, process coaching is not exactly agile team leadership either.

Look!  A Man with Nine Legs! Oh Bloody Hell, He Ran Away

We need something “completely different,” however rare, in our Agile Team Lead. Here are the things I now want:

Overarching Responsibility: Optimizing Flow of Business Value

In whatever ways a team improves: technical, interpersonal, process, practice, attitude, morale — we can measure and express them in how business value is delivered more and more efficiently, easily, steadily, skillfully, and (I’ve seen it) joyfully. The Agile Team Lead can trace all improvements back to how well the team delivers ROI and reduces code asset TCO, and back to how delighted the customer and team both are. The Agile Team Lead is in the business of knocking the customer’s socks off, over and over again.

Four Main Tools

The Agile Team Lead optimizes business value flow mainly with four varieties of tactic:

  1. Continuous Team Building — this includes all of the soft, fuzzy means Spann lists, whose ends are team cohesion, high ambient trust, high ambient respect, high morale, good humor, equanimity, close interpersonal connection. In Jazz, musicians talk about a band having so much groove that everyone can read everyone else’s mind. Reinforcing that is the Agile Team Lead’s link inward toward the team (bear with my link metaphor here for a few more paragraphs).
  2. Continuous Planning — for current purposes, I mean by this all of the agile practices and patterns around eliciting, analyzing, scoping, dividing, prioritizing, iterating, planning, testing, tracking, publishing, and delivering. The Agile Team Lead does not perform all of these practices solo, but leads their performance. This is how the Agile Team Lead is held to account by all managers and stakeholders outside the team. This is the outward link from the team to the world.
  3. Continuous Unblocking — teams continuously need outside help, resources, more team members, fewer team members, and other emergent support that they, as a team, lack the authority to achieve. The Agile Team Lead does the heavy corporate lifting to get these deals swung, to keep the team in steady flow. This is the link from the outside world back to the team.
  4. Continuous Improvement — The Agile Team Lead guides, without pushing, the zillion varieties of retrospective improvements that the team does own the authority to make. This does include holding the team accountable for owning the ever-changing lists of things to be improved, and concrete improvement proposals and plans. Note that this is not the same as coaching, which may need to happen separately. Teams had better outgrow coaching, while they are never likely to outgrow a need for leadership. These are the links from the team back to itself.

Guiding Principle: Servant Leadership

The leaders most admired in the agile community and software community, as in the world at large, are those who lead by giving and supporting. This is classically the root cause of a graduation from “good” to “great.”

And we are learning that it is simply the most effective variety of leadership and management: collaborative, listening, deeply present, deeply respectful, enthusiastic, inspiring, supportive, celebratory. And certainly trusted and adaptive, as Spann claims.

The Servant Leader attaches identity to the team’s abilities and accomplishments, not just to his or her own. Spann has captured several of the beliefs and concrete behaviors that we can only get from these leaders who lead to serve, not to rule. Indeed, an agile team’s Agile Team Lead must earn the team’s consent to be lead. Mature self-organizing teams eventually outgrow structural, imperative command and control, imposed by fiat.

Doesn’t it seem sometimes that the whole technical world is trying to go collaborative, trust-community, peer-to-peer? Aren’t these same patterns emerging everywhere, in different bits and bobs? Certainly it feels that way to me. Flat is the new hierarchy; village is the new city; conversation is the new document; trust is the new currency; small is the new big.


That’s my sketch so far: the Agile Team Lead, through the lense of Servant Leadership, uses Continuous Team Building, Continuous Planning, Continuous Unblocking, and Continuous Improvement to optimize how business value flows through the team.

I am still baking this one; your feedback is appreciated.

CodeRetreat #2 Outdoes #1, by a lot

CodeRetreat #1 set a pretty high standard for fun, learning, engagement, connection, and community building. CodeRetreat#2 at LeanDog blew that standard away.

More people showed up. More passion and creativity and humor showed up. Corey Haines and J.B. Rainsberger showed up again (and J.B. brought his wife Sarah), and Cheezy showed up. Chris Judd and James Shingler (the Groovy/Grails guys) showed up. Jon Stahl and his wife Deb prepared awesome food all day. The sun and the seagulls were out; the boat was a lovely, expansive work/play space. Lots of room to extemporize, come together, break apart again, project our mob programming experiments.

We had our schtick down better. We did Java Conway’s Game of Life kata/turtles all the way down. We ping-pong-paired more and more throughout the day. The retrospectives were long, and rich with feedback, humor, and (in the afternoon) micro-brews.

J.B. and Corey performed a Game of Life test-drive that was thought-provoking, hilarious, and quite crowd-interactive. Jim and Chris followed with a rather crowd-hushing port of J.B and Corey’s work to Groovy. Sighs and gulps all around. Nothing like seeing the same test cases in Groovy and Java to re-sensitize you to Java’s nasty noisy gunk. I’d love for us to repeat that at CodeRetreat #3.

CodeRetreat #3 will likely be in Columbus, OH sometime in May, co-sponsored by Pillar and LeanDog. We’ll take care not to collide with the several other Columbus and Cleveland tech events in May.  #4 will likely be in Philly or Montreal, perhaps as early as June; maybe July. Watch the ning site for details.

Thanks so much Jon and Deb and Cheezy for hosting us. Yesterday will be really hard to top, and we’ll have fun trying.

Summary: CodeRetreat #1 Smashing Success

Yay Team

Man, did we have fun at the first CodeRetreat in Ann Arbor, MI, sponsored by Pillar Technology. We had 25 or so programmers show up, including 5 dedicated software craftsmen who assisted me as Master Rabble Rousers for the event. So special thanks indeed to Ron Jeffries, Chet Hendrickson, Corey Haines, Bill Wake, and the guy who (of course) stole the show, J.B. Rainsberger.  J.B. flew down from approximately the North Pole on his own dime. He had, like, seven connecting flights. He was wearing a full beard and long hair, because where he lives, if you don’t do that, you die.There was lots of pairing, lots of discussion, a very cool String templatizer Kata performance in Ruby by Corey Haines. There were beers and brainstorming and stupid geek tricks at Bar Louie’s afterwards till late. I’ve made a couple of animotos of the event here and here.

Learning Outcomes (as they say)

So, we learned that we want to do this on a regular basis: several times per year, per region that adopts it. That’s our immediate goal.We learned not to use nasty little legacy Java applets as starting points. (What is it with me and nasty little legacy Java applets? Bad old Java karma, I expect.) We learned to spend each CodeRetreat event on a single language. Splitting the first one into Java and Ruby involved too much thrash and context switching, and did not focus us all on craft as much as we had wanted. Too many were not fully engaged in honing craft, enough of the time. I felt their pain. The next CodeRetreat event, at least, will be entirely in Java.

 Kata All the Way Down

We also learned that we want to concentrate the next few CodeRetreats on repeating the same exercise again and again, Kata-style. We’ll likely adopt Conway’s Game of Life as our standard exercise. We can adopt more if we choose to later.  Let’s see how well this one serves us as a craft-focused, learning sandbox. We can still mix up the session design around the way we do that Kata. But we agreed we’ll dive deeply for awhile together into that problem domain and potential implementations. We’ll get that one completely “under the fingers.”

CodeRetreat #2: Saturday, March 14, 2009: LeanDog, Cleveland

Just got the go-ahead from my pal Jon Stahl that his consultancy, LeanDog Software will be hosting our next CodeRetreat on his cool headquarters-boat on Lake Erie, some Saturday (TBD) in March of 09. Again: this one will be wall-to-wall Game of Life in Java. Other details will be emergent. Our primary texts, where craft is concerned, are Bob Martin’s Clean Code, Fowler’s Refactoring, and Lasse Koskela’s Test Driven. We might switch them up a bit, but we’ll try to stick to three reference works at a time, for a good long while.

Stay Tuned

If you want to start a CodeRetreat in your region (we are concentrating for now on MI and OH), please contact me, and I will help you set it up if I can. I have had interest in the Philly suburbs in hosting one at Ternary Software, for example.If you want to attend another of our MI/OH CodeRetreats, please watch the ning site.  Well, watch the site anyway. I think CodeRetreat is a meme that can spread. If not, it will not be for lack of stubbornness on my part.

The “E” Word, Part 3: Uncle Bob’s Clean Code Book

Learning Happens

No matter what happens, learning happens. I say this a lot. As many of you know, I joined the agile community way behind the OO-developer-competence 8-ball years ago. I had done lots of procedural programming in the small, but I had had poor instruction overall, and I was not learning OO well on my own. A learning-style thing, I suspect. I had done a fair bit of low-craft Java code, under the loose instruction of folk who waved Bruce Eckels books at me and said “Polymorphism! Prefer composition to inheritance! Encapsulation!”. I tried hard, but I was incapable so far, apparently, of really thinking in OO. To be fair, I had also been doing lots of other things: writing, managing, UI design, marketing, sales, training, QA, starting new businesses, rabble rousing.

And then, out of the blue, I had my agile epiphany, discovered the agile community of thoughtleaders and fanatics, and I sought out masters of agile programming craft. Oddly (for then), I began to learn OO through the lense of TDD and Refactoring. I discovered, of course, that the agile masters and thoughtleaders had long been masters of OO craft, project automation, programming craft generally. They also tended to be continuous learning masters, continuous improvement masters. They were also passionate about humanity, creativity, and fun in the workplace. They loved to talk and read and write. They were masters of software extensibility (the “E” word of this blog thread). They liked beer. True Masters, in other words. Folks who lived life fully and passionately, whether or not software was involved.

It kept seeming like a good fit for me, and it still does. I will be learning from these folks in my 80s, no doubt. And I just learned a bunch from a handful of them again this past couple of weeks.

Uncle Bob’s New Book

Uncle Bob Martin has a book coming out on Clean Code. It is a condensed version of the strictly code-related principles, guidelines, and standards that are covered in more detail in Agile Software Development: Principles, Patterns, and Practices. I am fortunate to have an advance copy of this book, since I and my odd little TicTacPente codebase are also fortunate to be part of the Agile 2008 Clean Code Clinic.

And I love this little book. Uncle Bob and his work need no additional praise, but I am going to praise them anyway, because you, as a programmer, need this book if you are serious about programming craft, and especially if you are serious about helping others with their programing craft.

Bob and his other Object Mentors (and to some extent, Kent Beck) together produced this condensed, unabashedly opinionated style guide in such a way that it succinctly covers all of the critical aspects of what it means to write clean code: naming, function size and responsibility, function parameter lists, function side effects, Command-Query separation, formatting, comments, exception handling, class structure, class APIs, emergent design, Simple Design, etc. It is a true style guide, not in the sense of coding style (formatting alone), but in the literary sense of guiding our semantic and syntactic decisions. It also refers back to former programming style guides and guides on programming craft, going back 30 years.

Each topic is covered cogently, with great little code samples, and with characteristic Uncle Bob passion and irreverent verve. I laugh out loud with agreement again and again. My guess is you will too.

Hmm. Time for Some Refactoring

So I am reading this awesome book, by this Bob guy, this agile thoughtleader who helped personally introduce me to XP years ago, who will be managing the Clean Code Clinic of which I will shortly be a part. And I realize, you know, my code is close to complying completely with the book’s guidelines.

Close. But you know? Not quite there.

So, with the book electronically in hand, I begin making refactoring passes through my codebase. Some modules are fine as is. Some, not so much. Hmmm.

Ben Franklin (apparently) said “Do not fear mistakes. You will know failure. Continue to reach out.” So I continue to reach out and refactor my little codebase. And I start to realize. Man! I am really improving some of these modules! The resulting 3-line, 5-line, and occasional 8-line methods are way better than their 10-line and 15-line parents. I watch myself improving my class API’s, hiding more implementation details, and replacing dumb getters here and there with more object-appropriate, intention-revealing, behavior-revealing methods. Cool. As I refactor, I am periodically refreshing the current version of the TicTacPente codebase on this site.

Mea Culpa: Permission to Learn, Sir?

So Man! is learning happening as I read, refactor, read, refactor. I have a few rituals I like to do around learning: I like to give myself permission to do it, which means that I must first admit that I don’t know everything already. I like to grant myself the time and safety to undertake the learning, partly for myself, and partly so that others may learn better. (I love to learn partly because I love to teach.) This requires taking a leap of faith that my production schedules and commitments will not fall to pieces if I take the time to learn. And finally I like to celebrate learning and its results.

I do these things because in my professional life, I have been surrounded by insecure know-it-alls, arrogant code cowboys, shy retiring cubicle-hermits, and every other kind of person who could not stand up and boldly say, “You know what? I don’t know the answer to that one. But I would sure like to know!” And in recent years, I have become the guy who, no matter what the circumstances, no matter what I am being paid, will loudly proclaim when I do not know something. Otherwise, I am not asking for, not giving myself, permission to keep learning, and I am also not modeling permission to learn to others. And I love to keep learning so, so much. And I love when others also do.

You are Using a Language to Make a Language

Here is my favorite lesson from this book. OO programming, at the highest level of craft, is about creating a rich DSL (Domain Specific Language). I am not simply implementing logic, or stringing together extensible algorithms and data structures. The packages, interfaces, classes, methods, variables, algorithms — even white-space — all form a language that is extensible according to how understandable it is. I am creating a DSL that reveals, as it implements, a way in which the problem would really like to be solved. A natural and terse way in which the problem can be solved.

I don’t want my DSL to turn out like English, which is really more of a collision than a blend. And I certainly don’t want it to turn out like Java, although I could do worse.

When I focus on the quality of the language I am creating, all of the other guidelines in the book appear what they really are, means to an end, as opposed to ends in themselves. I really like that. It reminds me of Yoga. Yoga, despite its many Westernized versions, is not an end, not something to get good at as sport, or status, or distraction. Yoga is a means, and the ends include health, equanimity, gratitude, affection, peace of mind, humor. Uncle Bob’s guidelines and principles are means toward an end of a requisite little DSL for the problem at hand, whatever that problem happens to be. When I focus on that end, then the means seem to fall more naturally into mind and under my fingers. What a beautiful way to guide a refactoring session. Learning happens. You see why I love these folks? How many books and communities can you learn that kind of insight from?

Clean Code: Upshot

Buy Uncle Bob’s Book. It’s a quick, funny, useful, compelling read, unlike most of the books on agile craft, OO craft, and programming craft. I am organizing most of my software conversations these days around this book. Indeed, so is much of the industry.

And you need to give yourself permission to take the time to read it, to take the time to try its lessons out on some of your code, and to take the time to celebrate how cool it is to have code that clean. This is how we all make progress toward the level of craft at which we always create code this clean. And this is important, because the world contains very, very little code this clean, expressed as a percentage. I have no idea what the actual percentage would be, so I am going to make one up: way less than 1% of the code in the world is this clean. And this matters, because the other 99% is much, much more expensive to maintain and Extend (there’s the E-Word).

Finally, consider coming to Agile 2008 and the Clean Code Clinic, where we are going to use pain and epiphany, courage, outrage, and truth to learn about the real differences between really ugly code and (in my case) at least somewhat clean code.

In the next post, I swear, I’ll return to the TicTacPente problem domain, and what I currently know about 10 x 10, first-to-5-wins Tic Tac Toe.

I keep getting side-tracked by cool, related things. If I am anything about blogging, I am emergent. So sue me.

Why did this take me so long?

I really have no excuse for taking this long to join the zillions of bloggers out there. I have some experiences to share, some music, some poetry. And I am a firm believer in the hilariously explosive zillion-to-zillion overpublishing of the blogosphere. Let us all share our gold, our dross!

So may I follow through with steady posting, daily rants and discoveries, and the journal of my life. If for no other purpose or audience, then for my kids, for whom I expect to have become inscrutable once I am gone. :-)

Kids, you may eventually be able to figure something out about me by digging through this detritus. Far more fruitful, I expect, than digging through my junk drawers.

But the flip language hides something more interesting, and worth exploring in later blogs: why did I procrastinate for so long? Especially for something so straightforward and enjoyable?  Because of old, negative childhood scripts about unworthiness, shame, whatever.

So, launching a blog — just launching it — can be a major accomplishment, even for a geek. It certainly was for me.