Tag: Craftmanship

The Code of Christmas Past

When we write code, we’re often thinking about the short term. We need this code to function correctly so we can deliver within our immediate deadlines. I’ve found it important to also think of the long term. Sooner or later, we might encounter our own code, again.

I spent a chunk of my career where I often worked solo on projects that might get enhanced every year or two. This taught me a lot about the importance of code readability and what sort of things helped me quickly understand and avoid overlooking important considerations. I’ve also worked on a lot of legacy code bases, so I’m well aware of the pain and problems created by code that’s not readable, or is not organized in a helpful manner. Read More

3 Comments

Categories: Tools and Techniques

Tags: , ,

When something persists, some reward exists

Jason Gorman has just written a piece in defense of Software Craftsmanship that highlights how very dependent our world has become on software.  He offers Gorman’s Law Of Software-Dependent Business Evolution:

Software-dependent businesses can only evolve as fast as their ability to write and evolve their software allows them to.

I think this is not only true, but an incredible opportunity for businesses that understand that.  Let’s face it: most businesses spend an awful lot of time for a very meager increase in systems capability.  Companies that do better than average can shoot to the top.  Look at the spectacular successes of some of the relatively young internet companies, for examples. Read More

6 Comments

Categories: Tools and Techniques Working Software

Tags: ,

It is possible to fail in many ways

On Twitter, Alfonso Guerra (@Huperniketes) asked me, “Okay, tell me how [software] quality will improve by prog[rammer]s taking more resp[onsibility] for quality?” My response is longer than 140 characters, so I’m replying here.

For background, my involvement in the conversation started when he caught my eye with

The problem with the Software Craftsmanship movement is its attempt to create a race of superprogrammers who can save [software] from bad [project management].

Well, I don’t know anyone promoting Software Craftsmanship who thinks that. Read More

1 Comment

Categories: Individuals and Interactions

Tags: ,

Trades, Crafts, and Certification

Dan North says that programming is a trade, and not a craft.  I agree with him that it’s a trade, like plumbing and wiring.  I’ve already disagreed with his definition of craft.  I’d say that programming is a craft only when it’s done well.  I’d also say that plumbing and wiring are crafts when done well.  Rather than a definition, how about a couple examples to illustrate the point? Read More

10 Comments

Categories: Working Software

Tags: ,

Software Craftsmanship

Dan North has created a bit of a stir with his declaration that programming is not a craft. Liz Keogh has agreed with him.  The funny thing is that most of what they have to say is not about programming, but about the Manifesto for Software Craftsmanship.  Well, writing is a craft, also, and I’ll agree with Dan that this manifesto is not “a call-to-arms, feisty, opinionated, brash and everything that a good manifesto should be.”  It never grabbed me the way the Agile Manifesto did.  Dave Hoover has taken this challenge as a call to improve the software craftsmanship manifesto.

I didn’t “sign” the Manifesto for Software Craftsmanship because I thought it was particularly well written, though.  I signed it because I support the intent (as I perceive it, and which Ade Oshineye defends) behind that manifesto.  Writing software is a craft, and there are far too many people who don’t treat it that way. Read More

4 Comments

Categories: Working Software

Tags: ,

Normally, I’d relish a mention on InfoQ

This article on InfoQ bothers me.  It seems to draw only from Dave Nicolette’s blog post [now lost due to the defacement of his old blog] and the subsequent comments.  Dave’s post is similar, in my mind, to a trip report that someone might give to an organization after a class or conference.  He goes into some detail about what happened at the first ever Certified Scrum Developer course, and muses about what he learned.  The bulk of the comments are an interchange between Dave and Tobias Mayer where, it appears to me, Tobias doesn’t think that the course comes up to the standard of the CSM course.  This is, of course, based on Dave’s description, as Tobias wasn’t present at the course.

