This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
When I started out in software development in 1987, my first job was on a database application where the entire development team consisted of a systems analyst, an analyst/programmer, and 2 junior programmers (including me). The system was not especially complex in terms of functionality, and we used the then new-fangled 4GL tools to speed up development, so the project was delivered on time, on budget and to the full satisfaction of the users. At the time I didn't realise just how rare this was, especially in government IT!
Fast forward 20+ years, and I found myself working for a different part of the same government organisation on another database application (yeah, my career is increasingly looking like an ever-decreasing spiral into oblivion). This project involved much larger volumes of data, but in most other respects was not hugely more complex in terms of functionality than my very first project (similar numbers of users, DB entities, screens etc). In my own experience, there is a huge raft of systems that are like this - reasonably complex but not requiring highly engineered enterprise-wide solutions.
But this time we were on a 3 tier Java Enterprise Edition platform, and instead of a team of 4, we had a team of around 40, including 4 "architects" of various kinds: a senior data architect (who was really good and contributed a lot to the project), a junior data architect (who contributed nothing much but did no real damage), a senior system/technical architect (who generated complexity and UML diagrams in prodigious quantities) and a junior architect (who was an experienced and pragmatic individual and mainly tried to neutralise the worst impact of decisions made by the senior architect).
This project was delivered very late and over budget, and the users were downright disgusted with how little functionality was ultimately provided for the vast amounts of time/money that had been thrown at the project, and with the unreliability of many of the unnecessarily complex parts of the system prescribed by our architects.
Now this project was fairly hellish, as was another similar project in the same organisation, which was also infested with "architects" whose main contribution was to spend months in endless arm-waving meetings philosophising and generating UML and documents with acronyms like SAD, BAD, DAD (mad, bad and dangerous to know), but vehemently not "solutionising", while the rest of the team tried to build a workable system around the limitations of the architecture that had been imposed on us.
I'm hoping my experience is far from typical, but I have to ask whether the rise of the "architect" in recent years, especially in Java-land (I see fewer jobs advertised for .NET architects, for example), is a symptom of the complexity of the technologies involved, an attempt to "cure" that complexity, or whether it is in fact the cause of much of that complexity? It sometimes seems like what Rod Johnson called the "complexity industry" is increasingly self-sustaining.
I genuinely have no idea what the "architects" are really bringing to the table that was not possible under the old regime, so maybe one of the "architecture" insiders can comment on this?
Jeanne Boyarsky wrote:I'd like to think the 1987 system was less complex. I'm sure it didn't run in a web browser and have to deal with the related security concerns at a minimum.
Well, yes, although the development tools and frameworks etc are far more sophisticated these days as well, and the systems I've been working on recently were all aimed at relatively small user groups within an organisation.
But really that stuff ought to be mostly "just plumbing" these days anyway. 3 tier web applications have been pretty much the standard for many years now, and the technologies (should?) have matured by now to the point where it is more of a routine technical matter to wire them together for a new application, rather than a job for 4 "architects" to spend months agonising over as if they had to re-invent the wheel for every project. If we still can't come up with a fairly standard architectural basis for building a relatively straightforward 3 tier application in a controlled environment, then maybe we need to think about a different approach? And if the basic infrastructure is fairly standard, then this should not be a major concern for architects, so what are they contributing instead?
I realise that the projects I've been working on have been in what might generously be termed a "technologically challenged" environment, but many of my colleagues and contemporaries seem to have had similar experiences, so I wonder what we're all missing.
I am sorry to hear you have had such a bad experience.
I believe utilizing processes such as agile development may help with delivering small portions of the project on a regular cadence.
Projects need to be executed by a team with many contributors including project management, coaches, developers, business representatives, ...
There needs to be an opportunity for open and gracious communication within the team to address concerns (possibly in a iteration retro) where a feed back loop can be put in place for areas than need adjustment.
Thank you for the question and good luck on your next project!