Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Software Development: Art, Craft, or Science

August 21st, 2008 · 11 Comments

Is software development a science?
I was required, as a Mechanical Engineering major, to take a C class on solving math problems with software. We didn’t talk about design patterns, or interfaces, or even clean code. We talked about theories of convergence and divergence, of Newton-Raphson, and progressively better guessing. Our work was judged based on its efficiency and accuracy at solving an equation. That was science. And math. It was also one of the reasons why I didn’t study computer science back then – I saw CS as just that. Using programming to solve progressively harder math problems, and of the science behind complex algorithms.

Software development, in the average sense, is far removed from that C class I had in college. In the last eleven years, I have only written software to solve a mathematical problem once, and that was related to smoothing a curve so that a machine could cut it more smoothly. The rest of the software development I’ve been involved may have been programmatically complex, but it was always scientifically simple. There’s nothing all that scientific about determining whether an unemployed mentally ill person qualifies for state benefits or integrating a back-office billing system with an IVR system to calculate how many minutes are left in your cell phone plan.

I don’t really think of software development goodness as being grounded in provable scientific principles. You can’t test a software application the way you would test a scientific postulate or mathematical theorem and decide that one application is “true” (and proven) while another is not. If you asked 100 different rocket scientists what the fundamental scientific laws were behind calculating the thrust of a rocket engine, invariably the three laws of thermodynamics would come up. But ask 100 software developers what the fundamental principles of software development are and you’ll get 85 different answers.

This may in fact be due to the relatively low barriers of entry into the software development field (as compared to the rocket scientist field), which results in a far lower formal education requirement than rocket science. Take me, for example. I was a rocket scientist who became a software developer, with nothing more than a fortran for babies class to go with the C class I already mentioned. Now try to go the other way and make a computer science graduate a rocket scientist. It’s possible, but not common or easy. Combine that with better pay in 1997 for software developers than rocket scientists and you’ve got a flood. Anyway, the point of this digression is that there may be scientific principles out there that “real” computer scientists know but hacks like me don’t. I concede that.

Does that make it art?
But… does the fact that software development isn’t really “science” per se make it art? I sometimes find myself feeling that way, particularly when I see a young software developer who instinctively writes good, clean code and then compare him to a crufty code factory with 30 years of experience. But I’m not sure. How would I know if software development was an art? What are the rules, and why does it matter?

If software development is an art, then the importance of sheer talent increases dramatically. That appeals to me. But the importance of form over function would also seem to rise, which doesn’t really sync with me. How many times have you bought software JUST because it was beautiful? Or because it matched the colors in your bedroom? Granted, I won’t use Open Office because I think it’s ugly, but I also won’t use Apple Pages (which is quite attractive) for complex documents because it doesn’t give me what I need.

At the workshop on technical debt that I attended recently, a few people proposed that software development was a craft. So I looked up craft in Webster and here is what I found: an occupation or trade requiring manual dexterity or artistic skill. Hmm. Well, typing requires manual dexterity, but I don’t think that is enough to make SD a craft. The notion of requiring artistic ability appeals to me though.

Is artistic skill required to make good software?

I don’t think so, at least not on average software development projects. I think we routinely make good software with average, not-particularly-artistic developers all the time. So why does this notion appeal to me?

I think it’s because good software development has always seemed very difficult to teach and because there are so many different opinions on what makes software “good”. It’s almost as if, kind of like art, I can’t tell you exactly what I like about “good” code, but I certainly know it when I see it.

That was before the Workshop on Technical Debt. Chet Hendrickson and Ron Jefferies shared something there with us that I found to be very eye-opening. The attributed it to Kent Beck, and it immediately stuck for me.

Four rules of simplicity in software
Good software will do the following, giving preference to the earlier rule when there are conflicts between them:
1) All tests run successfully
2) There is no duplication
3) It expresses all ideas relevant to the problem
4) It minimizes all architectural artifacts

This article isn’t about these rules, but my sudden awareness of them made me re-think my opinion about whether SD was science. Are these fundamental “laws” of software development? Certainly not in the sense of being provable. But they are logical and they clearly work in terms of following them will help create clean, maintainable code.

I could go on about art, science, and craft for thousands of words, but I’ll spare you. Let’s just jump to my conclusion of the day. It may be different tomorrow, but here is where I stand at the moment.

Software Development is Best Thought of as a Medieval Trade
In medieval times, tradespeople learned how to perform their profession from other tradespeople in a fairly well organized guild system. They progressed through various levels of their trade in different ways, but it generally worked something like this:
Acolyte -> Apprentice -> Journeyman -> Master -> Grand Master

