Do we care whether it's Software Engineering or Craft?

Much like a tenet of agile software development is that "planning is more important than the plan," there are some questions about software development that are useful to explore, even if you can't suggest a good answer. One of these these is whether what we, as software developers do, is (or can be) engineering.

I was talking with a colleague about a comment someone made about a post about lessons that software engineers can learn from artists. In this comment the poster raised an issue that comes up a lot when someone uses the phrase "software engineer." The question was, in essence:

Is what we do when we build software "engineering" or "craft?"

My colleague, who has a background in Naval Engineering and who is engaged to an Electrical Engineer (who designs and builds hardware) suggested that the difference is that one rule of thumb might be:

It's engineering if you need to use calculation (about physical constraints).

An example was that to build a bridge you need to do calculations to determine if the bridge, as designed, will support the load you want to support. Many of the "classical" engineering disciplines (Mechanical, structural, electrical) fit that criterion. But by that definition, some things which most would agree that are crafts, such as carpentry, involve calculations. So there is probably more to it that that.

On the other hand, I don't think that all work that is in a discipline that we might call "engineering" is engineering. A good friend designs test equipment for a living. When he builds a sensor to measure the performance of his home heating system is he doing engineering, or is that activity more like a hobby or craft?

As I think of the question, and the frequency at which it comes up, I wonder:

Why does it matter whether we are software engineers or software craftsmen?

Engineering, to me, implies a certain level of discipline are repeatable process, and all of the classic engineering disciplines are grounded in physical laws that we are fairly confident in for the scales at which they apply.

If the "software engineering" question is important to you, take a minute to understand why you are asking the question, as the reason for asking may affect the answer.  You can bring discipline to building something you regardless of whether or not you are engineering. I don't think that the question of how (or whether) to make software into an engineering discipline is an unimportant one. But I do think that it is often asked in a vacuum, much like the an attempt at a user story that is missing the "so that..." clause.

To me, as a professional, it's more important that I bring discipline to what I do. I want to build useful, quality, software where the definition of "quality" that is often most appropriate is Jerry Weinberg's from Quality Software Management: Systems Thinking:

Quality is Value to Some Person.

It might be fair to say that we're not always "crafting" or "engineering" software when we sit down at an IDE and program. Sometimes we're just coding (or hacking, or programming). But if you (and your team) are committed to building software that meets your customers needs, and you are always working to learn how to work better, you're doing a good thing. And you don't need to call it engineering to acknowledge that.

Agility (and Learning Opportunities) Everywhere

People often ask "can I apply agile methods to something other than software development?" Since the basic appeal of agile methods is to acknowledge uncertainty by planning in increments, evaluating where you are relative to the plan and other forces, and planning the next increment, it seems like there should be no obstacle to following an agile approach for any project. The lurking question many have is "but can my type of project really be structured in an incremental way?"

While in general, I tend to believe that the answer is "yes," it's always good to have examples. So I was intrigued to head a segment on the radio show Living On Earth, where the rapper Baba Brinkmann described his approach to developing The Rap Guide to Evolution as "Performance, Feedback, Revision," which is a very concise way to describe an agile approach. This meta-aspect of this also intrigued me, as Brinkman used the performance, feedback, revision theme in the evolution rap as well.

This is also another reminder of how software developers can learn much from many seemingly unrelated domains. As Rob Austin and Lee Devin explore in Artful Making: What Managers Need to Know About How Artists Work managers, including software managers, can learn from theatre, and in Computers as Theatre Brenda Laurel discusses what interaction designers can learn from theatre.

So, yes, you can be agile if you are doing something other than software, and if you are developing software you can learn how to build software better by looking at other disciplines.