I've just spent a day helping out on a project I had some involvement with last year. For some reason it apparently puts people's minds at ease when an old face gets involved (actually, my face isn't that old - perhaps I mean't "a familiar face"?)
Despite my prior involvement I can't claim to have particularly in-depth knowledge of the systems being worked with. I'm certainly not familiar with the requirements that were being discussed. I wasn't really even there to solve a specific problem. My helping-out wasn't a formal arrangement - I was there, unaccountable and for one day only.
I don't reckon there's a lot of architecture you can get done in a day. However, you can do a lot for the architecture in that day. By asking a few simple, common sense questions you can drive out what's missing, the reason that a project might be languishing:
- "What methodology are you following?" Although a one- or two-word answer might result you're really asking them to prove it. "Can I see the backlog?" "Have you signed off the architecture document?" Most methodologies rely on commitment and accountability so if the team isn't clear on the approach they're unlikely to know what they're responsible for or who's relying on it.
- "What problem does this design solve?" Ok, as an outsider to a project I've got to get some context, but I'm surprised how many times a solution is given as a requirement. This often indicates that a technical solution has been conceived by those undertaking the analysis - the potential for standardisation, reuse and, worse, understanding is severely diminished. Furthermore, if you don't know what the problem is, you've very little right to be confident in your solution.
- "Why did you choose this solution?" Problems usually have a corresponding space of solutions, not just a single one. Understanding why a solution was reached is another step in having confidence in it. You also start to learn how reversible the decision is or how flexible the solution is and thus how much effort you might want to spend refining it.
- "Can you do this?" There are numerous reasons things can't be done, particularly time, money and skills. It can be instructive to find out if the technical skills exist and, more importantly, responsibility for them seems to stick to someone in the team. Remember, the system/application needs to be built!
That's probably more than a day's worth of discussion in those few questions (indeed, it turned out to be a long day!). Whether it makes any long-term difference to the project is ultimately up to the project team.
About the author
Kevin has been working with Java for 10 years, in defence research through dot com to investment banking. Currently he works at JPMorgan
developing front-office trading solutions.
While getting on well with server-side Java, Kevin's also a keen Swing developer (and possibly masochist).
E-mail : kevin.seal at codingthearchitecture.com