Blah.Blah.Blog

So I was somewhat nonplussed when I re-discovered how class-ist some (usually) large financial companies are when it comes to organizing their development capacity. On my most recent engagement with such a firm, my collegue and I soon discovered a fairly rigid demarkation of duties amongst the resident development teams. Note: Although these seemingly draconian conditions are probably rife amongst this type of company, I've highlighted them here lest others have been similarly cocooned against the harsh reality of corporate development shops.

In short, the pecking order is as follows:

1. Solution Architects produce copious amounts of documentation describing the system from this angle and that, which is then handed off to...
2. High Level Designers, who take said documentation and generate more volumes of documentation on the system from a whole new set of lower-level perspectives, which is used as input by the...
3. Low Level Designers, who then produce even larger wads of class diagram-like stuff as fodder for the...
4. Developers, who translate said diagrams into code.

Some key points to note in the above hierarchy:

• Neither the Architects nor the Designers sully their hands with coding, thereby removing the best chance for concrete validation of their wares. This may/may not be a good thing :-)
• There is little/no official opportunity for the Developers to exercise any real creativity in their work; their only hope is to one day ascend to the exalted level of Designer, whereupon they are granted a license to create within the parameters of the architecture. As to whether the reality of development is in accordance with this doctine - I have no idea.

Now I, pragmatist that I am, have always believed that at the very least the core development practices of Agile/XP will make a team function much better, irrespective of whether the project itself dances to the Agile beat. In other words, in the face of unwavering resistance to the introduction of Agile mechanisms to plan and track a project, I can always get the code quality improved via the introduction of refactoring, test-driven development, pair programming etc, etc. However, implicit in this statement is the development team having the leverage to effectively use these tools, which usually requires enough empowerment to alter the design of the solution to accommodate changing requirements. In the types of environment detailed above, this sort of empowerment is not given to anyone doing the actual coding, rather it's seen as a privilege to bestow upon those lofty individuals who have moved beyond the lowly rank of Developer. This situation makes even a developer-centric introduction of Agile difficult at best, as the changes required to give the development team sufficient autonomy to use the practices appropriately must be mandated by the very people who have placed so little trust in the developers in the first place!