A Good Imagination and a Pile of Junk

I just posted this to the Software Craftsmanship group/list a couple minutes ago.  Thought I’d post it here just in case.  It frustrates me that I don’t write better.  But the only way to do it is to do it, so I’m going to do more of it.

(err… I posted the below thingie in response to J. B. Rainsberger’s msg here.)

J. B. Rainsberger wrote:
> Hello, folks.
>
> I think the subject line says it all. I believe that a focus on
> software craftsmanship without a similar focus on becoming an
> entrepreneur wastes valuable energy. Most companies will never respect
> the level of craftsmanship you want to attain, so you’ll need to make
> your own opportunities. Whether you start your own business or don’t,
> I believe you need an entrepreneurial spirit in order to turn your
> passion for craftsmanship into better day-to-day work.
>
> What say you? Full of shit? Bang on?
>
> Take care.
>

I’ve been rolling this over in my head a bit and something’s not quite right.

I certainly do think this J.B. is right about the state of business and their understanding.

BUT

If internal customers aren’t going to respect a certain level of craftsmanship, why would external ones?

Think about what’s been going on in the past few years in our industry. It’s perfectly clear to me that WE don’t even know what the hell we’re doing. I don’t mean that we’re a bunch of hacks. But that we’re trying to work out what good software even IS. Agile practices as a widely accepted notion is what, 5 years old at the outside? (people “got it” earlier, just read Kernighan & Plauger’s “Software Tools” book and tell me it isn’t agile.)

This is a young field and because it’s one of the few crafts that works with zero raw materials, there has been no material cost of waste. It is simply not obvious what is bad product and what is good product. If you have a thing of tin and a thing of steel, senses you’ve been developing all your life tell you pretty quickly which one is going to hold up and feel like a more substantial “better thing.”

So a couple very fundamental motivations out of which true craftsmanship evolved simply don’t exist in our field. Throwing something together that just worked well enough has been expedient for the last 40 years and it’s only in the last 10-15 or so that we’re starting to understand the notion of technical debt, seeing what it’s really costing us and our customers.

Add to that the speed of advance in this arena. New languages, techniques and technologies du jour (Client Server, Push, Fuzzy Logic, Data Warehousing, Thin Client, yadda yadda) all of which were seized upon as panaceas which failed to deliver, to the unending and increasing frustration of our customers who began to see us as just wanting them to pay for toys for us to play with.

So now here we are. We’re starting to realize what a horrible fog we’re in while groping our way around the elephant of craftsmanship, trying to replace the natural impetus of material waste with best practices and discipline. We’ve started wrapping these ideas in packages of nomenclature that can be sold and talked about. And It Is Good.

But think about our customers for a minute. They’re going to look at all this, hold their breath and mutter ‘oh here we go again’. By all estimations, they’re right. What possible reason would they have to think anything else? And how are we going to respond?

Well, we get to pick.

I don’t think there IS a good answer to that. It asks people who have very little attachment to the inside of the software development process to understand an evolution in our field that’s only beginning and that we don’t understand very well ourselves. At the same time we’re telling them that what we’ve been delivering is probably an awful lot worse than we had previously realized. Who the hell do we think we are to have any expectations that a product customer is going to accept that?

What we can always do is to write software better. No matter how intractable the customer seems, there’s always room for personal improvement through diligance and hard work. You can always clean the code a little more. You can always code for testability. You can always leave a code base better than you found it. You can always have out of band converstaions with QA people, asking what would make their lives easier. If the shop “doesn’t believe in unit tests” then keep your unit tests on your box. There’s always room to pull and ground that can be gained.

We work in a world where you can’t hold up a good thing and a bad thing and tell the difference by visual inspection. You can only tell over time what is strong and flexible, and what is brittle. So it falls to us to create a good thing instead of a bad thing and to do so consistently such that the difference will eventually be obvious.

We are doing all the right things. Sure it looks like floundering around in the dark. But that’s only because we’re floundering around in the dark. It’s a part of the process.

Flipping the bozo bit on our customers, whether they are internal or external, is simply not useful.

Tags: Agile, Programming

This entry was posted on Monday, March 16th, 2009 at 12:18 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.