Search
Search
Martin R
November 30, 2009

SE Radio 150: Software Craftsmanship with Bob Martin

Recording Venue: Skype
Guest(s): Bob Martin
Host(s): Markus
This episode is a conversation with “Uncle Bob” Bob Martin about agile software development and software craftsmanship specifically. We talk about the history of the term, the reasons for coming up with it some of the practices and the relationship to other agile approaches. We conclude our discussion with an outlook on some of todays new and hyped programming languages.

Show Notes

Links:

Tagged as:
Join the discussion
18 comments

  • Thank you for this episode and the last one as well. I feel that those two two episodes explain important contributions to the search of identity and meaning in our field. The software craftsmanship manifesto in particular is a valuable contribution to the discourse about ethical behaviour of IT professionals. I believe that it is relevant even to those software professionals that don’t believe that craftsmanship is the right metaphor to capture the essence of our profession.

    There are definitely similarities between software developers and craftsmen in other disciplines. However, to my opinion there two major differences between craftsmanship disciplines such as plumbing, woodworking or tailoring on the one hand and the the way software development is seen through the lens of the software craftsmanship metaphor as explained in this podcast.

    First, real craftsman typically have deep experience in a speciality. Building a home for example involves work by a carpenter, a plumber, a roofer, an electrician, a bricklayer, … . And all those masters or journeyman are quick to point out that they would at best perform at the level of an apprentice in another speciality. Software craftsmanship on the other hand seems to see software development as a big whole. I feel we should be more humble and accept that software development is too big to be considered as one craft, but that we should rather look at UI design, domain analysis, code writing, testing or database development as distinct crafts with their own sets of skills and tools and their own path to mastery. Those specialities actually are already there in the world of software development. When working with the „software craftsman“ metaphor we should frame them as different (software) crafts. It would be interesting to work out a set of skills, tools and practices for those crafts in a similar way Bob Martin has done this for code writing in this podcast.

    Second, in other technical disciplines there are not only craftsmen, but also people called engineers. Their learning is based on a heavy dose of college education and learning about the use of scientific methods. When practising their profession, quite often they work as dedicated designer or as technical or managerial leader. Even the process of building a moderate private home is not exclusively a self-organized undertaking by teams of craftsman from different specialities, but there is an architect in charge of translating the owner’s needs to the design of the home and quite often also to coordinate and supervise the work of the various craftsmen. Might be that in the world of software, we need a similar separation of work between software engineers and software craftsmen.

    One last point about our mental capacity to capture the complexity of our field: With all due respect to Jim Coplien and Bob Martin – software architects shall not code. Or do architects in the physical world lay bricks? Architecture is a speciality of its own. In a similar way than architects in the physical world, software architects need to understand the user domain, technical structures, the mapping between those two, the economics of software development and some project management. Even Bob Martin’s twenty hours per week of learning are not enough to stay current in all those architecture topics and continue learning code writing, testing, business analysis, … . For building quality software, we need master architects and not journeyman architects that double as journeyman code writers. There are exceptional individuals that have mastered more than one discipline and are able to stay current in them. But this is nothing we should expect from everybody in the field. Even an individual that is a master code writer and a master architect at the same time shouldn’t architect and code on the same project. This is just too difficult in terms of social interaction since as Tom de Marco and Timothy Lister have pointed out in „Peopleware“: Leaders are not part of the team.

    Regards

    Erich Pawlik

  • An excellent episode – one of the best I’ve heard since becoming a listener. Much of what Bob says here resonates strongly with my own feelings about software development as a craft.

  • Hi Markus,
    I want to say thanks for another very good episode with great guest and host as well:).
    I am also into DSLs and therefore I find questions regarding those topics very interesting, pitty, that you have not pushed it little bit further by explaining that rather than internal DSLs, you work on external ones. It wuld be interesting to hear Uncle Bob’s opinion on that, although he kind of answers it implicitly when mentioning compilers…
    I want to ask, not reagarding this episode, if there is any episode in preparation about BDD. If not, it would be great to have one, especially with Dan North or some of the Cucumber guys.
    Keep the good work:)

  • This post was really great!

    Just one thing to add: Robert mentioned static typed languages kind of obsolete because test-driven-development executes the system and shows problems with typing during test-runs. This is true but in practice the code coverage tends to be low, and even if code-coverage is good it doesn’t tell you that your test-suite is strong (see also http://www.aldana-online.de/2008/03/18/ensure-test-suite-quality-and-beware-of-the-green-bar/).

    In my view overlooked aspects of static typed languages:
    -Static typing information in source-code can increase documentation and comprehension (of course also the opposite can happen, if code is cluttered with too much typing information, type inference could help here).
    -Typing information inside source code can lead to better code-browsing facilities (click+jump to referred class, method etc.).
    -Safer refactorings (move, rename etc.), which I think is the strongest point.

    Not that I am biased (e.g. I love groovy and favor it for many tasks over Java), but static typed languages have a big plus when it comes to maintainability of big systems.

    Apart from this little detail, fantastic (and one of the best ones I have ever heard) se-radio talks.

    —
    homepage: http://www.aldana-online.de

  • Craftsmanship is a fruitful metaphor for software development. In particular, I like Uncle Bob’s message that the way to improve software quality is for developers to take responsibility and stop blaming project managers for tight deadlines, clients for changing requirements etc. If we’re not advocates for code quality, who will be?

    As an aside, is there a PayPal link for those of us who do not speak German but would still like to support SE radio?

  • The episode was very interesting to listen to. The comments also raised the interesting question, how much an architect really should be able to code. From the broad responsibility he has, he will only be able to code very little in real projects. But he must be up-to date with current technology, as he has to be the one which lays out the architecture (with some technical details) and be a good coach to the developers. In order to be able to do this, he must have a longtime coding experience.
    This is only somehow comparable to building architecture. There, architects know the principles of how the work has to be carried out, but did never work long time in a specific craft. But in comparison we really should consider this analogy and judge what we would think about an architect which would raise up one of the rooms in the building he is about to put up.

    Ekkehard Janas

  • Bob Martin praised the book Structure and Interpretation of Computer Programs by Abelson, Sussman and Sussman.

    Then in response Marcus praised another book, which he thought sounded similar.

    What was the name and authors of the book Marcus praised?

    Mal

  • Brief summary of this excellent podcast
    —————————————

    A person wanting to become a good craftsman should first learn these tools

    1) IDE – Spend a bit of time understanding the IDE that you work in. If you don’t use an IDE, start using one!

    2) Version Control – A developer should understand this aspect well. Great free version control systems are cvs, svn and notably Git.

    3) Bug tracking – Start using a bug tracker, preferrably a lightweight one, and with a web interface. Bugzilla (?)

    4) Unit Testing – Start using Unit Testing on your source code. cppUnit, NUnit, phpUnit are good examples for the specific language.

    5) Acceptance Testing tool – This will help ensure that the features that have been “frozen” in the requirements document actually are what are expected by the costumer. Fitnesse, Green pepper are good examples of this.

    6) Learn Lisp !

    7) Make sure that you spend time (not work time, your personal time) in understanding more of your field. Learn new languages. Study more about the evolution of language paradigms etc. Hone your skills and tools.

    8) Keep learning!

    Books referred to during this podcast
    —————————————

    1) Software Craftsmanship: The New Imperative by Pete McBreen
    2) Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin
    3) Structure and Interpretation of Computer Programs – Harold Abelson, Gerald Jay Sussman, Julie Sussman
    4) Concepts, techniques, and models of computer programming by Peter Van Roy and Seif Haridi

  • Thank you for this episode! It totally motivated me to try to do my best. I would say that some episodes of se-radio are just making my life better in general. Great job!

More from this show

Menu

Recent posts