Craftsmanship, Quality, Dogma, and Pragmatism


In the last year or so, there has been an increasing amount of discussion on software craftsmanship, and what it means and whether or not it’s a good thing. There’s an online email list, a conference with the same name, and at least one user group devoted to the subject (in related news, I’m helping to organize a similar group in Hudson, Ohio). There is some good discussion going on in this sphere about what it means to be a craftsman, but there are other discussions (mostly happening elsewhere) that question the value of craftsmanship with equally valid reasoning. I’ve heard from several successful business owners that they don’t want to hire artists and craftsmen devoted to making beautiful and elegant code, they want programmers who can get the job done with a minimum of fuss so they can move on to the next task. At issue here is the notion that some of the values held by those who believe quality is of great import don’t always fit in with the business needs of the day.


Recently, Bob Martin took issue with some remarks by the StackOverflow team on their podcast. In it, the SO guys stated that quality “isn’t that important” which, taken completely out of context like I’m doing here, sounds like blasphemy, especially to those who prize the quality of their work (as I try to), like Robert Martin (they later mostly made nice). However, as a business owner myself, I also realize that sometimes quality can be sacrificed in order to meet business needs today. And, on a related note, some “best practices” for building quality enterprise software present unnecessary overhead for small and/or one-off applications, either in terms of time necessary or due to the skillset required. We frequently employ college interns to help with our software development work, and if need be we can task them with simple projects that don’t require a deep understanding of complex business problems. The amount of rigor that we apply to this code is proportional to its importance to the business, and we accept that if we do need to revisit this code it will have technical debt that we’ll need to pay if we want to maintain it and build upon it. This is an acceptable tradeoff and one that we are able to make knowingly.


I also overheard recently in the context of the current economic climate that the first developers to go during a layoff should be the ones who eschewed simply getting the job done in favor of using their latest favorite developer methodology (insert a TLA here). The implication being that their unwillingless to cave on their principles was costing their employer money in the form of extra time and complexity added to projects that simply didn’t require any additional formality or structure. Related to this is the common theme on twitter or various mailing lists for experts to describe the “right” way to do things, often with some degree of condescension for those who would do things another way. This is where dogma comes into the discussion, and is rightly seen as getting in the way of solving business problems.


Personally, I think craftsmanship implies quality, but a craftsman is also one who can provide the right amount of quality to meet the customer’s needs. As a very real example, I’m getting some work done on a building to which (hopefully soon) we’ll be relocating our offices. I got a quote from a contractor whom I was referred to because they do very good work, to do some pretty simple remodeling of a tenant’s space. It was a bit higher than I expected and after further discussion, I (just today, in fact) got a quote that was about 35% lower with, among other things, the following bullet point describing the difference:

Savings from a relaxed “degree of finish”

What does that mean? It means less quality, but at lower cost. It means I might have to get the space remodeled again sooner than if I were willing to spend a little more, or it might not look quite as nice, but it will cost a little less. As the customer, I appreciate having this as an option. The contractor is showing that he understands his job is to meet my needs, not to necessarily maximize the value of the job or perform the best work of his career (building architects, in particular, like to make designs they can be proud of and show off to other clients, so you need to be extra careful with how much you let them expand upon what is functional).

