The Computer Scientist as Toolsmith - Fred Brooks
I’ve come across a couple of posts recently talking about the gender specificness of the term 'Software Craftsman' and Victoria suggests that the term 'Codesmith' would be a more appropriate name to use.
I’m not that bothered what the name is but I was reading the transcript of Fred Brooks' acceptance speech for winning the ACM Allen Newell Award in 1994 titled 'The Computer Scientist as Toolsmith' which has some interesting ideas about what our role should be.
These were some of the parts that I found interesting in the talk:
-
I quite liked the following quote and it seems to cover the same type of ground that we try to cover with the agile approach to software development with respect to writing software that actually provides value to our users:
If we perceive our role aright, we then see more clearly the proper criterion for success: a toolmaker succeeds as, and only as, the users of his tool succeed with his aid.
The article goes on to say the following:
...we tend to forget our users and their real problems, climbing into our ivory towers to dissect tractable abstractions of these problems , abstractions that may have left behind the essence of the real problem.
I also came across an interesting blog post by Rob Bowley where he discusses some of the limitations he’s noticed in the agile approach with respect to addressing the needs of our customers which seems to cover similar ground.
-
He also makes some interesting points around interdisciplinary collaboration:
There are real costs associated with any professional collaboration, and interdisciplinary collaborations have some unique costs. I find that our teams spend about a quarter of our professional effort on routine work that supports our collaborators
I’m not sure whether that last statistic stands true for collaboration between software development teams and the business but a fairly common objection from the business is that they don’t have the time to interact with the software guys and that we should just get on build what they want. Rob’s post seems to suggest that we’re not collaborating in a particularly effective way and Brooks goes on to suggest that we need to do some preparation before interacting with these guys:
Our Ph.D. students often take introductory courses in the using disciplines, and they always take reading courses from our collaborators to prepare them for their dissertation work. One need not become an expert in the partner’s field, of course, but one does need to learn the basic principles, the vocabulary, and the partner’s research objectives.
I wonder if this is where we sometimes go wrong - we’re focused on the software solution rather than stepping back and working out our customers' real problems and helping them solve those. This part of the article also reminded me of comments made by Eric Evans in his QCon talk about not wasting domain experts time.
-
In one part of the article Brooks talks about artificial intelligence, suggesting:
...intelligence amplifying systems can, at any given level of available systems technology, beat AI systems. That is, a machine and a mind can beat a mind-imitating machine working by itself
This seems quite similar to an idea that I read in Taaichi Ohno’s Workplace Management whereby we look to automate processes but not just for the sake of automation. We should automate so that the human can do their job more effectively. On the projects I’ve worked on we often make use of automation to provide us with code metrics but a human would then analyse those and work out whether we need to make any changes to the way that we do things based on those metrics. Google seem to be going with an even more automated approach with respect to understanding which tests are useful as Marcus Striebeck described in a talk at XP Day and since it seems to be working well for them, perhaps we haven’t yet worked out where the usefulness of a machine ends and a human is required.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.