Craftsmanship

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 its a good thing. Theres an online email list. a conference with the same name. and at least one user group devoted to the subject (in related news, Im 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. Ive heard from several successful business owners that they dont 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 dont 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 isnt that important which, taken completely out of context like Im 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 dont 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 well 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 didnt 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 customers needs. As a very real example, Im getting some work done on a building to which (hopefully soon) well 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 tenants 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. Its important to be aware of how to overcome complexity and avoid future technical debt using appropriate patterns and practices, but its 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.

3A%2F%2F1.gravatar.com%2Favatar%2Fad516503a11cd5ca435acc9bb6523536%3Fs%3D80&r=G /%

About ardalis

Steve is an experienced software architect, trainer, and entrepreneur. His courses on Pluralsight help developers write better, more maintainable code. He is currently serving as CTO for Falafel Software, and is a Microsoft Regional Director and MVP.

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: xprogramming.com//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 didnt offer you that option because he and his team /couldnt/ 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, Ive 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. Theres 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

Michael Letterle

@Steve

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 its possible to deliver high quality software at least as quickly as one can crank out crap. But such skills are not universal. frankly dangerous. Its 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 teams incompetence. Unacceptable. If the customer wants it in a week, and we know itll take two weeks to do it right, then we cut corners to get it out in a week. Thats an acceptable case. Cranking out crap because we dont know any better, however, is not.

All my humble opinion of course.

Steve Smith

@Michael,

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 were a small business, and sometimes the interns are left to their own devices. Know that will be the case, its best they be working on things that wont cause too much damage if theyre 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 doesnt always have the authority to dictate which members of the clients 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, its fact. I work very hard to keep my skills high. I do my best to ensure my team is extremely proficient as well. But its 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 itll 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

@Steve

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!

Im 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 Ive worked in, Ive seen several 52 years old that should have been benched years ago and 22 y/os who should have replaced them. Ive also seen the reverse.

Im 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. thats something that a customer can wrap their brain around.

However, many customers dont care about the long term. Thats entirely their right. While that may trouble craftsmen such as I presumably call us all, its also our choice whether we want to work with such customers.

If you work as a consultant, its your right to fire the customer as well. Its a value proposition just as for your (potential) customer.

Ill 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 24 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?