Learning from my mitsakes

Fri, 01 Jun 2007 10:36:17 GMT

A wise man learns from the mistakes of others, a fool from his own.

I was feeling in a retrospective mood, so if you're wise you might learn from 5 mistakes of this fool.

Not making time for the architecture

Allocating insufficient time for the architecture makes everyone's life difficult; you tend to interact through minutes and documents rather than meetings and discussion (which usually takes longer overall anyway!). Is this my mistake or perhaps one made by the project manager when allocating resource? I guess if I've not been involved in planning then it's hard to imagine what I could have done about it. Regardless, architecture takes time. I now like to start my bid at the same amount of involvement as the project manager - it should at least kick off a discussion!

Not thoroughly scrutinising the functional requirements

Perhaps caused by not making time for the architecture, I've certainly been guilty of skim-reading the functional requirements. Even when I've fully understood them I've not pushed back on them as much as I could have done. I, and the development team, are not just consumers of the functional specification, we're stakeholders of the application and should try to improve the requirements by adding/trimming/redefining wherever appropriate. Minor changes can make the development much easier without negatively impacting the end user.

Not keeping a repository relating to the system architecture

It seems whenever I'm asked to do a presentation or document on the system architecture, even the existing portions, I end up knocking up something new in Visio. It's not that this information isn't captured somewhere, it's more that I just can't find it. Just a few snapshots of the significant subsystems, components and interactions at various levels of detail is all that's required and would allow everyone else to inspect and update these views easily.

Not letting it slide

Some things just don't matter very much. At least, not at the architectural level. I've certainly argued the toss over numerous issues. Not getting involved would perhaps have been better than intervening and backing down once time or willpower has run out!

Letting it slide

Some things do matter. On occasions I've trusted that the development team know what they're up to; they're coding it, they're testing it, so if things were that bad or started to become risky they'd probably notice it. I've definitely been wrong about that!

Coding the Architecture - mistakes tag

Learning from my mitsakes