In the Agile Modeling forum, we were discussing:
“With the exception of acknowledged apprentices, do I really want any of my coding done by anyone not good
enough to design? — Paul Oldfield”
I think it is a matter of scale / breadth.
For the full application, i see the entire design and how the pieces of the model fit together.
For the technical architecture, I look at a slice and see the pattern that needs to be followed by all parts.
For very gnarly parts of the application I usually work with the developer to design out a solution, starting with ideas, working with sequence diagrams, then code.
For specific tasks, a “programmer” will do more or less of the design themselves:
– as they are skilled/experienced
– as the task complexity demands
The only tasks that developers might do that require no design is when they follow the cookie cutter patterns established in the technical architecture patterns. For example, creating a new class that needs to follow the standard design pattern… the table DDL, the DAO, maybe a Data Gateway, a Business Object, a Transfer Object, etc. These sorts of repetitious patterns require little design for the “basics.” So the basic “CRUD” is often a pattern, or a framework config file… not much thinking required. (“It’s so easy even a tool can generate the code…” and “Consistency is a quality all to itself” phrases come to mind.)
As the tasks move to more novel elements, like implementing certain methods, or interacting with other classes, the complexity and uniqueness start to surface.
So, i would say that even the simplest development task that is accomplishing something novel in the application requires some level of design.
Agreed the scale and breadth come into it – you’d want better, more experienced designers to lead the more tricky bits; ideally with knowledge transfer so the more junior designers learn what there is to learn here. I agree with you, if there’s no design to be done get a tool to do the work where that would be a saving overall. Yet even there, your programmer needs to make the (design) decision to use the tool.