First Experiences...

...all over again.

I used to be a lead developer who had to make most of the design decisions, be responsible for requirements, quality, etc. - a kind of de facto architect. I suspect this is typical for many lead developers as they meet the need for architecture without an architect. So in a way I was an "architect". But now I'm actually an architect I find that what I used to do was really only the tip of the iceberg and my "style" has changed notably.

As a lead developer responsible for the architecture I would naturally design systems that played to the strengths of the development team. As a result, the code would be high-quality but the technology selection not necessarily best-of-breed. It was easy to stagnate even while continuing to deliver successful projects as the design decisions were driven by what the team was proven to be successful at delivering. Technical authority stemmed from you and your team's ability to develop high-quality, functioning code in more or less the same way time and again.

As an architect it would appear that relying on your own existing capabilities is not sufficient. Indeed, it's probably a sign that you've missed something - how can you be an authority in a field as diverse and volatile as software development without having learned something new recently? Part of the role would appear to be to embrace the unfamiliar and make it accessible to those tasked with delivery. Technical authority may therefore come from research and intuition as much as experience.

Contrary to my expectations, I've found that being separated from the development team has made me more tolerant of their mistakes, despite being less able to address these mistakes directly. This I attribute, in part, to being better able to see the value of less costly development. Of course, this is not to say that code quality, mentoring and review aren't still very important! However, I find that I'm less exacting and more pragmatic - if I were to press for the quality that I'd deliver myself (as a lead developer) then I'd be negating some of the cost benefits of having got someone else to do it in the first place! As a lead developer I knew when things weren't up to scratch and I'd do something about it; as an architect I have the context and obligation to determine when things are "good enough" and be confident not doing anything about it. Sure, it's frustrating not being able to roll your sleeves up and show everybody how it should be done ;) but there's also satisfaction to be taken from making a call on whether something's fit for purpose.

It's been my experience that the formal role of architect is considerably broader, deeper and less familiar than I anticipated from my experiences "architecting" as a lead developer but I'm finding new abilities taking on these unexpected challenges.

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: First Experiences...

Many in the software industry derive their job satisfaction from delivering very high quality products on time. It sounds like, now you've been detached from the development team and cannot "show them how it's done" you are prepared to make quality sacrifices so that you can deliver something on time. In order to justify this drop in software quality to yourself you label it "pragmatism".

Over time, as your standards continue to drop are you not concerned that you will become the kind of software producer (for want of a better word) that the lead-developer in you dislikes due to the poor quality standards they have? Is this not the start of the road to the end of job satisfaction?

Re: First Experiences...

Thanks for your reply and interest in my well-being! I would like to stress that this is based on my first experiences and most definitely not intended as some sort of recipe for how to do things. Hell - it's not even how I'd like to do things!

At the risk of turning this into a cathartic thread about individual's values, the point I was trying to make is that my own values have to be tempered by those applicable to the project, at least with respect to the things I valued highest as a lead developer (i.e., the team and the code). The implication is not that the software is now "low quality" but that it is now "good enough" - a metric (albeit a vague one) that needs to take into consideration the likelihood and cost of future decay. There is also no reason to believe that quality will drop over time; it will continue to be "good enough" although naturally subject to decay.

You're absolutely right that this pains the developer in me as I'm used to delivering the best of both worlds; high quality and on time. To ignore the cost of this type of approach to the client would be a bit irresponsible, though! There are cheaper ways to develop which may or may not be perfectly alright for the task. Perhaps you're right - "pragmatic" is far too lenient a word; "responsible" and "objective" might be better.

When constrained by such inconveniences as cost, the choice may well be between something good enough on time and something great later. Personally I'd definitely opt for the latter! But then I'm not the one who might lose first-mover advantage if the software's delivered later.

As for job satisfaction, there's less in some areas and more in others. Whether I'll like this new balance as much as cutting code I think only time will tell.

Re: First Experiences...

I don't agree with some of the things in your previous blog posts, but this post is probably the best explanation of the differences between an architect and a lead developer I've ever read.
Thanks!

Re: First Experiences...

Mariano, please do feel that you can leave comments on the posts that you disagree about because I'd certainly be interested in your thoughts. One thing is for certain, we don't have all of the answers and we'd welcome your input.

Quality

Kevin posted a great entry about his first architect experiences and it's inspired me to write a follow up about quality.

Add a comment Send a TrackBack