Choosing a Chair

Two chairs, both functional and provide exactly the same service.

Solid Chair  Folding Chair

But which is better?

Having a context helps to make the decision on which chair to take, a quick sit down, or a long lunch, the one on the left will properly be around longer, so will be used more over its lifespan, but is it better?

When it comes to code, developers have the same problem, except it in some ways its worse! How many times has a developer quickly put together an application that will only be used “once”, only then to have it come into continuous use, bugs and all, for months or even years!  Having built a folding chair, but having to support it into the future adding padding when the user complains about it being uncomfortable.

Attempting to build the quick application that can morph into a core service with a bit of refactoring is the holy grail of modern software development, where rapid application development has pushed the art of software to its limits.

Practices spawning from this grail search are what developers argue about, how productive will a developer be if they  follow pattern “a” or “b” instead of pattern “c”, which pattern produces code that is better, more readable and reliable, which pattern allows the developer to produce the application within the time available? 

There is always someone with a better way, or another framework that will make it easier, solve the problem etc.  Inevitability all the ideas and frameworks fall short at some point, there is a situation where it will be impossible to use framework “z” or practice “y”, but it is these choices that make the developers craft interesting, there are very few wrong answers to these problems, but there are many opinions.

The latest controversy around the programming internet has been about the craftsmanship label,  “Michael Feathers”, “Dan North”“Gil Zilberfeld”, “Jason Gorman” and finally “Rob Martin”, have blogged extensively about it. 

Craftsmanship for me is knowing how to build a folding chair, that can be turned into a Chippendale masterpiece, and knowing when to build each from scratch, In code terms this means I must try to write the cleanest code I can, every time regardless of the project. 

This is not gold plating the code, ivory tower or elitist thinking and everything has to fit into the time scale allowed for the project.  But it has been proven time and again that the cleaner the code is the quicker the development process can run, up to a point:

                1. “It is not possible to go slower because the code is too good”

                2. “It is possible to take too much time making the code good.”

Ron Jeffries

But again that’s the craftsmanship, in knowing where to stop cleaning, these things can be learnt, and its through practicing the art of programming, reading code and and following the tenants of something like the craftsmanship movement that a developer can improve their skills.

What is interesting is not what the “movement” is called, but the practices that emerge, because when the dust has settled, it is the practices that will guide the way we write code in the future. 

A lot of the things we take for granted today were, at one time as controversial as the idea of “test first development” is today: 

The removal of the “goto” from programming languages, was in its day fought against by many developers, who felt it was going to stop them from developing their applications in the way they wanted, but today some languages don’t even have the concept of the “goto”, and few if any developers would actually use the “goto” command day to day. 

The idea of object oriented design, is today taken for granted, but in its time was again the source of many arguments, and so it will probably be for the craftsmanship principles, until they become part of the mainstream culture.

The idea of writing well structured code that follows the “SOLID” principles guided by tests written first for me make perfect sense.  Has writing the test first changed the way I program? Yes definitely, but its not the tests that have forced that change, its what the tests have shown me, and the things I have learnt that have changed the way I program.  The tests have not forced change, but they have facilitated it.


About Duncan Butler

Trying to be a very agile software developer, working in C# with Specflow, Nunit and Machine Specifications, and in the evening having fun with Ruby and Rails
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s