As James Robertson points out, there are reasons to favor the Software as a Craft metaphor over the Software as a Factory metaphor. But he writes "software is still a craft" (emphasis mine).
That's almost an apology. I'm not sure how intentional his words align with my interpretation, but the notion is commonly expressed, as if someday it won't be a craft but for now it is. Usually the notion is that someday software will be more like "real engineering".
I've taken another view on these metaphors. Let's forget about factories because 10 seconds of thought informs us this does not fit well at all. So the candidates seem to be "craft" or "engineering".
My view is there are things software developers can learn from various kinds of engineers. Maybe there is something to be learned from legal engineering certification processes. But the lack of doing so is not what makes software development seem craft-like.
I think the "informality" of software makes it feel craft-like. If only we had more formalisms. Could be, but we'll always have "informalities". Every engineering effort, and every creative effort in general, involves many informal conversations.
The difference is perhaps software depends more on informal conversations than do many of the traditional engineering disciplines. The requirements in those disciplines are more formal. Most of software development is really requirements development. The interpretation of formal requirements is most easily expressed in software as tests and code that (correctly one hopes) runs those tests.
I think the key difference between software development and traditional engineering disciplines is not primarily the lack of discipline. Rather it is the inherent predominance of informal conversation and that software development fails mostly due to lack of communication. There is room to improve our formalisms for sure. But those improvements will not replace the focus on informal conversation the way standards and formalisms have in traditional engineering disciplines.
Those software development improvements have to support informal conversation. That's why the agile approaches have been successful... when they have improved communication for a specific team, they have improved the results without any new technology or formalisms. Of course some of that communication is in the form of "knowledge transfer" of how to use the available formal tools better. But in the aggregate it is *all* sorts of communication among the whole team that has made agile approaches successful. And when they have not been successful, in my experience it is not from failing to use a formalism well, it is failure to communicate well.
5 comments:
Interesting post. The more I think about this topic the more I wonder what the difference between a craftsman and an engineer is? What is it that "engineers" do that we are envious of?
I'm not sure other disciplines have any more of less formality around them other than what level a group decides. A TV design team could easily be organized in an informal "agile" fashion.
Engineering is a matter of scope and scale. I don't think the software that runs a satellite or one that powers weaponry would be written any less formally than the effort involved with engineering a bridge. Even at these lofty levels, there are elements of craft at the design level, one which comes from experience, and not one that comes from formal learning.
Conventional software is a craft in the sense that work on a software is never finished. Hence, it takes continual craftmanship to keep the work maintainable and malleable enough to change in requirements.
Software is definitely not a factory.
Software can be set up to be like engineering... but that doesn't do justice to many people out there. I can build an application that meets 100% of the user requirements. But to be perfectly honest, it would probably look like crap. In engineering you have limited options, in many cases, as to how to do something. There are discrete problems that require discrete solutions.
Software development, on the other hand, should be part engineering (we developers need the organization and structure that goes along with it) and part architect (the creativity to apply a different perspective on the solution). In my mind a good architect is a good craftsman. As should be a good software developer.
Interesting discussion, I would say software development is a mixture of disciplined, logical, and artistic skills. Here is a webpage with more discussion on the topic Software engineering myths
Post a Comment