Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 '10 at 4:14
    
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 '11 at 3:01

6 Answers 6

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.

share|improve this answer
2  
And you definitely have an education to back up your experiences -- glad you didn't say "formal". –  treecoder Nov 15 '11 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 '11 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 '11 at 15:03
    
I disagree, an engineer is not necessarily a craftsman. –  NickC Nov 15 '11 at 22:51
    
@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 '11 at 22:56

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.

share|improve this answer

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.

share|improve this answer

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.
share|improve this answer
3  
Honestly, all of those bullet points describes a good engineer. Especially 1, 2, and 4. –  Thomas Owens Nov 27 '10 at 2:49

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

share|improve this answer
2  
How shiny are we talking about here? :-) –  Chris Oct 24 '10 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 '10 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 –  Antony Scott Oct 25 '10 at 8:20

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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