Archive

Posts Tagged ‘craftsmanship’

No, I’m not a mason

October 27th, 2010 8 comments

“Danger! Software Craftsmen at Work”

Now that’s a great title! I wish I could have used that for this post. Instead, that’s the title of the QCon 2010 David Harvey presentation that is the foundation of this blog entry.

In his talk Mr Harvey places the “Software Craftsman” ideas and practices somewhere between distracting and dangerous, and claims these ideas builds a wall between developers, organisations and customers.

I claim he exaggerates the dangers, but I welcome the stirring in the pot and I do agree in parts of what he says, mainly regarding the emotional associations of the metaphors used by the Software Craftsmanship movement.

I agree with Uncle Bob‘s views on “The Empty Manifesto“, “Engineering vs. Craftsmanship” as well as “The Craftsman Connotation“, the last one being the one I’m expanding upon here. Plus, he sums the whole thing up nicely, so if you haven’t yet, please read that one first. (Yes, you may read Gael Fraiteur’s post too if you must, but please then leave a trail of breadcrumbs so you find your way back here.)

A masonry brick wall

So, on to David’s talk:

My first issue is with his first analogy; why would wearing a white T-shirt with printed instructions make it any worse walking into the lion’s cage? …ok sorry, that’s not the point. And, to give hime some credit, the print was in fresh blood and lions tend to like that, so fair enough, I’ll let it slide. After all, he was standing inside the lion’s cage saying it.

And thanks for putting yourself in that cage, David. It was refreshing to see an alternate slash controversial view presented on this subject.

My biggest issue

My biggest issue, however, is that he picks on a great movement with the noble goals of achieving a larger recognition of software development as a profession and to “raise the bar of professional software development”. Why would anyone want to do that? That’s just mean.

Or, is it? He is, after all, a developer himself…

Please, let me shine some light on an important point he makes, one that I’ve brought up before: We should be careful with our wording! We are already perceived as loners, nerds, Storm Troopers sleeping in line for Star Wars premiers. We don’t need to enforce that perception.

For me the timing of watching this presentation was great. It aligned perfectly with a conversation I had the other day:

The conversation

I was sitting out on the lawn, (re)reading a book* about apprenticeship and craftsmen, when my neighbour approached me.

-Are you working?
-Yep, reading up on some important professional elements.
He shot a quick look at the cover.
-But aren’t you in IT?