The InfoQ article mentions me by name, but doesn’t mention other participants other than Dave.  It also misquotes Dave [now edited without any indication of doing so], and implies that the learnings that Dave got out of our retrospective conversation after the course was a list agreed upon by both of us.  There was apparently no fact checking done on this article.  Certainly no one spoke with Ron Jeffries or with me about it.  I find the article misleading enough that I need to respond.

I had planned to write about the course, but this isn’t the article I’d planned. Read More

11 Comments

Categories: Individuals and Interactions

Tags: ,

Building sand castles on a rising tide

Grabbing a handful of wet, saturated sand, I let it dribble through my finger tips.  I watch each drop pile on top of the previous, draining away the water and leaving a new building block of solid sand.  Too much water and the previous drip will be washed away.  Too little and the sand cracks and refuses to hold together.  I watch the sand grow, getting into a rhythm that ensures just the right amount of water, without thought.

My thoughts are not on the mechanics of building a drip castle with sand.  Instead, I’m thinking of the spire that I’m building.  Can I build these two spires toward each other and form an arch?  Can I make this slender spire taller?

Frequently I fail and a part of the castle slides down, becoming part of the landscape again.  Or becoming a foundation for a new part of the castle.  No matter.  It’s the building of the castle that brings me joy–not the owning of it.  For I will never own it.  The sea soon comes and takes it away.

Last weekend, I drove six hours down to Floyd, Virginia for a Code Retreat organized by Gustin Prudner and led by Corey Haines.  There, I joined thirty-some people working in pairs and threes on Conway’s Game of Life for forty-five minutes at a time.  Then, Corey would call time, and we would wash away all traces of what we’d built.

Does that sound like a waste of time?

Read More

3 Comments

Categories: Tools and Techniques

Tags: , , ,

Of course it’s a misnomer

On Twitter, my good friend Mike Sutton said, “CSD is a misnomer. The value of existing Certifications needs to be justified before new ones are released.”

Many of the terms we use are misnomers.  For example, “acceptance testing” is a misnomer because it doesn’t indicate acceptance if the tests pasts–it indicates lack of acceptance if the tests fail.

What is the misnomer in the phrase “certified scrum developer?”  Read More

22 Comments

Categories: Individuals and Interactions

Tags: , , , ,

Testability & Good Design

Much of the time, the test-driven development yahoogroup is pretty quiet, but it has recently awakened from winter hibernation.  The question “Is it OK to add code to a class only to improve its testability?” stirred up a wide-ranging discussion that brought in the topic of what constitutes good design.  “Uncle Bob” Martin drew a bold line in the sand with his comment,

One reasonable definition of good design is testability.  It is hard to imagine a software system that is both testable and poorly designed.  It is also hard to imagine a software system that is well designed but also untestable.

I greatly sympathize with this statement, though I wouldn’t go quite that far.  I don’t think it is so hard to imagine code that is testable, but poorly designed.  For a trivial counter-case, there could be rampant duplication of testable code.  I would call that poorly designed, but it doesn’t affect it’s testability.  Therefore I would soften Uncle Bob’s definition to “One reasonable component of the definition of good design is testability.”

To me, the notion of “testable code” is the same thing that “testable circuit” was back when I worked on a custom integrated circuit.  Mostly, that depends on the ability to put the circuit or code into a known state, exercise it, and see the interactions with its collaborators and its resulting state. Read More

5 Comments

Categories: Responding to Change Tools and Techniques Working Software

Tags: , ,

Fixing the Agile Engineering Problem

A lot of people are talking, recently, about the fact that organizations that adopt Agile practices don’t always achieve the results they desire.  See Martin Fowler’s Flaccid Scrum, Ron Jeffries’ Context, My Foot!, and Jim Shore’s The Decline and Fall of Agile for examples.

In my experience, most organizations have much room to improve both their project management and their technical engineering practice.  Those that start with Scrum seem to improve their project management practice enough that the deficiencies in their technical engineering practice become more painfully obvious.

The answer is simple and obvious–improve the technical engineering practice.  The way to do that is not so easy, however. Read More

8 Comments

Categories: Individuals and Interactions

Tags: