The developer is central to all activities of this end-to-end software development process.
Context:
Forces:
Totalitarian control is viewed by most development teams as a draconian measure.
The right information must flow through the right roles.
You need to support information flow across analysis, design, and implementation.
Managers have some accountability.
Developers should have ultimate accountability, and have the authority and control of the product; these are often process issues.
Solution:
Place the Developer role at a hub of the process for a given feature. A feature is a unit of system functionality (implemented largely in software) that can be separately marketed, and for which customers are willing to pay. The Developer is the process information clearinghouse. Responsibilities of Developers include understanding requirements, reviewing the solution structure and algorithm with peers, building the implementation, and unit testing.
Note that other hubs may exist as well.
The Developer can be moved toward the center of the process using patterns Work Flows Inward, and Move Responsibilities.
Though Developer should be a key role, care must be taken not to overburden it. This pattern should be balanced with Mercenary Analyst, Firewalls, Gatekeeper, and more general load-balancing patterns like Buffalo Mountain.
Design Rationale:
We have no role called Designer because design is really the whole task. Managers fill a supporting role; empirically, they are rarely seen to control a process except during crises. While the Developer controls the process, the Architect controls the product. (In the figure, the Architect role is split across Framework Owner and Architecture Team.) This communication is particularly important in domains that are not well understood, so that iteration can take place to explore the domain with the customer.
Next: Patron