A software craftsman takes pride in his work, but more than that they should take pride in delivering value to the customer. If a particular piece of code is not written using their favorite framework or methodology, but it got the job done and the customer is happy, then they should be pleased with themselves. It’s important to be aware of how to overcome complexity and avoid future technical debt using appropriate patterns and practices, but it’s just as important to be able to objectively describe to the customer what the costs are (both short and long term) of implementing these practices so they can decide whether or not they are worthwhile for a given project. In many cases, as Bob Martin says, building quality software makes everything go faster, so trading quality for speed makes no sense. However, in my experience this is only true if the team already has all of the necessary skill to do so. If some or all of the team requires training, and worse, if they are resistant to changing their typical modes of writing code, then trying to deliver higher quality is likely to require significant investment in time and energy. The customer should be the one who gets to choose if this is a worthwhile investment for the project at hand.

  • Jeff Putz

    Man, I can identify with everything that you’re saying here. The thing that I try to instill in developers that I mentor is to ask them if what they do will cause a great deal of pain later. It seems that the biggest measure of quality for me comes in the form of maintainability. I’m less interested in how interfacey and abstracty you are and more interested in how easy it will be to refactor, improve and grow your app later.

  • Troy Tuttle

    Nice post Steve. I’m thinking about a post like this myself, and my theme will be similar to yours–it’s really the business owner who decides in the end.

  • ssmith

    I just read this post that talks a bit about how to deal with technical debt once decisions have been made that have caused it to accrue:…/technical-debt-

  • Michael Letterle

    "If some or all of the team requires training, and worse, if they are resistant to changing their typical modes of writing code, then trying to deliver higher quality is likely to require significant investment in time and energy. The customer should be the one who gets to choose if this is a worthwhile investment for the project at hand."

    This seems to be the crux of your argument. Just prior to that you even state that quality tends to be a worthwhile investment. Frankly if your team is this much of a hindrance to delivering quality software, time for a new Team IMHO. 🙂

    Also, I think the whole /point/ of looking at Software Development as a "craft", is that all Software Craftsmen have a basic level of skill.

    Yes, there are times and places for a Quick and Dirty Hack, but not having a team /capable/ of something better is NOT acceptable.

  • Michael Letterle

    As a follow up, using your contractor example. The contractor didn’t offer you that option because he and his team /couldn’t/ offer a high quality finish, he offered it based on your needs. BIG difference.

  • Ron Jeffries

    Certainly it is possible to over-finish things. However, in over a decade now of helping teams be more successful, I’ve seen no cases at all of overbuilding, and many where technical debt has slowed the project to near zero.

    As for the notion of "dogma", I find it dismissive. There’s real value in most ideas about software development, including the "Agile" ones, and dismissing them is, in my opinion, imprudent.

    There are many ways to do software successfully. I think doing it well enough is always important. Doing it poorly rarely works. The question to ask and answer in this regard is "how good can we be without slowing down," not "how bad can we get away with."

    All IMO, of course.

  • Steve Smith


    Quite right, in my contractor example, he let me (the customer) make the decision of what kind of tradeoff I was willing to make. That’s my point. If one is has the skill, then I wholeheartedly agree that it’s possible to deliver high quality software at least as quickly as one can crank out crap. But such skills are not universal.

    I think it is typical that writing quality code involves a tradeoff between short term throughput and long term throughput. For experts in the game, this may not be much of a tradeoff, but for many it’s measurable. It’s where technical debt comes from, as is discussed here:…/technical-debt- If everyone did everything right all the time and felt no pressure to cut corners, there would be no such thing as technical debt. That it exists (and in fact is rampant, in my experience) indicates that in many cases developers choose expedience over quality (either explicitly or through not knowing better). My point with this post as regards pragmatism over dogma is in agreement with Ron Jeffries’ post that the customer needs to be kept informed, and ultimately in control of what they are paying for.

  • Steve Smith


    Hmm, between you and Corey Haines’ tweets I’m thinking I may have misrepresented my position. I’m not advocating "do it as cheaply and quickly as you can get away with" and I am certainly an advocate of quality code. I take the long view on it and fully realize that most development effort is spent on projects post-shipping, not pre-shipping. My points about dogma were mainly directed at certain comments I’ve heard in private, so perhaps the lack of context of my response to them is hindering my ability to convey my position there. Or perhaps we really do disagree.

    My point is simply that a craftsman in any trade knows how to produce a quality good, but should also be able to trade quality for cost effectively if it better suits the customer’s needs. To use a common example, if the customer needs to be able to demo something in 4 weeks at a big trade show, buggy or not, then a true craftsman (and professional) would not let dogmatic attachment to "the right way to write code" stand in the way of meeting the deadline (and incurring technical debt). If the demo goes well and the product needs brought to market, then naturally that technical debt will need paid off at some point (in one way or another). Being able to make that choice is what I consider, as a business owner, pragmatic.

  • Michael Letterle


    I certainly recognize the business pressures to get code out the door. But if we continue to accept that the skills to write quality software are not universal, then they never will be.

    For instance, the trivial programs you mention interns writing are the PERFECT opportunity to teach them best practices.

    Similarly if members of the team are unable to use best practices then time should be set aside to train them before having them work on customer facing projects. And if they are UNWILLING to learn, then frankly they should be fired.

    In other words, I find this statement "If one has the skill, then I wholeheartedly agree that it’s possible to deliver high quality software at least as quickly as one can crank out crap. But such skills are not universal." frankly dangerous. It’s high praise of the status quo, something that looking at our industry as a craft is meant to change.

    This implies that Customers are not the ones driving our development practices, but our own team’s incompetence. Unacceptable. If the customer wants it in a week, and we know it’ll take two weeks to do it "right", then we cut corners to get it out in a week. That’s an acceptable case. Cranking out crap because we don’t know any better, however, is not.

    All my humble opinion of course.

  • Steve Smith


    Several good points. First, you say "if we continue to accept that the skills to write quality software are not universal, then they never will be." Accept that they never will be universal. The 22yo college grad is never going to have the same skill level as the 52yo software veteran. There will always be a range of skills, and the 52yo craftsman will learn something new every day.

    Yes, of course we train our interns as they work on non-mission-critical applications. But we’re a small business, and sometimes the interns are left to their own devices. Know that will be the case, it’s best they be working on things that won’t cause too much damage if they’re not done perfectly, and which we can always review and teach from if they go down bad paths.

    I agree that developers who cannot use best practices should be trained, and those who are unwilling should be replaced. However, as a consultant one doesn’t always have the authority to dictate which members of the client’s team stay or go, and in any event the organization may not budget for necessary training. Reality once again intrudes upon the ideal we both agree on.

    Claiming that skill levels are not universally high is not dangerous, it’s fact. I work very hard to keep my skills high. I do my best to ensure my team is extremely proficient as well. But it’s ludicrous to think there is not variation in skill levels in our industry, and more optimistic than I care to be to think that will ever change (see my first point about the 22yo vs 52yo).

    My entire point is that customers need to be the ones driving decisions made about quality. Once again, we agree. You say "If the customer wants it in a week, and we know it’ll take two weeks to do it ‘right’, then we cut orners to get it out in a week" which is exactly my point. There are some who disagree, and would tell the customer it will simply take two weeks, and deny them that choice.

  • Michael Letterle


    Of course a 22yo is not going to have as much refinement and skill as a 52yo, but is it unreasonable to not expect CRAP out of a 22yo? Or at least a willingness to learn how not to create crap?

    Is it unreasonable to ask that even a 22yo has some basic knowledge of how to produce quality software (albeit incorrect due to lack of knowledge) before being called a developer?

    Is it unreasonable to try and improve the overall skill level of those who practice the art of software development?

    Imagine if we took the same approach to the plumbing profession.. imagine all the stuffed drains. Talk about delivering crap! 🙂

    I’m glad to see we agree on the very basic level, your points are mostly valid, but I believe the industry can be improved and that it is a worthy goal to work towards.

    Will we have an industry full of Code Mozarts? Of course not, but everyone should know how to play Flight of the Bumblebee at least…

  • Evan Light

    I may live to regret this but…

    @Michael et al.

    In some of the circles I’ve worked in, I’ve seen several 52 years old that should have been benched years ago and 22 y/os who should have replaced them. I’ve also seen the reverse.

    I’m seeing a lot of extreme positions adopted in this dialog.

    I could not agree with Steve more when he says "My entire point is that customers need to be the ones driving decisions made about quality".

    The customer pays for the project. Period. He has the dollars. Whoever has the dollars makes the rules.

    While in their employ, we are ethically bound to attempt to provide them with the information to aid them in decisions effecting their project — including the quality of the output product.

    To many customers, terms like "code quality" do not resonate. If they are instead framed in the context of money, "higher cost of ownership", "anticipated maintenance costs", etc. that’s something that a customer can wrap their brain around.

    However, many customers don’t care about the long term. That’s entirely their right. While that may trouble craftsmen such as I presumably call us all, it’s also our choice whether we want to work with such customers.

    If you work as a consultant, it’s your right to fire the customer as well. It’s a value proposition just as for your (potential) customer.

  • Corey Haines

    I’ll be posting a response on my blog tomorrow morning. I have it written, but want to let it sink in a bit.

  • David L. Penton

    Posted on twitter (via @dpenton)

    Consumers make choices all day long about their purchases – what brand of gas to buy, what crackers, yogurt, milk, cheese.

    The house they buy/rent, apt also. Car/truck/van etc. Each of these has a specific amount of craftsmanship, good or bad.

    Home stereo components? Same thing. I can spend 10k on a single speaker and expect a certain level of craftsmanship.

    Is software development somehow not like that?

    I can make a table out of white pine 2x4s only if I want. A better 2×4 is ash. Is it a better table? What if I use a better blade?

    Now, what about how I cut it? How I join the wood? How I sand it? What if this table was just a workbench in the garage?

    What if it was a table as a central piece in my living room?

    Are there actual levels of acceptable development or only one? Who chooses that? Where are the lines drawn?

    Are these standards personal or measured? Should they be?

  • Corey Haines
  • Brief Response to Corey on Software Craftsmanship

    Corey’s blog’s comment box is failing, so posting my response here.  Read his response to my post for context.  Below is simply cut-and-pasted from a comment I was trying to leave on his blog: Hey Corey, thanks for the well thought out comments

  • On craft, dogma, pragmatism and better analogies

    I’m leaping into a lengthy discussion, so I’ll start with the links: Steve Smith wrote this post discussing

  • Ilja Preuß

    "If some or all of the team requires training, and worse, if they are resistant to changing their typical modes of writing code, then trying to deliver higher quality is likely to require significant investment in time and energy. The customer should be the one who gets to choose if this is a worthwhile investment for the project at hand."

    You can certainly work in such a mode, but then you wouldn’t get me to work for you.

    I prefer to work for companies that invest in their employees, both because they feel responsible for their development, and because they know that it will pay back.

    And if you have people on your teams who don’t want to improve, you might want to rethink your hiring practices. Or, perhaps even more importantly, your company culture.

  • Ilja Preuß

    Oh and regarding "Savings from a relaxed ‘degree of finish’" – a well trained developer knows how to save time and money by proposing alternative, less polished implementations of a feature, *without* having to compromise code quality. In fact that’s part of my daily job…

  • ssmith


    "you wouldn’t get me to work for you" – I guess it wasn’t clear that I’m not suggesting my own employees fall into this category. However, it’s not uncommon as a consultant to find such things within client’s organizations.

    "a well trained developer knows…" sure, but what about when we’re talking about less-well-trained developers? Their default mode of operation introduces (unintentional) technical debt, but delivers features. You’ve just been brought in to teach C# and .NET for a project with a team of these developers. It needs to ship ASAP. You’ll only be spending a few hours each week with the team. The customer knows that eventually they want the team to be well-trained, but right now they just need to be *productive* in C# and .NET. Is it ok to skip advanced topics like DI and SOLID or to use a RAD framework that is tightly coupled to the database if that gets the job done quickly (which is what the customer is demanding, fully aware of the long term technical debt involved)?

  • ssmith

    Go read this if you haven’t:…/technical-debt-

    What I’m talking about here primarily relates to taking on strategic, intentional technical debt from the point-of-view of the well-informed customer (business owner).

  • Anthony Broad-Crawford

    I wonder if we are confusing the "practice" with a particular "project". I absolutely agree with most of the concepts being discussed towards the practice of software engineering (the art, the craft). However, to Steven’s point, those processes / methodologies/ practices will always vary to some degree from project to project.

    I have always had some damn variable which takes you away from being able to do it the completely preferred way. It could be time, team, money, tools, you name it. Do I need to practice so those constraints are diminished in most situations, absolutely. Is it possible to remove all unwanted variables? No.

    In my opinion, for a particular project, the customer will always set the standard for quality. So long as we inform them (per Evan Light’s response). Then, if you don’t want to build the product to their level of quality or the process they prefer, I guess you can walk away if you so choose. That’s your choice and control in the project.

  • What is good? « Anthony Broad-Crawford

    Pingback from What is good? « Anthony Broad-Crawford

  • Craftsmanship, Quality, Dogma, and Pragmatism

    Steve Smith has some interesting things to say about one of the passionate debates of the day among developers:

  • Software Quality Digest – 2009-02-25 | No bug left behind

    Pingback from Software Quality Digest – 2009-02-25 | No bug left behind

  • Links


  • Ilja Preuß

    I’ve worked on a couple of such projects – short, only "standard" functionality, CRUD projects. In hindsight, I think that using a quality approach would have been faster and cheaper.

    The customer can only set the standard for external quality, because that is all he sees. He cannot set the standard for internal (code) quality, because he doesn’t understand it.

    Last but not least, it’s no surprise to me that if you don’t have craftsmen on your team, you can’t apply craftsmanship to the project.

  • ssmith


    You’re making too many assumptions. What if the customer is a developer, who sees and understands the code and any technical debt associated with it? What if the time required to train the team up to where they can produce what you and I consider quality code is longer than the time available to ship something?

    Your last sentence is dead on. In the case where the team simply doesn’t have the skillset and a deadline is looming, you sometimes need to ship "as good of quality as the team is capable of in the time allowed".

    The customer *could* decide it’s worthwhile to get everybody trained up to a high standard before shipping anything. That investment would likely result in lower TCO over some period of time and ultimately no doubt would be a good investment – if the business survives. But sometimes business needs dictate short term decisions that may not be in line with ideal long term investment goals (think why companies keep any money in non-interest bearing checking accounts when CDs and other investments have better ROI – liquidity is necessary).

  • Ilja Preuß

    Re: technical debt

    This is not just a boolean decision of producing technical debt or not. It’s a question of which parts of the code could take some technical debt, when and how you can get rid of it again etc. pp. This needs to be someone who doesn’t just understand code, but *the* code. And you only can do that if you are actively working on the code, for a considerable amount of your time, if you are *feeling* the impact on the code.

    Our CEO is the original developer of a critical component of our product. I’m convinced that if we had followed his suggestions on cutting corners, that component (and perhaps even the product) wouldn’t exist any longer – maintenance would just have become too expensive. Fortunately, he was smart enough to just ask questions and let the developers make sound technical decisions.

    I consider myself to be technically rather savvy, but I wouldn’t imagine telling the development team of my favorite IDE where to cut corners. I simply can’t, because I’m not coding it.

  • Ilja Preuß

    Re: training

    I don’t know anyone who has ever suggested to train up your beginner level programmers to a high standard before shipping anything. That would just be economically stuppid, it seems to me.

    What I’d suggest is to give that team an experienced developer as mentor, train them while they are developing shipping software, and holding them up to an as high standard as they are capable of producing.

  • Joe Brinkman

    Everyone keeps dancing around the white elephant in the room – there is no common definition of "best practice". We all have varying degrees of what we consider to be good software practices, often based on many years of development experience and training. Nowhere is this more apparent than in the discussion of why we have FubuMVC even though MS is getting ready to ship ASP.Net MVC. This occurs because two different groups of highly competent developers have different thoughts about how to build software – what is acceptable and what is not. Often discussions of dogmatic thought occur because one group of developers assumes that they know/employ the one "right way" to develop software and act condescendingly towards anyone who does not follow those same development practices.

  • anonymous

    I think Corey Haines has hit the nail on the head:

    1) Pick a line of work

    2) Wake up one morning and call yourself a crasftman in that line of work

    3) Don’t proceed quietly, honing your craft every day to the satisfaction of what you claim to truly be interested in, rather (see #3)

    3) Begin travelling around and meeting with others who want to hear you pontificate. Once they have been in your presence, call them crafstmen too.


    The best thing is this… let’s start doing this in other areas of science/business/arts/technology.

    Maybe for Doctors? Carpenters? Architects? Firemen? Astronauts?

    Maybe people on all of these fields do not really need to contribute other than travelling to other people’s houses, pontificating, then granting them the title of crafstman as well.

    Awesome… I am healed and enlightened by Corey Haines.

  • Ilja Preuß

    It is always easier to misrepresent someones view to use it for ridicule, than to seriously look into a foreign opinion. Especially if you are doing it anonymously, I guess…

  • Alex

    Quality can be sacrificed in order to meet business needs for sure.

  • Nair

    Question, would you trade off TDD for quality? There are situation where we need to develop a software it not as important as the critical bussiness process but it is required. When developing those application, do you think skipping TDD is applicabale? Just curious.

  • Conciant

    I like your post, it’s a really good stuff, keep it up! Office Conceirge has another benefit that it is economic too