Although not a new idea there seems to have been a big increase in the interest in software craftsmanship over the last couple of years (notably the often recommended book Clean Code's full title is Clean Code: A Handbook of Agile Software Craftsmanship).

Personally I see software craftsmanship as good software engineering with an added interest in ensuring that the end result is a joy to work with (both as an end user and as someone maintaining that software) - and also that its focus is more at the coding level of things than the higher level process things.

To draw an analogy - there were lots of buildings constructed in the 50s and 60s in a very modern style which took very little account of the people who would be living in them or how those buildings would age over time. Many of those buildings rapidly developed into slums or have been demolished long before their expected lifespans. I'm sure most developers with a few years under their belts will have experienced similar codebases.

What are the specific things that a software craftsman might do that a software engineer (possibly a bad one) might not?

  • 1
    The analogy doesn't seem to fit. Both software craftsmanship and software engineering have the same goal (and vested interest) of improving the long-term usefulness of the software.
    – rwong
    Oct 25, 2010 at 4:14
  • 3
    I think this matter is mostly an issue of whether you consider "engineer" or "craftsman" the cooler title, and the current answers seem to prove that. Whichever title you prefer obviously implies that person knows what they're doing, after all.
    – Ben Brocka
    Nov 15, 2011 at 3:01
  • I would say the difference between the two is that a craftsman works alone, an engineer works as part of a team. In broad strokes this seems to satisfy the main descriptions of the two roles, not that either are differently skilled but their approaches come from different positions.
    – gbjbaanb
    Jan 7, 2016 at 9:48
  • It just sounds like a really pretentious title to give yourself. Jul 10, 2016 at 7:49

7 Answers 7


I'd say the only difference between a professional and a craftsman is caring with a little bit of passion mixed in. There is no specific, observable practice that would classify one as a craftsman, but rather a collection of qualities:

  • A craftsman cares about the actual quality of his work, and not just the perceived quality.
  • A craftsman has an interest in his craft that goes beyond getting the job done, and naturally gravitates towards his craft.
  • A craftsman cares about his profession, aspiring to improve his skills and not only advance his career.
  • A craftsman spends some amount of time outside of his paid working hours (even if it's a small amount of time) doing something with his craft, be it discussing, learning, or even thinking about it.
  • A craftsman knows how little he actually knows, and is humbled by it.
  • A craftsman is willing to teach those who are willing to learn, guide those who seek guidance, and seek those things himself when he needs them.

A little bit of passion covers all of these without breaking a sweat.

  • I think the last one is particularly important
    – Lovis
    Jan 8, 2016 at 21:33

Personally I see software craftsmanship as good software engineering with an added interest in ensuring that the end result is a joy to work with (both as an end user and as someone maintaining that software) - and also that its focus is more at the coding level of things than the higher level process things.

As a professor of mine said once (paraphrased): "As a software engineer, it's not just your job to deliver software. It's your job to deliver software that makes your customers happy."

What are the specific things that a software craftsman might do that a software engineer (possibly a bad one) might not?

Nothing - an engineer is a craftsman...but more. Engineering builds on craftmanship.

As a craftsman and an engineer, you are skilled individuals, through some combination of education and experience. You follow established procedures. You are also pragmatic and realize what is broken and needs to be better.

However, an engineer adds concerns of economics, theory, and science on top of that. You are concerned with getting the most benefit for the least cost. You want to apply theories from psychology, sociology, management, human-computer interactions, and computer science to solve your problems (both interpersonal and technical). And you definitely have an education to back up your experiences.

  • 2
    And you definitely have an education to back up your experiences -- glad you didn't say "formal".
    – treecoder
    Nov 15, 2011 at 5:11
  • @greengit In many places, to use the title "engineer", you must have formal education. In Europe, this means graduating with an engineering degree. Italy also adds a requirement of passing a certification exam. In North America, Texas, Florida, and Canada require those who use the title "engineer" (including software engineers) to pass a licensing exam.
    – Thomas Owens
    Nov 15, 2011 at 14:58
  • Although that doesn't mean that someone without this formal education can't practice engineering. They just can't call themselves an engineer as a professional title.
    – Thomas Owens
    Nov 15, 2011 at 15:03
  • 1
    I disagree, an engineer is not necessarily a craftsman.
    – Nicole
    Nov 15, 2011 at 22:51
  • 2
    @Renesis By definition, engineering is a craft. Definition of craft: "an art, trade, or occupation requiring special skill, especially manual skill". Engineering is an occupation that requires special skills, therefore it is a craft. However, it's also the application of scientific theory (among other things), which make it more.
    – Thomas Owens
    Nov 15, 2011 at 22:56

The software craftsmanship movement was initiated in reaction to the failures and unsatisfying results of "traditional" software engineering that (along with the carelessness of some developers) today lead to distrust from stakeholders and users towards our profession.

Its goal is twofold : restoring trust in programmers, and in order to do so, raising the bar of software quality and developer skills.

Sw craftsmanship promotes technical practices such as :

  • SOLID design principles
  • Design patterns
  • TDD ("double entry accounting" metaphor)
  • ...

And team/organizational practices :

  • Pair Programming
  • Mentoring
  • Code katas
  • Dojos / code retreats
  • ...

So I'd say the difference between the 2 is clear : software craftsmanship tries to address a large part of the problems software engineering has had in 40+ years existence which today make our discipline look unreliable and crippled with a history of failures.

  • 1
    I disagree - the reason software engineering failed is because it didn't have engineers, only craftsmen pretending to be engineers. NASA didn't send spacecraft to the moon using craftsmen!
    – gbjbaanb
    Jan 7, 2016 at 9:44
  • @gbjbaanb I think it's quite the contrary - we did have engineers, and that's why they tried to tack a traditional engineering model and mindset from other industries onto software, but it didn't work. Jan 7, 2016 at 10:14
  • Spacecrafts are not made of intangible stuff that can be remodelled, re-engineered and redeployed over and over. The laws they obey largely differ from those of software programs. Jan 7, 2016 at 10:16
  • The space shuttle has redeployable boosters, at least, and no doubt reused bits (or at least knowledge) from previous rockets. And spacecraft have lots of software in them. I don't think they start from scratch with every new satellite or probe, and hardly ever apply updates once deployed. Software engineering can and obviously does work - but only if you approach it with an engineer's mindset, not a craftsmans.
    – gbjbaanb
    Jan 7, 2016 at 10:19
  • Please define "engineer's mindset", in the context of software. Jan 7, 2016 at 10:25

Uncle Bob somehow hinted that programming is a very young discipline that doesn't yet have a stable body of laws or rules recognized by goverments (or was it Frederick Brooks?). I'm not making a verbatin citation here.

You cannot revoke anyone the permit to program due to malpractice. Programming lacks a body of laws and rules than are legally enforced by legislation that conforms a "profession". A doctor kills a patient due to incompetence and he risks his physician title or permission being taken from him.

A programmer makes a buggy program or makes a project fail due to incompetence and he is free to continue programming.

I think that's pretty much what makes programming a craft. A clay-pot maker don't make two identical pots. Nor have you heard of a clay-pot maker forced to recall defective pots. Programming is still a very manual, personal kind of work. Sometimes you can even tell who wrote a piece of code judging by the style of it.


Going by http://manifesto.softwarecraftsmanship.org/ I would derive the following.

A craftsman is different from traditional perceptions of an "engineer" because

  • They focus on value, not just meeting requirements.
  • They focus on quality even in the style of their code, not just meeting requirements.
  • They participate in the broader software development community, not just their workplace.
  • They don't just understand that today's state of the art is tomorrow's junk, they are active in bringing it about at one level or another.
  • It's not just a job, it's who they are.
  • 4
    Honestly, all of those bullet points describes a good engineer. Especially 1, 2, and 4.
    – Thomas Owens
    Nov 27, 2010 at 2:49
  • @ThomasOwens And what about bad engineer? Is he also a craftsman? Or good vs. bad craftsman?
    – Euphoric
    Jan 7, 2016 at 11:58
  • @Euphoric I don't think you can be a good engineer without being a good craftsman. It's like a staged. You must achieve "good craftsman" before you achieve "good engineer". However, you can be a good craftsman and not be a good engineer.
    – Thomas Owens
    Jan 7, 2016 at 12:00

Refactoring To Patterns.

That is, build something that satisfies 90% of the software requirements, then refactor the whole project into some clean, elegant design.

Normally, software engineering would prevent you from doing this, because satisfying 90% of the requirements means that the software has enough business value to the customer that it should not be modified in any significant way (except high-priority bugfixes).

Software engineering would instead advise you to stabilize the software at this point.

Furthermore, if a project does not start with that elegant design from the very beginning, it would be considered a poorly executed project (regardless of the project's outcome), according to software engineering.

Spike Solution.

A design that is inspired from a spike solution is normally not acceptable according to the prevailing software engineering methodology.

Deprecation, for whatever reason.

In software engineering, any kind of deprecation is allowed to happen only at the end of a software system's life cycle. This must be planned as part of the SDLC.

In practice, it is rather common that the shortcomings of a specific part of the software interface being discovered a few years into production, and that specific part can be deprecated in the middle of the life cycle, without invalidating the rest of the software. This would have required a re-certification of the entire software system after the deprecation, according to software engineering.

In the end, software craftsmanship is a personal strive for good judgments from individuals, whereas software engineering is a conservative body of knowledge. Allowing that good judgment into the project's decision making is what separates software craftsmanship from software engineering.


I would say having unit tests covering 100% of the code would be a good one. As that allows the excess stuff to be stripped away.

I sometimes compare software development to sculpture. It's not what you add, it's what you take away.

Obviously you can take that too far. No-one is going to say a small shiny pebble is a good sculpture :S

  • 3
    How shiny are we talking about here? :-)
    – Chris
    Oct 24, 2010 at 21:53
  • 1
    Most of the time I agree with this - but I'm not sure strict 100% is always worthwhile - e.g. getters/setters where they have no logic. Also generated code is generally better left without unit tests (although integration tests may be appropriate)
    – FinnNk
    Oct 24, 2010 at 21:55
  • @FinnNk - i agree. I've used dotCover recently and that says a getter/setter is covered if it's used in another test. So, I didn't really mean a test method for each getter & setter Oct 25, 2010 at 8:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.