I began explaining, but it wasn’t until I started using words like professional instead of craftsman and mentoring instead of apprenticeship and that the book was really about learning and improving that the coin really dropped and the conversation took off. Turns out he, being an ambulance driver (amazingly enough, the very one that drove me and my wife to the hospital six months ago, when our bub #4 decided he wanted out in the middle of the night), knew and practiced many of these patterns. New ambulance drivers work with experienced ones to pick up on the large part of that profession consisting of working in the field, in an often critical atmosphere.

-They have to. Can’t read that in a book.
-So ok, you do that too, he said, I get it. Cool. But what with all the old guild talk? You’re not a mason, are you?

Touché!

So, why do we fight so hard for recognition?

Well, for one, it’s still a fairly young profession, but I also think some of it has to do with our characteristics. Software developers are smart, analytical people, lacking the social and communicative skills required for many other professions. (Generalising. Trying to make a point here. Moving on.)

I don’t care if you’re socially inept, as long as you can code. It’s actually better that way, since you’re going to spend most your waking hours in the basement anyway.

This has changed, greatly and quickly, and we are now in contact with the users, the business, no longer sitting in the basement. But even so, to the outside world that’s still us, the loners.

We see all that – we’re smart and analytical remember – and we’re tired of standing back to the sports jocks from the school yard, now turned corporate leaders. And we just don’t understand why people have such a hard time seeing the complexity, the necessity, the importance of what we do, just because it’s not tangible.

So, maybe we get a little bit too eager to get that recognition and forget there’s a gap that needs bridging first. (…and now, also a brick wall to tear down. See, we’re not making it easy on ourselves.)

Bridging the gap

That gap will be brigded though, sooner or later, through continously working on doing what we should do and doing it well. I agree with David’s advice; developers, stick to what Kent Beck described as the four basic activities of XP:

-Listening
-Testing
-Coding
-Designing

Do them well and stop worrying so much about recognition and acknowledgement. And by all means, use whatever names and metaphors you want for learning and improving, but do it internally. On the outside, make sure our organisations and customers understand what we’re doing too.

And anyone suggesting writing software is not hard, not a real profession, is welcome to come and give it a go…

* Not just “a book”, ladies and gentlemen. The Book! Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye. Read it. Please do. For your own sake.

(Photo courtesy of Shutterstock)

Iterative evolution

May 28th, 2010 2 comments

Isn’t it great when you stumble upon something, whatever, that makes you think, really think?! And then sometimes, that wonderful stumble triggers you to rethink things you thought you already knew, things you took for granted. Ah, that’s indeed a wonderful process.

It just happened to me. This time it was two very interesting articles that got me thinking about the Agile idea of iterative delivery.

Step by stepPhoto Credit: extranoise

Delivery

The way of delivering anything these days is arguably to do it in steps, adjusting as you go, depending on the feedback and the changing requirements. Yes, yes, yes, I know; far from everyone agrees with that statement. Hence “arguably”. (I’m not going further this time. Go google – or bing if you will – delivery waterfall agile if you want to dig deeper into that subject. And bring a sturdy spade.)

Having lived with a term like “iterative delivery” for about a decade now, believing to have a rather firm grip around its meaning, I find it interesting – and refreshing – to find it challenged twice in a couple of days, after reading two excellent articles sort of on the subject.

Iterative delivery

A common way of looking at iterative/evolutionary product delivery is: Release and fail fast, acknowledge missing features, embrace change and continuously add and improve all the way to the “final” (great) product.

Banana skins

My two challenges, or pitfalls, for today concerns:

  • The acknowledgement of missing features
  • The failing fast

The acknowledgement of missing features

There is a very interesting article by John Gruber, about “how Apple rolls“, showing how Apple consistently release their products small, and then improving on them, slowly, bit by bit. Of course that’s what they’re doing. I just haven’t seen it like that before. Apple is doing iterative delivery. They just don’t advertise it as they go. They never focus on the missing parts. Every product is a flagship that will, and most often does, revolutionize the industry.

Before I go on and you accuse me of comparing Apple and orange: When we talk about Agile software development principles, the acknowledgement of missing features is commonly communicated within the team, including stakeholders/customers. What Apple is doing is marketing externally to the end users of the product. That’s a different ball game, but nevertheless I think there’s an important lesson to be learned here:

One of the great benefits of the Agile way of thinking is that it fosters a humility towards failure and change. However, too much of a good thing may do you harm. When you insist on putting up a sign on the front page telling the users this is not a complete product, when you refuse to remove that Beta tag, you start making excuses, effectively demoting your product. You don’t have to speak Apple, but be careful. Don’t be too humble.

Fail fast

The same goes for the mantra “fail fast”. It’s a great guiding principle, but be careful communicating it to people without the same level of understanding and knowledge about Agile and XP. They might just perceive it as a careless approach to their product, their time and money.

But pretty please with sugar on top; it’s such a catchy phrase, with its short allegorical allure! Yes, but it does front a dangerous word when it comes to the customer’s children: Fail!

It’s not just linguistics though. Fail fast is a concept that demands and deserves proper presentation. It lives dangerously close to the world of lazy or lacking preparations. (Which, by the way, is not a good starting point if you have any ambitions.)

There have been times that I’ve felt this need for careful wording trying to convert waterfalling customers, but after reading this rather energetic confrontation with the mantra from a VC’s standpoint, it really made its way to the frontal lobes. Again, all I’m saying is: Be careful.

Do your homework

Be careful you say? How? The way to avoid these pitfalls is – in my humble opinion – to be sure to communicate, to eat, live and breathe responsibility and thorough groundwork. From there you can go pretty much wherever you like…