Coding the Architecture - kseal

The Four Stages of Learning

Tue, 25 Mar 2008 10:07:57 GMT

I've found many parallels with the four stages of learning in software development, from how a developer's approach to design changes to how agile teams eventually become self-organising (eg, Scrum's "readiness levels"). By understanding where someone is on their path to becoming truly good at something you can be more effective in mentoring them to the next level - rather than assuming you can fast-track them right to the top.

Common sense...

Mon, 28 Jan 2008 11:21:00 GMT

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.

Who's paying for this?

Fri, 07 Dec 2007 10:43:53 GMT

I like working with users as they often give really good feedback. They're the ones who have to live with the software every day so tend to be very clear about how it helps/hinders their work.

Is it naive to think that making users happy by meeting their requirements is the primary goal of a software delivery, though? In my experience, which is not in COTS software development, the end users are not paying for the software - their boss is. Yet we often grant users great import, perhaps because their feedback is more immediate and tangible. Granted, it is unlikely that giving users unusable software is going to prove successful. Conversely, giving users exactly what they want is also unlikely to be a success. For a start, it could well prove financially prohibitive (eg, technically difficult)!

I consider one of my responsibilities as an architect that of keeping delivery focused on what matters. Sometimes this may mean giving the users what they want, sometimes it may mean telling the users what they're getting (and helping smooth the transition). After all, change isn't always just about transparently replacing the technology.

I'm sure I'm not the only person who's worked on software that has delivered what users wanted but has never seen the light of day. Were the users wrong or were we simply speaking to the wrong people?