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.