Those who think software construction should be just like building construction are clearly unskilled at both. 

~ Andy Hunt

A developer who lacks the ability to give good names to concepts and data in their code is like a mute translator. It doesn’t matter if you can understand something, if you can’t adequately explain it, the moment it leaves your head it is gone.

~ John Sonmez

What if?

What if software wasn't "made", like we make a paper airplane - finish folding it and fly it away? What if, instead, we treated software more like a valuable, productive plant, to be nurtured, pruned, harvested, fertilized, and watered? Traditional farmers know how to keep plants productive for decades or even centuries. How would software development be different if we treated our programs the same way?

~ Kent Beck

I will not write crap

I've gone from Dan North's post, to Gil Zilberfeld's to Michael Feather's to Jason Gorman's. It would appear that we, in the software craftsmanship movement have not been clear. I hope this blog clears a few things up.

Why is there a software craftsmanship movement? What motivated it? What drives it now? One thing; and one thing only.

We are tired of writing crap.

That's it. The fat lady sang. Good nite Gracy. Over and out.

We're tired of writing crap. We are tired of embarrassing ourselves and our employers by delivering lousy software. We have had enough of telling our customers to reboot at midnight. We don't want bug lists that are a thousand pages long. We don't want code that grows more tangled and corrupt with every passing day. We're tired of doing a bad job. We want to start doing a good job.

That's ... what ... this ... is ... about. Nothing else.

What we are not doing:

• We are not putting code at the center of everything.
• We are not turning inward and ignoring the business and the customer.
• We are not inspecting our navels.
• We are not offering cheap certifications.
• We are not forgetting that our job is to delight our customers.

What we will not do anymore:

• We will not make messes in order to meet a schedule.
• We will not accept the stupid old lie about cleaning things up later.
• We will not believe the claim that quick means dirty.
• We will not accept the option to do it wrong.
• We will not allow anyone to force us to behave unprofessionally.

What we will do from now on:

• We will meet our schedules by knowing that the only way to go fast is to go well.
• We will delight our customers by writing the best code we can.
• We will honor our employers by creating the best designs we can.
• We will honor our team by testing everything that can be tested.
• We will be humble enough to write those tests first.
• We will practice so that we become better at our craft.

We will remember what our grandmothers and grandfathers told us:

• Anything worth doing is worth doing well.
• Slow and steady wins the race.
• Measure twice cut once.
• Practice, Practice, Practice.

I suppose that some people might look askance at our code katas and our code retreats, and our practice sessions. They might think that we're turning inwards and abandoning our customers. They might think that we've given up on the real world and have yielded to the temptation to entertain ourselves. I can see how someone might come to that conclusion.

But they are as wrong as the day is long. We are doing this because we care about the customer. We are dedicating time and effort to being the best that we can be so that our employers will get the best possible value out of us.

Do you think the only time musicians play their instruments is when they are on stage? Do you think the only time that batters hit balls is during games? Do you think the only time lawyers give a closing is at trial? Of course not. These people are professionals; and professionals practice! Professionals study the minutia of their disciplines. Professionals know all the little tricks and quirks. They know the history, the theories, the anecdotes. They know techniques and methods. They know good options and bad options and how to tell them apart. And they know all this stuff because they practice, practice practice.

So when you see someone wearing a green wrist-band that says "Clean Code" or "Test First" or "Test Obsessed", it's not because they've joined a movement, or signed a manifesto, or that they somehow feel superior to everyone else. They aren't participants in a holy war. They aren't trying to join a tribe and huddle around a campfire. The green band is a personal thing. It's a promise made to one's self: "I will do a good job. I will not rush. I will write tests. I will go fast by going well. I will not write crap. And I will practice, practice practice so that I can be a professional."

http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmen

All the great code

So you can write Java code that's object-oriented but C-like using arrays, vectors, linked lists, hashtables, and a minimal sprinkling of classes. Or you can spend years creating mountains of class hierarchies and volumes of UML in a heroic effort to tell people stories about all the great code you're going to write someday.

Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done. It's not very easy to drag your heels and dicker with class modeling in dynamic languages, although I suppose some people still manage. By and large these languages force you to face the computation head-on.

-- Steve Yegge

We are authors

We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

Uncle Bob

Teaching people

Better to teach people and risk they leave, than not and risk they stay.

-- anonymous

Why do you code, test, listen and design?

"You code because if you don't code, you haven't done anything.
You test because if you don't test, you don't know when you are done coding
You listen because if you don't listen you don't know what to code or what to test.
And you design so you can keep coding and testing and listening indefinitely.
That's it."

-- Kent Beck