Tradesman with a natural talent (the artistic ability we mentioned earlier) progressed more quickly than those without, but even the un-gifted could participate in the trade as long as they could attain competence. Not everyone had what it took to become a Master or Grand Master, but those with special gifts of talent and the luck to live long lives could attain those levels.

Journeyman tradespeople had responsibilities to teach the apprentices the principles of their trade. This principles weren’t based on science so much as they were based on practice, and as a result different guilds had very different sets of principles that they taught.

Another interesting aspect of this system that is interesting to me is that progression was based on self-selection. You weren’t a journeyman because you said so, or because you took a test, but because your peers respected your abilities.

I think software development is similar. Kent Beck isn’t famous (at least to the degree that geeks can be famous) because he has a certain degree or because he is a certified Grand Master, but because we respect his accomplishments.

I wish software development was organized a bit more like medieval trades, a point that Brian Marick sort-of made at the Workshop on Technical Debt when he indicated how much we need to imprint good practices on young software developers in a systematic way. I wish we really entered the system as apprentices and were attached to a journeyman until we were skilled at the trade, in a formal way.

Software development guilds in the modern worldландшафт
I believe there are currently many different software development guilds out there. They each represent a certain set of principles they believe in and teach to each other. Because they aren’t always formalized, it isn’t always obvious that they aren’t the same. The good practices from one might become bad if mixed with the “good” practices of another, but some might transcend them all.

