Development and Design Concepts (How to get to Predictable Development)
Today I stumbled upon an old post by Alan Cooper located here: http://www.cooper.com/journal/2007/10/design_engineering_the_next_st.html
(Thanks to another blog post on SpittingCAML for bringing my attention to it.)
I want to ask you all a question based on the article and Development/Design Concepts that are debated out there, but before I ask the question I need to give some background:
The article is extremely well articulated and while I am not a fan of necessarily grouping people as one collection or another it does a good job of illustrating some of the deep set challenges of our current Development Practices (I speak of a wide generalization based on what I have seen in organizations I have worked with). The issue described in the article particularly is that of unpredictable development.
The issue Alan illustrates here of unpredictable development clearly describes that the approach to solving them is by better understanding individual programmer objectives or goals and mapping that in a way to the processes we use to create the end solution.
He creates two classifications, builders and designers and explains each. For the sake of brevity I will just quote the illustration here:
The first camp is composed of builders: those programmers who, like the many carpenters and masons who preceded them in history, take a sublime joy in seeing their handiwork take form in the real world where it can be—and is—used and appreciated by others. They may be hammering together packing crates or they may be painstakingly crafting Steinway pianos, but seeing their products of wood and steel assume a tangible form that gets things done in the wider world provides them with a sense of accomplishment and well-being. It achieves their goals.
The second camp is composed of designers: those programmers who, like the many visionaries who preceded them in history, take a sublime joy in seeing complex, apparently intractable problems dissolve in the face of their creative thinking. They may be arranging utensils in their kitchen drawers or they may be painstakingly calculating how to shape a girder to support a mile-long highway bridge, but seeing that the solution they imagine is the best and most efficient one possible provides them with a sense of accomplishment and well-being. It achieves their goals.
Of course, the builders share in the joy of devising clever solutions just as the designers revel in seeing their creations take real form, but if a mutually exclusive choice between the two options ever arises, each will be happy to focus on the type of work that best satisfies his goals.
What I think is important here (and I am trying to be objective) is that the article outlines a simple yet effective way to help improve development processes. The method outlined: By creating designers and builders with appropriate roles and responsibilities that run in line with their personal goals and objectives; the development work and end result will be far more predictable and of higher quality. This quality can be measured as reduced cost, higher morale, and so on.
You can read hundreds of books and articles, and of course this is a heated debate topic, but for me personally I believe that the only way a development process and methodology will be effective is if it works for the actual developers you have on staff.
As an individual developer it is extremely important to know and understand your fellow developers. It is even more important for anyone structuring development practices or managing developers to understand the developers they manage. Knowing their personal goals, interests, and objectives will allow you to assign them with the work that is most suited to their personality and style.
Realistically the ‘builder’ and ‘designer’ is an extremely oversimplified description, but it has value in that it is a separation of developer types under more than one classification. This way there is a greater chance of them getting the kind of work they want.
Let’s think about that for a moment:
- What happens if a developer falls under both types? Or seems caught in the middle?
- Or if (as is the case in many small development groups) the developer must constantly change roles to deal with the increased demand?
- Then even comes the more challenging aspect of:
Who makes the judgment for which group they belong under?
The manager? The developer? Co-workers? A objective and neutral testing process?
It becomes a spiral of questions that quickly pulls attention away from the important and easily understood concept that the individual’s goals and personality (regardless of what they do whether it be development, design, consulting, analysis, etc) should have an impact on the work assigned to them and that the only way we can try and assign work is by using classifications.
We use classifications for everything. From our professions (Analyst, Designer, Developer, Manager, etc) to often our personalities themselves (Introvert, Extrovert). These all provide value if they are used correctly.
The great article Alan wrote depicts two interesting classifications of developers which separates them by their goals and interests (or personality).
Hold on a second, I said earlier I am not a fan of grouping people or classifying them, and yet I just described how it is effective? It is effective and works in many situations however these can never be static, and will and MUST change based on hundreds of influencing factors.
You will no doubt need to break each classification down further, or adjust them to match the kinds of developers you have, or adjust them to better suit the kind of architecture and design work necessary for successful projects based on the technology you use. All these reasons and more such as cost, organization style, your own management style, etc will influence how you structure it. In some cases for extremely small development groups it won’t make sense to even have classifications.
So in summary (I know I rambled a bit, apologies) Alan’s article is really fascinating and good because it shows that many other people understand that the personality of developers influences the development process and development design concepts. He also (based on his own situation and experience) suggests two classifications that work for managing and working with his developers.
So the question I give to you is:
What classifications would you use?
The same ones? Or different ones? If they are different why are they different? What is your situation like?
Have fun thinking about it, or applying some of the concepts Alan describes,