Learning from my mitsakes

I can't wait to learn from my next ones ;)

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!

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

Re: Learning from my mitsakes

We can definitely learn from each other's mistakes. I'll add at least two that I've been guilty of. Of course, this could become a really long post ;-)

Not ensuring understanding and buy-in among the teams. The architect provides the technical leadership for a project. We wind up in trouble when others responsible for delivery don't sufficiently understand or don't believe in the architecture. It's important the architect take a "seek first to understand" approach with others to make sure they really get it - and support it.

Not gaining support and commitment from the "customer". Architecture invariably requires trade-offs among competing stakeholder needs. The stakeholder's need to understand and support the decisions and have confidence in the direction.

Brian Sondergaard

Re: Learning from my mitsakes

One other thing I usually do is to always consider an alternative approach before settling on a solution. Your first solution might be the better one but then again there may be a better approach.

Re: Learning from my mitsakes


I'm so glad to say that I already knew this even if I know how it should be done I don't always get the opportunity to do it. Worked in differed companies who could not see the true value of proper project initialization.

I've been trying to make them see that it would be better to have a good design up front before doing any code. Mainly because you need this to give an indication about resources needed to make the project work. It is more or less an equation a balance between time given and resources. Not only this affect the equation but also the quality of the the given time or resources. Imagine you need 3 month with 2 descend developers. You get 1.5 months with 4 junior developers. I don't think project will be a success. Simple for the fact that the time given is less an indeed we have more resources but you will need time to educate the juniors. So both are of "bad quality"

Documentation or any technical paper done with in a project should be stored in a conventional way so that other may find it easily and know how to add new them self. This one can go wrong unnoticed very easily.

One thing I don't understand; the choice weather to let something slide or not. I think this actually makes you a good architect. Seeing importance of a certain subject with in a project and defining it as important or none important. In some way I think you are also responsible for taking care over the development team. Therefor you have to use your social skill to be on the same level with your development team constantly. So that when you see that they are going the wrong direction you can put them back on the highway.

Re: Learning from my mitsakes

There are times I've let things slide that I've later regretted and there are times I've regretted not letting some things slide. Knowing which things are "architecturally significant" without the wisdom of hindsight is the trick, especially when time is short.

But then again, some "insignificant" things are great learning opportunities for the team... oh, I just can't make my mind up!

Re: Learning from my mitsakes

I can totally understand this, mostly it means having some experience with in the subject in matter. Project exist out 2 parts.

One which already been done before some type of repetitive work. This will get better in time depending on how much you will do it.

The second part is the hardest one the "unknown factor" It is always this that gives the trouble.

You can minimize the unknown by defining it and researching it better in the design phase. So you have a better feeling about what you up against. This also makes it more easy to help out the development team and making your self comfortable deciding when to slip and when not.

Add a comment Send a TrackBack