A discussion came up about vision in the Agile Usability forum.

Like many things in software, it is always hard to discuss “things” without specific examples. The size or scope of the discussion has to match the circumstances. Design and “vision” for a single functin/feature is radically different than the design or vision of a “change the game” product. Timeframe can often be important… are we talking about year-long projects with 20 people? or decade-long projects with 2000 people? at any rate, even the latter can be broken down into small chunks of reasonably-sized sub-projects and shorter deliverables. in other words, in some sense, ideas about the role vision plays are/should be scalable…

do you find product owners have vision that spill beyond the purpose and needs of the system into disciplines like usability? architecture? maintainability? extensibility?

my experience has been one of working closely to collaborate as a partner with product owners or the “customer(s)” to blend their wants and desires into aspects of software design and usability that can then be conveyed to the team as a “vision.” the phrase “two heads are better than one” comes to mind.

setting the vision, conveying it to the team, allowing good ideas from any quarter, at any level in the project, at any time; but also staunchly defending the vision as needed. contradictory? maybe, but not really.

As far as the team and others peripherally involved grokking the vision… yeah, it requires constant repetition. “If I had a nickel for every time…” I write or speak the vision… I say it in scrums often. It is all over the wiki, whether you start from the “project vision/overview” pages, the FAQ pages, or the page titled ” Grokking ” and the subsection: “Grokking in a Flash!” with the quick links of “What”, “How”, and “When.”

The wiki is also a very useful place where i keep discussions, brainstorming, etc. New people come onto the project and may have “a great new idea” — like the other 5 before. So a gentle discussion and a wiki link can direct them to a wealth of corporate memory and explain why we may have considered that “great idea,” but chose a different path instead.

nonetheless, it is no small feat to carry a torch of a vision… requires continuous championing, occasional foot stomping, and lots of repetition, in my humble experience.

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.