Becoming more architecturally aware - part 2
It's important to understand the architecture behind the technology
Last time I talked about how we need to understand how application frameworks are designed and work behind the scenes in order to produce code that is consistent and compliant with the overall architectural principles. The second aspect that we need to become architecturally aware about is the underlying technology.
Again, let's put this in context of my current .NET project. I have much more Java experience than .NET experience; I've written some C# and I've played with Silverlight, but ASP.NET is new to me. Thankfully, the concepts behind ASP.NET translate fairly directly with those behind JSP, so it's not as if I'm tackling this from a standing start. Having said that, I've felt that it's really important to get to grips with the underlying architecture of the technology so I can be sure that the code I write, again, integrates properly into the overall architecture. An example here would be the ASP.NET page life cycle. Like JSP, ASP.NET pages have a series of things that happen to them when a request is made, which includes creation of the request/response objects, page compilation, page instantiation, calling page event handlers and so on.
Knowing the finer details of a programming language is one thing, although using or not using new language features such as generics isn't necessarily going to negatively affect the architectural integrity of the solution. Not understanding something like the page life cycle of ASP.NET could. For example, it's important to understand the page life cycle so that you understand when objects can be shared/cached. Session management is another important thing to understand, and blindly throwing objects into the user's session can have architectural implications if your application needs to scale horizontally and you need to implement transparent session failover using session replication.
Being more architecturally aware doesn't necessarily mean that you need to understand the entirety of the bigger picture, but you should understand how to write code that is architecturally compliant. And that means understanding more about how the underlying technologies work.
Re: Becoming more architecturally aware - part 2
Unfortunately we tend to become aware through negative experiences: scalability or failover issues in your example. Code reviews will help pick these things up but only if review hasn't been entirely delegated from those that architecturally aware.
A more comprehensive testing strategy (ie, more than unit testing!) can also show where awareness is needed by bringing these negative experiences into a portion of the development lifecycle where education and experimentation can be encouraged.
Re: Becoming more architecturally aware - part 2
There's something more to all of this though. Some project teams don't understand that they can be more effective by being more architecturally aware. We learn by negative experiences or from external influence/advice, but some teams don't seem to have either!