I think I will end this post with some of the “guilds” that I am aware of. This isn’t an exhaustive list, nor an exclusive one. Some of these guilds might be the same, but with different branding. I’ll miss a lot, and they will probably overlap. And, the point here is not so much to be precise and “right”, but to just brainstorm. Here’s what I’ve got:

  • The Specialist Guild
  • The Generalist Guild
  • The XP Guild
  • The Open Source Guild
  • The Proprietary Software Guild
  • The Command and Control Guild
  • The Community Effort Guild
  • The Waterfall Guild
  • The Context-Driven Guild (the agnostics!)
  • The Sustainable Pace Guild
  • The Even Monkeys Can Code Guild
  • The Pragmatic Practices Guild
  • The Agile Guild
  • The Test First Guild
  • The RUP Guild
  • The Experts Only Guild
  • What guilds do you belong to? What practices do they represent?

    If you enjoyed this post, make sure you subscribe to my RSS feed!
    Stumble it!

    Tags: Uncategorized

    11 responses so far ↓

    • 1 Matt Heusser // Aug 21, 2008 at 10:11 am

      Part of what makes it craft is that a defined process doesn’t close to cover it. You have to -experience- it and consciously learn from that experience to get better.

      Sure, a book could help – Bob Martin’s Clean Code or Kent Beck’s Implementation Patterns are both attempts at this – but you could still give the same requirement to five different devs and get five completely different, yet correct-enough, answers.

      Corporate America likes defined process. But try selling your defined process to a golfer; he’s say you’re on crack, get your clubs and let’s play and learned from that playing. :-)

    • 2 Matt Gumbley // Aug 22, 2008 at 3:54 am

      Nice post, thanks.

      For a book that has a simliar theme, try Pete McBreen’s Software Craftmanship: The New Imparative.

      http://www.amazon.co.uk/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862

    • 3 David Christiansen // Aug 22, 2008 at 7:43 am

      I don’t think software development is a craft. Not in the witchcraft sense or the woodcraft sense. I guess you could call it a craft the same way any profession can be called a craft, like a lawyer who is “practicing his craft” or “plying his trade.”

      Maybe it’s silly to get petty about semantics, so I don’t want to labor this point to much, but I think software development is a trade, just like masonry is a trade. There may or may not be physical laws that govern “good” software, but you don’t necessarily need to understand those laws in order to be reasonably competent. Instead, you need to be skilled at the practices of your trade, regardless of your grasp for its theory.

      People built cathedrals without the law of gravity or an understanding of the chemistry of cement. Developers routinely write decent software without understanding transistors, binary, bytecode, etc. A firm foundation in the basic laws of software development is not necessary to build software.

      That’s what I think makes it a trade. If you are lucky enough to be mentored by an expert tradesman so that his or her practices can be imprinted upon you and creative/intelligent enough to add to them, you can do well even if you never crack a patterns book.

      Some people may be offended by my view that software development is a trade. So is working on cars, building houses, etc. Lawyering, doctoring, and managing are not trades, and some readers may resent not being lumped in with professionals.

      I’m not bothered by it. I think understanding our business as a trade makes it a lot easier to understand how to get better. Practice. Practice. Learning. Practice. Example. Practice.

    • 4 Brian Marick // Aug 22, 2008 at 11:36 am

      I think medicine is a trade and in fact is actually closer to medieval guilds than many modern trades. Certainly it’s taught via apprenticeship and hands-on mentoring.

      “Being a professor” is also a trade, one that’s taught (if you’re lucky) through a master-apprentice relationship with your graduate advisor.

      Generally, I think a profession is just a trade with legal muscle behind it. Does that mean hairdressers are professionals since (in Illinois, at least) they have to be licensed? I’d say yes. If you say no, I’ll amend my rule of thumb: a profession is a trade with legal muscle behind it and enough widely-shared cultural respect. Or, maybe: a legally-backed trade that deals with high-risk matters that make people feel helpless (sickness, legal jeopardy, etc.)

      One thing to remember about guilds: a big part of their purpose was to restrict competition from people not in the guild. Also, I think I remember, competition from people within the guild by establishing a “just price” for guildsmen’s work. I also think I remember that they were not exactly boosters of innovation.

    • 5 Stewart Rogers // Aug 22, 2008 at 1:08 pm

      I did a post that was relatively similar to this awhile back. http://tinyurl.com/6lrj5x There are certainly creative aspects to software development I believe that it a science.

    • 6 David Christiansen // Aug 22, 2008 at 1:52 pm

      Yes, well your definition of science (i.e. no crayons or paints) would call unclogging drains a science. I suppose it might be semantically true, but it doesn’t strike me as being useful.

      Also, the wikipedia definition of science doesn’t correlate to what I know of software development. Software development isn’t about collecting data about reality and modeling in a way that helps us understand it. It’s about solving problems with abstract software constructs that may or may not have any correlation to objects in the physical world.

    • 7 David Christiansen // Aug 22, 2008 at 1:58 pm

      Brian – trade is definitely a loosely defined term and may not be all that useful after all. If you think about it long enough, you realize a large portion of all “work” is based on practices.

      You make good points about medieval guilds. I think the guilds of the software development world are intellectual institutions rather than real ones, but they may still have some of the same problems.

    • 8 Rick Grey // Aug 24, 2008 at 5:58 pm

      I think your rumination around art, science, and craft in software development has a certain appeal, and I think the guild metaphor is an interesting one in terms of bringing the concepts together.

      In the corner of SD devoted to testing (as an activity separate from the unit, system, or integration testing performed by developers themselves), is there room for separate (or sub-) guilds for Software Testers?

      Given the absence of software testing as a standard degree at universities (for the most part) here in the US, and the varying opinions around the value of the various certifications available, in some ways testing has even more of the learn-by-doing and learn-from-others quality than the coding portion of software development. I know I’ve learned a great deal working with teammates, as well as reading the works of Masters and Grand Masters in the field. (Hm, reading books: an indirect form of guild participation not available in medieval times. Does it still count?) All of this causes the Guild concept to resonate for me.

      Bret Pettichord created an interesting framework with which to evaluate different schools of software testing (www.io.com/~wazmo/papers/four_schools.pdf). In it, he describes the:

      – Analytic School
      – Standard School
      – Quality School
      – Context-Driven School
      – Agile Schools

      There’s definitely some overlap here with the guilds you list above, but I would nominate these as a starting point for testing-specific guilds.

      Rick
      Acolyte of the Context Driven Guild

    • 9 David Christiansen // Aug 25, 2008 at 4:49 pm

      Books and magazines are, I think, one of the expressions of a guild. What books do agilists read? Or PMBOKists? Or context-driven testers? It’s really pretty predictable at a certain level.

    • 10 Software Development is an Art, and a Craft, and a Science, and a Profession // Sep 10, 2008 at 11:52 pm

      […] is a followup from my earlier post, Software Development: Art, Craft, or Science. I initially sent it out to the attendees of the Workshop on Technical Debt, since it was discussed […]

    • 11 Who is Guy Nachimson | Yves Hanoulle // Oct 23, 2012 at 3:39 pm

      […] occasional simple computer graphics design work. Sometimes people (who probably don’t think of software development as being a creative craft) tell me I’m wasting my talent. There’s a good chance I’d have become an animator – I […]

    Leave a Comment