This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I do agree that the developer has to understand the Architecture on which his development is going to function on. But, at what stage of the Architecture Design do you think the developer or developers need to get involved? So that they have an understanding of the decisions that were taken.
In an ideal world, all of the developers on a team would be involved in the initial architecture stages of a software system. In the real world though, this doesn't necessarily work for a number of reasons including levels of experience within the team, ego and various other motivating factors (e.g. some developers don't want to get involved, and we shouldn't force them). I talk about a "relay sport" style of architecture in my book (https://leanpub.com/software-architecture-for-developers/read#relay-sport) where solution architects create the architectural vision and then simply hand it over to the rest of the team, like a baton in a relay race. Often, these solution architects have very little subsequent interaction with the team, effectively leaving the poor team members to implement the vision on their own. This is bad. My recommendation is to avoid this wherever possible, and either get the architect coding (or at least being a part of the ongoing team) or getting one or more of the developers to assist with the architecture stuff. Many teams talk about pair programming, so why not pair architecting?
To pick up your other point about decisions, I truly believe that every developer should understand the architecture decisions being made, and this includes the rationale behind them. For example, if you're using a particular pattern or technology on your project, understanding *why* can help considerably, helping to create a much more collaborative environment.
Padmarag Lokhande wrote:Nice points. It'd be really nice if all developers are involved to some extent.
I agree. We always hear about how we should strive for "self-organising teams" of experienced developers, yet people rarely seem to highlight that an understanding of software architecture is essential to making this happen.