Recently where I work we have been interviewing candidates for developer roles in our team. I have been involved in conducting some of these interviews and this has been causing me to reflect on other interviews I have been involved in, both as candidate and interviewer.
Most of the candidates that I have seen, both recently and over the years, have been fairly strong when it came to their knowledge of C#, SQL, and the .NET Framework. Where typically they fall down is in their understanding of the ways in which these tools can be used to create quality software.
An analogy that has been rolling around in my mind is that of the developer as a builder (I'm sure it's not original to me). Now I'm not a builder (as my g/f would happily attest I'm not even much good at DIY) but it strike me that a good builder has certain key areas of expertise.
A good builder will know the materials that are key to their trade. She will understand the differences between materials, such as between different types of wood, or cement, girders etc...
But there are another set of skills that are important for a builder to possess before you would want them to work for you. Beyond this knowledge of materials a good builder will also know the techniques required to build things from these materials that are fit for purpose.
To build a wall it's not enough to know about bricks and cement, its' important to also know at least some of the types of bond, that's to say the commonly accepted strategies for building the wall.
Of course, what I'm saying and the parallel is not new. The GoF design patterns were inspired by the work of Alexander in the field of architecture (not software). But it is, at least to my mind, a useful analogy. You wouldn't want a joiner (carpenter) that didn't know about types of joints, so why would you employ and trust a developer that didn't know (and couldn't discuss to some degree) some of the common design patterns, or fundamentals of object oriented development.
Posts
2 comments:
I agree that too many developers do not now enough about the fundamentals of design patterns and software architecture and IMO it is this understanding that separates good developers from great developers. However, I don't like the builder/architect analagy because to me it is a bit of an over simplification of the problem, when you are building a brick wall there is relatively small number of ways to do it. Building a software application on the other hand is a completely different beast and should not be analgious to building a house, I believe it is about time software development became its own entity and we understand that the reason there are so many software developers without basic OO skills and knowledge of design patterns is due to the way that the majority of developers learn their trade which is by being self taught, reading books etc but rather than seeing design patterns and architecture as the starting point it is much more fun to just start coding and bumble through until eventually some kind of appication is born.
I don't disagree with you Rich, every analogy has its limits, beyond which it can hinder rather than help, and software development is littered with examples of this.
That said, to defend the analogy a little, a wall, house, etc, is only one type of thing that a builder will work on. It is only one type of object if you like, it may be a composite object (like a house, which is very complex, or a simpler object like a wall. Even the wall is constructed from other artefacts such as bricks, cement, etc. Such things to me are like the framework we work with in .Net.
Beyond this I think that there are useful parallels to be found, not just in the examples above, but also in the requirement for a degree of 'artisanship' or craft. Something that David West expounds the need for recognition of in Object Thinking.
Software development should be seen as its' own beast, but it cannot, and shouldn't, be a hermetically sealed beast that does not look beyond its' own borders for inspiration. Beyond the patterns movement (inspired as it is by the world of architecture) other important developments in software development owe much to understanding the similarities with the 'outside world' such as the adoption of Lean Manufacturing principals by the agile movement, or componentised development from the the world of manufacturing (complete with its' factories, components, etc...).
That said parallels are only useful when they serve to inform an argument, not when they become the argument itself. The battle as I see it is to see the parallels but also to understand their limitations. That way when deployed they can enrich understanding and discussion without leading to false conclusions.
Post a Comment