englishteeth.co.uk

My latest assignment has involved implementing change requests in existing code on behalf of a service team who are ramping up their Java capability. The role can only really be described as ancillary and I am comfortable with that. Nevertheless, having stumbled across these very entertaining posts on Top 10 Ways To Demotivate Your Programming Team and The Anti-Team, I found myself feeling peculiarly nostalgic about my last permanent position…

In brief, I was the technical lead of a team that grew to around twenty developers and we were forging new ground with an in house Enterprise Service Bus (I know, but this was a few years ago).

The environment was hostile:

• The Architecture team were on the whole, power point architects with no apparent technical grounding. The chief architect openly resented my “technical architect” job title, my solution design and my odd habit of implementing things.
• The customers did not want the system. The manual way they did things worked for them and had done for years, but management wanted the control, monitoring and automation benefits.
• The Business Analysts were entrenched in their particular customer’s camps and did not have a unified view of the product. They weren’t going to get it from the assigned Solution Architect (part of the above team), who was more concerned with change control boards and compliance and didn’t have a clear understanding of the product either. There were no systems analysts.

Ultimately, all of this (and a book’s worth more) contributed to my leaving, but I do think I am missing what Robert M. Pirsig describes in Lila as Dynamic Change. At the moment what I am doing has value and quality, but it is static. I am craving the architecture and design aspect that provides that other dimension, even to the point that I am nostalgic of a time of conflict.