#1 Gain the respect of the developers
I would like to generalize and say that developers seem to be the type of people who don’t want to put up with more bullshit than they absolutely have to. So trying the typical political maneuvering that you find in big companies to impress developers wont work. That includes salesmanship, power point presentations, etc. Those skills can be important for relaying a direction or vision, but it’s not going to impress the developers. The most tried and true way to gain their respect is to code with them. Yes, indeed. Good architects code. Bad ones pontificate. And there seem to be *way* more of the latter than the former. Coding your brilliantly “architected” solution will help gain their respect. But it also helps in another area. The second rule I follow.
#2 Realize that you cannot design a system on paper.
The source code is not the product that you’re engineering. The source code itself is the design. So when I sit in an architecture role, I remind myself that coming up with diagrams and flow visualizations is not the design. It’s a brainstorm to help develop a model in my head. But without putting that model to code, you don’t know how it will truly behave, or how the architected solution should be altered. And believe me. In almost all cases, it should be altered. In other words, there should be a feedback loop between the developers and the architects. And if you follow rule #1, you’ll be right there to observe first hand how your solution plays out in code.
#3 Don’t resume build
Don’t glom onto the latest and most shiny technology and push it onto the developers without putting it through some rigorous, real-life situations. Playing with new technology is fun. I do it all the time. But I do it outside of my day job. Sacrificing the stability of the team, the software, and the business model just because some technology seems cool and Google might hire you if you know it is not a respectable way to go about solving enterprise problems. Even if you’ve seen enough sales presentations about how this new technology is going to be such a magic bullet, resist the temptation to try to indoctrinate the rest of the team until you’ve put the new technology to real life software problems in an incubator.
I’ve been on both sides of the fence, have worked with a bunch of good developers and architects, and these are my three rules. Anyone want to add anything?
Reference: Being a better enterprise architect from our JCG partner Christian Posta at the Christian Posta Software blog.
Your article is quite accurate. Nevertheless, it’s a whole art when it comes to using new technology for the benefit of the team and projects. Nowadays, Software architects are asked to be more creative and to anticipate competition. Respecting the standards and ensuring long term stability is the core of enterprise software activity, yet don’t you believe these same developers are worth the challenge of incorporating new technology without sacrificing the stability. In companies, this might be easier to achieve through dedicated cells, but in small boxes like statups, things might get ugly if the architect forces its way to… Read more »
Great article, by the way. #3 is a bit more complex than it appears. Although playing with newest technology for the sake of it is a dangerous thing; the flip side is also true. Forgetting to upgrade and letting things age just because they work is perhaps far more dangerous. I would consider #3 as a split rule; Do not upgrade your resume – instead upgrade your technologies. In Java, at least, the technologies move quite fast and often times upgrades are necessary to fix certain bugs; in turn those forced upgrades create ‘classpath’ issues in an non OSGi world.… Read more »
My absolute rule is #1. Practiced it myself and experienced just positive feedback. That way your devs will trust you as they see you’re facing the exact same hard problems they do. In the end we are all devs, aren’t we??
“If you do not talk about, do not sell, do not force developers to use Every Shiny New Technology that you have read about – then you are not an Architect.”
Unfortunately, this is what most ppl believe.
Use as few Technologies as possible to Solve a Problem – And you have my respect.
Simplicity is the sign of excellence.
Complexity of mediocrity.