Craftsmanship is Mastery
Posted by Lars Vonk just before lunchtime: August 21st, 2008
This is the literal translation of an old dutch saying "Vakmanschap is Meesterschap"; being a master in your profession. In my opinion the lacking of this is one of the biggest problems in software development these days and main reason why projects fail; it isn't a process that caused it, nor the technique that was used: It's actually people that mess up projects! Did the technique or process pick itself or did someone pick the technique or process?
Currently there is also a debate going on whether or not to include Craftsmanship over Execution as fifth value on the Agile Manifesto.
But let's take a step back and try to figure out why we are lacking craftsmanship?
First of all let's see what craftsmanship actually means. For me craftsmanship means, amongst other things, that you; take pride in your work; care about what you deliver; try to improve yourself. Of course years of experience count, but when you lack the taking care or pride in your work you are not a craftsman in my book.
In my opinion the reasons for the lack of craftsmanship are the traditional grow path and money.
Grow path
With this I mean that in (especially larger) companies you are expected to "grow" in your professional career. Growing in this case usually means a step higher in the software development functions ladder. From my personal experience I think it kind of looks like this: "Developer/Tester" -> Analyst -> Project lead / architect -> Manager -> Program Manager -> ? Of course there are people that just want to do something else, but in most cases I think we just "grow" since that is what is expected from us. Let me illustrate the consequence with a simplified example:
At the age of 21 you are starting at big financial as software developer. After five years of coding you finally understand a bit what it is about and your manager comes up to you and says: Hi employee, you are doing pretty good; how about we gave you the role of technical lead? In traditional organizations this means doing a lot of planning, meetings etc and a lot less coding. You are probably replaced by a junior developer developer who you also need to coach. So just when you build up a little experience you are pushed into a more "important" role; the tech lead. Having no experience with this whatsoever Mr. employee is probably the worst lead ever: So now we have no experienced programmers anymore and a non experienced tech lead. The next step is of course becoming an architect or project leader. See where this is going? Do you recognize it?
At the end of the story we all wind up with people that aren't really experienced in what they are doing.
I can say from experience that working with craftsmen (we have quite some at Xebia) makes a hell off a difference. I'd rather work in a team consisting of 4 craftsman, than 10 mediocre or just experienced people. And I am sure that the "craftsman team" will deliver more business value, better software in less time.
Money
Besides the grow path thing, in the Netherlands the rates for developers are (considerably) lower than those of analysts or project leaders. But as (at least) all developers know; we the developers are actually doing all the work and get paid the less 
. Besides this being unfair it actually pushes developers that are on the verge of becoming craftsman to do other work, or they'll leave your company and become freelancer. And now you'll have to hire a new mediocre developer again... from a financial perspective this might be a healthy thing to do, but from a software perspective it sure isn't. And in the end all that really matters is the software.... right?
How to counter this
Countering this is easier than one might think: Reconsider your rates; pay your team members more and they'll keep doing the work they like till they ll become craftsman. In fact: rates should be determined on level of craftsman instead of your function in a company or project.
Break with the traditional grow path. As a company value your developers, testers, analysts etc. Stimulate them to become better in what they are doing, rather than pushing them to a new role.
Lars
Archives
Training
- Workshop Agile Management
Custom made, in-company
Xebia Sites
Categories
- Java (279)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Quality Assurance (14)
- Middleware (19)
- Frameworks (13)
I used to think so far, things you just mentioned are prevelent only in Indian IT
. It looks like a universal phenomenon. Good points and they concur what I also feel about Indian IT. I posted a blog (http://svashishtha.wordpress.com/2008/06/06/challenges_of_a_new_project/) sometimes back somewhat related but subject was more related to – what happens when this hapless developer becomes a manager.
Cheers.
Hmm interesting, I think you put across your point to the company that you need more salary
This is the reason why I prefer a more agile style of development. In an agile environment, every person on the team needs to know all kinds of things. When you’re a developer you *don’t just* code, you also spend a lot of time doing technical design, testing, architecture, analysis… My advice: empower the developer (and raise their salary)!
[...] recent blog by Lars inspired me to write about my perception of craftsmanship in software development. A feature that [...]