Sunday, March 21, 2010

Emergent Design

I have just finished reading the book “Emergent Design” by Scott Bain and thought I would do a little review here.

If you read my previous reviews, you might know that I don’t like standard chapters by chapters review, so this one is not going to be exception.

Instead I’m going to start by telling you about the week of training I had with Scott. It assumes a background in software development since I can’t summarize a whole week in two pages without making a lot of shortcuts.

I followed two consecutive trainings, one on Design Patterns and the other on Test-Driven Development (TDD). As you might imagine, these can be pretty dry subjects, especially if you take the simple approach of going through patterns one by one. Fortunately, this is not the way Scott teaches.

Instead, Scott tells a lot of little stories, some about his life as a Software Developer, some about famous authors, even some seemingly irrelevant like the Battle of Azincourt. As you can guess he doesn’t tell these stories for the sake of it: they all are relevant in (sometimes) unexpected ways.

I know that some students wish that it was more technical, but I don’t agree. Us software developers are used to learning things by reading documentation and so on, and quite frankly if I want to learn about Design Pattern, I can do that on my own.

Learning how to make proper use of them however, is an entirely different story and this is where Scott’s way of imparting his experience was hugely beneficial.

As you may well know, design patterns are not a miracle solution. They merely provide a common language for developers, and provide solutions for already encountered problems. But they are not a silver bullet, and will not make you magically write great code.

That’s why Scott also focused on three other things: code qualities (or flaws), principles, and practices. Let me detail.

Code qualities are for example code cohesion, code redundancy (or more precisely the absence thereof), the absence of non-intentional coupling, to name a few.

Principles are for example “Encapsulate by policy, reveal by need” or the open-closed principle.

Finally, Test Driven Development is a practice. “Programming by intention” another one. “Encapsulating constructors” yet another one.

Let’s use the word “practices” as a shortcut for these three categories.

A point that Scott made during the course is that as a profession, we Software Developer don’t have a common set of practices. Other professions do: for example surgeons wash their hands before cutting somebody open.

As a profession, we badly need to establish a set of practices, otherwise we set ourselves for failure. Our lack of practices that can guarantee success is probably the reason why nowadays, marketing drives our planning. Could you imagine going to a surgeon and tell him “Cut me open, do what you have to do, and I need to be out by 5pm”? No. Sadly, this is what happens in software, a situation that in Scott’s opinion (and mine) will only evolve if we start establishing a set of practices.

What is the purpose of these practices? “Guarantee some level of success, or at least prevent failure”, as Scott says. A surgeon that doesn’t wash his hands is going to kill the patient, every time. If he does (wash his hands), he might (hopefully) succeed. So he doesn’t think about it, and washes his hands.

The nice thing is, practices don’t cost anything to apply. Most of us developers know them all already, but maybe we lack of a common framework to apply them consistently and easily.

Scott’s course has provided this framework, and interestingly, faithfully following it has enabled me to produce better designs without even trying. It just seems to “emerge” from the way I code, and more often than not, I end up with a well known pattern without having thought about it.

Giving us a list of practices is not sufficient however, and Scott has also done a great job teaching us how to apply them.

Take TDD for example.

As every developer, I’ve always been convinced of the necessity of proper automated testing. As every developer, I seldom did because I found it very hard to do in practice, for two main reasons: my code was not designed well enough to be easily testable, and I lacked a simple method to write tests.

As I said, “practices” solved the first problem, and Scott provided a simple method that makes writing tests a no brainer.

Recently I had to work on a bug in an old legacy code. After a week of battle with it, I had three different solutions and absolutely no idea which one to use.

So I wrote my tests, nearly without thinking, following Scott’s method. And I wrote, one solution pretty much singled itself out, and “emerged” from my tests. Within a few hours, a problem that had kept me in check for a week pretty much solved itself.

Scott’s practices had a huge impact on my coding. After nearly a decade of software development, I felt that I wasn’t evolving much. Learning new techs and so on, yes, but writing better code, no.

Looking back, I can see a quantum leap in my ability to write good code, and the greatest thing is that it is actually easier now. Before I had to think about how I was doing thing. Now I apply trusted principles, and can pay attention on why I’m doing things instead. The energy gain is incredible.

Oh, and the book “Emergent Design” you may ask?

Well it is pretty much a blueprint of the Design Patterns and TDD courses I took. Do I really need to say that I think it is a great book?

From a technical standpoint, it is a must-read, with a lot of references code examples and thanks to Scott’s style (he also tells a lot of little anecdotes and stories in the book) it is also a very very pleasant read (as opposed to, for example, the GoF Design Patterns which is dryer than the Sahara).

- Update:
Here is a remark Scott made after he read this review:
I consider Test-Driven Development and Pattern-Oriented Development to be "disciplines", not practices. Words are arbitrary of course, but the distinction I make is this: a practice is quick and easy to learn and put into place while providing a lot of value, whereas disciplines require much more investment from the learner and the team, and are expected therefore to give an even larger payoff in the end.

So, practices (in my use of the word) are things like encapsulating constructors, programming by intention, following a coding standard, making all class state members private, things like that. Washing one's hands was a good analogy on your part.

Disciplines include the ones I mentioned, and also Refactoring as Fowler defines it. Basically, the stuff I create classes around. This distinction may or may not be important for your purposes, but the teacher in me came out when I read it. :)

Thanks again Scott.

1 comment:

Loïc said...
This comment has been removed by the author.

Post a Comment

Please leave your comment

Search Results