Good software development is a craft because it produces a result that is both functional and beautiful.
If we produced software according to rigorously defined rules of what's "true in the universe" then it might be a science, or an application of "engineering" principles. (Programming As Engineering. So I guess beautiful buildings are a result of architecture, not engineering.)
If we produced something beautiful (or pleasing to us), but not functional, then we would be doing art. (Programming As Art)
As craftsmen (and -women) we should feel proud that we produce high quality product that serve a very useful purpose. Discipline Envy is for those who don't really know what they're doing.
Recently. I have heard talk about formalizing patterns and proving that the concept has scientific validity... Well, sometimes I need to remind myself why I develop software and write patterns:
Sometimes we forget that most of software development is about people. Ultimately ,the greater percentage of software modules and programs written will be viewed and/or used by other people.
When we forget, we tend to tack on interfaces, write end-user manuals to explain the tricky concepts, and allow cryptic error messages like abort: system error to explain to a user why something doesn't work.
We also tend to resist viewing design and implementation as true legacy to be left behind for others developers who follow. What we leave behind should, above and beyond technical content, adequately communicate design and implementation issues (the why and how) to the future developers.
As much as we like to view software development as
applied science or
engineering, we must also remember that it is a craft. It takes good taste and carefully thought out design to make useful software.
You don't need fancy GUIs, animation or sound to make friendly software. You need sound technical skills, a passion for quality, and an open mind.
-- Todd Coram
There is a lot of pressure in the worlds of both academe and business to formalize software analysis, design, and engineering into more of a science and less of a black art. Personally, I think they're flogging a dead horse.
Yes, much of software engineering can be formalized into rules, patterns, methodologies etc. Just as an artist must follow certain rules when mixing pigments to get a specific colour. But what remains is down to individual skill and experience.
If it was a pure science, anyone could do it and excel. But it's not. You need a particular mindset and enthusiasm for the job. The programmer who thinks they've learnt enough will probably never be a software artist.
I take some exception to this pejorative view of science. After all, scientists consider themselves artists, not just craftsmen.
Engineering is neither pure science nor pure craft. It is the artful mix of both. Creating a product (any product) requires imagination. This is art, pure and simple. Building complex products requires science. The successful engineer must master both. Many in software have mastered the art, none have really mastered the science. Too bad, because we could produce truly elegant programs that really work as they are intended to work.
I am reminded of Guitar Craft (www.cs.man.ac.uk ), a conscious course of study turning guitar playing into a craft. I've never taken the course, but I would love to some day.
-- Kent Beck
There's a very well established pattern lore in the Game Of Go - I'm surprised no one here has referred to it before. Go-playing is a 4,000 year-old craft whose study involves extensive examination of patterns (joseki) and heuristics (proverbs). The theory is that knowledge of the craft of Go is absolutely fundamental to the production of Go as art - and as the art is codified, it becomes craft. Art is just the bleeding edge of craft. -- Peter Merel.
Work -- to satisfy your boss.
Craft -- to satisfy your customer.
Art -- to satisfy yourself.
There's more to it than this, I'm sure, but I find these distinctions useful. -- Ward Cunningham
See also Turkish Crafts.
I heard the following the other day:
If you work with your hands, you're a mechanic
If you work with your hands and your head, you're an artisan (read craftsperson)
If you work with your hands, your head and your heart, you're an artist.
Since patterns create elegance, I think they are especially good for those that work with their heart as well as their head.
I disagree. (1) A really good craftsperson works with their heart too. I used to know a drum-maker who lost money for years because that was what he really wanted to do. (2) Do composers and poets work with their hands?
(1) A really good craftsperson who works with their heart is an artist.
(2) Don't composers and poets write down in some form what they create?
Check out the Chuang Tse version on Cook Ding
I love the idea of Software Development As Craft, but every time I see the writings of Jim Coplien, Kent Beck and others where there is so much, dare I say, love of doing a good job and the right specialized job for the situation, I just get the feeling that it is great, but someday, inevitably, technological advances will come along that will render our lore of craft useless.
Unlike art, where something like Robert Fripp's Guitar Craft is sustainable, we have to deal with creeping standardization and competitive pressures that tend to churn and antiquate methods. While the spirit of inquiry and the love of doing and doing it right will never go away, the particular knowledge and heuristics or content of the craft will. Things are already changing. I see Extreme Programming as something along the lines of "good enough software" along with Microsoft's synch and stabilize methods. More programmers are employed now than ever. I don't think that the craft model will be sustainable in the face of pressure to drive costs down.
Synch and stabilize is good. Knowing what is "good enough" is good. Software costs are not necessarily reduced, however, by deviation from a craft model. In XP we strive to do just what the customer needs, provably correctly, as fast as possible. That's craft, I submit, and it's hard to beat. -- Ron Jeffries
Component-driven design in particular is ascendant. We should be assembling more and more of our systems these days. We are living in the age of the cobbler-artisans. Will we maintain our pride and identity in the face of people who just want $20 shoes? I see how the pride in craftsmanship over the years has changed towards pride in giving the customer what they want. And that is good, it is what we are paid for. It looks like there will be more of that. But, to respond to Ward, will there be enough art to keep us happy?
I used to think payroll was easy. We export over 1000 values per person to around 20 downstream programs. There are about seven savings plans, half a dozen different ways of supporting people who are laid off or ill ... it goes on and on. No one is ever (IMO) going to build systems that complicated the way $20 shoes are built. More components, yes. Less craft? Never.
Designer software, with the Extreme Programming logo on it. Costs more, but your friends know you're cool. I can go with it. -- Ron Jeffries
I want to be doing this 20 years from now. But it is going to be different. OO will be old school. -- Michael Feathers
Why not look at our forbears - the realware architects and engineers? Their domains are simpler than ours. After all, how many ways are there to build a building or bolt together a bridge? Yet no one imagines the end of realware architecture or engineering any time soon.
Certainly there are track housing projects and robotic assembly lines. Certainly there are slums and malls. But the engineers continue to provide value so long as there is a market for more complex, more refined and more maintainable products. That market isn't going away so far as I can see.
Instead, the productivity of an engineer increases with time. His tools get better, get meta, get standardized, and get obsoleted by new tools, but so long as he keeps up and learns to use what is at hand his drive, discipline and spark will be in demand. He might not be making the same old nuts and bolts any more. He might be making things with the things that the nuts and bolts made. But that only makes his job more interesting.
I expect, being of that bent, that one day our skills will no longer be required. At that time I expect that no human skill will be required, for then we will be bootstrapping ourselves to Trans Humanity. Sure, we'll no longer be making $20 shoes. We'll be making the machine that makes $20 shoes, and then the machine that makes that machine, and then the machine that makes that. Eventually one or more of us must be making the machine that makes us, and then that machine will make the machine that makes that machine, and so on ad deity.
I've already made three of the 'machine that makes us'. I call them Gregory, Tommy and Andrew! -- Kiel Hodges
Just when this Technological Singularity might arrive, I have no idea - I'd bet it'll be more than 20 years and less than 200. But I expect even then our poor mental porridge might serve as the germ of the transhuman equivalent of an originative engineer, and so our craft would continue on, not superseded, only vastened.
-- Peter Merel
I've seen the analogy of producing software to making shoes and the analogy of producing software to constructing buildings. But software is infinitely malleable. The appropriate analogy is to making shoes
and constructing buildings
and building airplanes
and creating and running organizations
and constructing roads
and making appliances
and so on...
For the foreseeable future, the craft will survive. It will change as it has since the beginning; that's one of the appeals for many of us. But as some things become more cut and dried, new opportunities will arise in unforeseen areas. The craft will live on.
-- Kiel Hodges
When I watch Star Trek The Next Generation and Star Trek Deep Space Nine, and see how much trouble the people have making the holo-deck do what they want, I say "there will still be a need for programmers in the 24th century."
This is something that comes to mind every time another salesman gives his spiel about how his product eliminates the need for programmers. Please go ahead and try. I say; it'll reduce the tedium, but it won't eliminate me. -- Jeff Grigg
Programming will endure. Teach Me To Smoke.
This discussion of craft seems to miss the social aspects, in particular the notions of apprenticeship and peer judgement. Many skilled crafts take place either on site or in a workshop (or, if you count dance musicians, in a band). This is where Extreme Programming looks right because it has good mechanisms for passing on skills and for keeping an eye on what people are doing as it develops. There's also an element in many crafts that, as you get better, you either specialize in the hard bits or get more supervisory. I suppose this would be like a coach in Extreme Programming.
I was listening to Jacques Pepin talk about his apprenticeship and he was saying that "after a year he graduated to the stove." Maybe we need this kind of thing in programming - a year of grunt work that teaches you respect for the tools, the materials and your master. But what would you do in that year? In Germany they still make apprentice machinists file a metal cube by hand for the first four weeks. It's completely "unproductive" but, man, does it teach you about tools and materials. --Andrew Queisser
If you start talking about this stuff and people seem to be arguing with you for reasons you don't understand, remember that some of these terms are very slippery. I love to talk about what I do as a craft; the word seems absolutely right to me. It captures the blend of beauty and practicality, the need for compromise, the amount of instinct and taste involved and the occasional difficulty of explaining decisions and reasoning to others, etc. But I have a colleague - a terrific programmer - who considers the term an insult. To him, a "craft" is a hobby (he associates it with "arts and crafts", and not in the sense of a style movement). So when someone says that programming is a craft, he feels it as an accusation that he gets paid for doing something useless.
(I think he's wrong, incidentally, but it helps me to know that some people understand the word that way.)
Likewise the word "science." Above, Dan Rawsthorne said this:
I take some exception to this pejorative view of science. After all, scientists consider themselves artists, not just craftsmen.
But there are at least two meanings of the word "science," and Dan was responding to someone who used it in the sense of "he's got that down to a science," meaning that it could be done mechanically without thought. I know that that meaning of the word comes from a naive and incorrect popular view of what real science is, but nevertheless that is what the idiom actually means. -- Glenn Vanderburg
See: Is Computer Science
See also: Art Craft Soft Science Hard Science
Contrast: Software Development As Labor
See original on c2.com