Back Room Front Room 2

Third, this approach leads to a sound architecture.
If the organizational structure grows according
to a pattern language that draws on the key structures
of the business domain, then the architecture
will in turn reflect those key structures. That’s what
architecture is supposed to do—serve the business.
We must continually remind ourselves that it should
do so not for its own sake, but for the sake of the
relationships between the people who inhabit it.
6 KEY PATTERNS OF
SOFTWARE DEVELOPMENT
The key patterns of software development
organizations have come together in several key
collections, many of which were mentioned in
Section 4 above. Many of those patterns have been
woven together into a single pattern language of
about 100 patterns for software development
(Coplien Harrison 2004). Here are some of the key
patterns from that pattern language.
6.1 Engage Customers
If you want to manage an
incremental process that
accommodates customer
input, and if you want the
customer to feel loved,
Then: Engage customers
after Quality Assurance and
project management are
prepared to serve them.
Most of “engaging customers”
means listening to
them more than it means asking them questions or
reviewing Use Cases or UML diagrams with them.
Use Cases may have a place in dialogue with the
customer but are secondary to the practice of
listening. You can observe a lot, just by watching.
And it should be a cold day in Hell before a
customer sees a UML diagram. Customer
engagement means making a customer feel cared
for, and that as much means spending time with
them as it does fixing their bugs and addressing their
requirements.
6.2 Work Flows Inward
If you want
information to flow
to the producing
roles in an organization,
Then: put
ORGANIZATIONAL PATTERNS
the developer at the center and see that information
flows toward the center, not from the center. If you
always feed developers with the resources and
information they need and if you allow them to
control the process (DEVELOPER CONTROLS PROCESS
is another one of our patterns) then the organization
will be working its hardest to deliver the artifact that
matters most: the software to be delivered to the
customer. The alternative is to channel resources to
management. But most managers do not directly
produce anything delivered to the customer.
6.3 Architect Controls Product
If a project has a long
life, Then: use the
architect to carry the
vision forward and
serve as the long-term
keeper of
architectural style.
The goal is to keep
the conceptual integrity
high for the project. The Architect doesn’t
dictate APIs or code but embodies the principles and
styles that are key to success in this line of business.
6.4 Developer Controls Process
If you need to orchestrate the
activities of a given location
or feature, Then: put the
Developer role in control of
the succession of activities.
The Developer role is the one
who builds things that your
customer pays for; other roles
produce internal plans and
artifacts that the customer
never sees. If the schedule is planned around the
Developer, then the Developer is never blocked and
Developer productivity can be optimized.
6.5 Hallway Chatter
49
If developers tend to
huddle around the
organizational core
or supporting roles
are inadequately
engaged with each
other, Then:
rearrange responsibilities
in a way that encourages less isolation and