Back in May, I wrote about why I thought GWT matters. As promised, I am finally getting around to completing my thoughts on the subject.
In the original post, I talked about how I felt we took a step back when we shifted our development focus more to the web platform and further away from the desktop. We lost some of the richness of the interface for our users and we retreated from advances in programming models in the areas of component and event based programming. It’s only been fairly recently where we finally can have it all (reach/zero deployment with productive programming models).
GWT does provide it all as far as I’m concerned. It has a nice programming model that should feel natural to anyone that has done any desktop based GUI programming in the past. It doesn’t lock you into a particular widget library which makes it a sound investment. It takes care of dealing with the nastiness of writing cross-browser code – because it generates all of this for you.
It makes it easy to write internationalized applications. It makes it easy to provide a working back-button for your users (a rarity for a lot of AJAX applications – hit the back button and you may be taken completely out of the application).
If you really do have to drop-down to JavaScript, there is a mechanism called JSNI which provides this.
However, most of all it is the amount of attention the GWT team has spent on tool support that really gets my vote. The integration with Eclipse makes for a very productive environment.
Of course, there are lots of alternatives in the RIA space. Flash/Flex, Silverlight, and Volta are just a couple of alternatives. Of course, if you are lucky enough to have exceptional JavaScript developers on your team then you may feel comfortable using JavaScript directly (although, I have to say although I like dynamically typed languages, one cannot argue with the ability of statically typed languages to assist you in finding problems earlier in the development cycle - i.e. compile-time vs run-time).
However, GWT seemed to be an ideal fit for my team (no new tools – continue to use Eclipse, no new languages to learn – continue to use Java, and no need to worry about the plethora of browser types and versions).
What are your experiences with GWT or RIA approaches in general? (the good, the bad, the ugly)?
Wednesday, August 27, 2008
Wednesday, August 20, 2008
Balancing “YAGNI” with “avoiding the cul-de-sac”
This is a tough part of the architect’s job because it involves speculation. It would be easier if we had a crystal ball to peer into, but we don’t. All we have to go on is our instinct based on past experiences.
Let’s look at one end of the spectrum – “Avoiding the cul-de-sac”. You may have been burnt in the past due to significant amount of rework required as requirements changed or new requirements surfaced during the middle of a project. The common knee-jerk reaction is to make everything flexible, configurable and adaptable. However, like most engineering endeavors there are always trade-offs to be made. Be careful, you may have ended up with un-necessary complexity (which drives up the cost of the project).
Let’s look at the other end of the spectrum – You Ain’t Gonna Need It. With this approach, you eschew flexibility, configurability and adaptability until a requirement surfaces that demands it. This approach is a gamble, but the agile folks will tell you that this is ok because of continuous refactoring and unit tests.
So what is the architect to do? Well, it depends. You have to look at the sub-systems of the architecture and run through some what-if scenarios. To prioritize, I would focus on the sub-systems that have external dependencies. Wherever you have external dependencies, you have given up control. Anything could happen to the external dependency and you have no control over it. The vendor or organization that owns it could a) go out of business b) change their licensing model c) raise their prices d) break backwards compatibility e) discontinue support f) fail to meet performance SLAs. The architect is responsible for addressing these risks in such a way that if any of these events would happen, the impact is contained.
The single most effective way of containing impact is to effectively manage the degrees of coupling within the system. A Formula 1 team can change the wheel in under 10s because the wheel component is loosely (yet securely) coupled to the car. How long would it take to switch your system from say Oracle to SQL Server?
Where couplings between components are legitimate, there are several coding techniques and (albeit very similar) design patterns you can use to allow for independent evolution of the components yielding contained impact in the event of change. On the coding side, coupling to an interface rather than implementation is a safe bet – thus allowing for different implementations to be plugged in later. On the design front, the strategy, provider and adaptor patterns all help to introduce flexibility into the architecture. For example, the Java Cryptography Extensions (JCE) is a great example of the provider pattern. Initially, I may use a software based provider that performs cryptographic services – but I may upgrade to a hardware based provider (HSM) for when the time comes when a performance boost is required – all without having to change any code. A more common example is the JDBC architecture, where drivers can be plugged in to connect the application to a different database product for its persistence needs.
A goal of the architecture is therefore to provide flexibility without disruption where it makes sense.
Let’s look at one end of the spectrum – “Avoiding the cul-de-sac”. You may have been burnt in the past due to significant amount of rework required as requirements changed or new requirements surfaced during the middle of a project. The common knee-jerk reaction is to make everything flexible, configurable and adaptable. However, like most engineering endeavors there are always trade-offs to be made. Be careful, you may have ended up with un-necessary complexity (which drives up the cost of the project).
Let’s look at the other end of the spectrum – You Ain’t Gonna Need It. With this approach, you eschew flexibility, configurability and adaptability until a requirement surfaces that demands it. This approach is a gamble, but the agile folks will tell you that this is ok because of continuous refactoring and unit tests.
So what is the architect to do? Well, it depends. You have to look at the sub-systems of the architecture and run through some what-if scenarios. To prioritize, I would focus on the sub-systems that have external dependencies. Wherever you have external dependencies, you have given up control. Anything could happen to the external dependency and you have no control over it. The vendor or organization that owns it could a) go out of business b) change their licensing model c) raise their prices d) break backwards compatibility e) discontinue support f) fail to meet performance SLAs. The architect is responsible for addressing these risks in such a way that if any of these events would happen, the impact is contained.
The single most effective way of containing impact is to effectively manage the degrees of coupling within the system. A Formula 1 team can change the wheel in under 10s because the wheel component is loosely (yet securely) coupled to the car. How long would it take to switch your system from say Oracle to SQL Server?
Where couplings between components are legitimate, there are several coding techniques and (albeit very similar) design patterns you can use to allow for independent evolution of the components yielding contained impact in the event of change. On the coding side, coupling to an interface rather than implementation is a safe bet – thus allowing for different implementations to be plugged in later. On the design front, the strategy, provider and adaptor patterns all help to introduce flexibility into the architecture. For example, the Java Cryptography Extensions (JCE) is a great example of the provider pattern. Initially, I may use a software based provider that performs cryptographic services – but I may upgrade to a hardware based provider (HSM) for when the time comes when a performance boost is required – all without having to change any code. A more common example is the JDBC architecture, where drivers can be plugged in to connect the application to a different database product for its persistence needs.
A goal of the architecture is therefore to provide flexibility without disruption where it makes sense.
Thursday, August 14, 2008
Do Architects need coding skills?
Do Architects need coding skills?
In the oft cited parallel world of construction and engineering (of buildings), it is true that to be an architect one does not need to necessarily possess brick-laying skills in order to be effective in their role. However, to be an architect one does need to understand the properties of the materials used for construction.
What about software? Most, in fact pretty much all of the (software) architects I know have some background coding experience. The question to be asked is how essential is it to have coding skills? If an architect can get by without having ever laid a brick, is it possible for a software architect to get by without ever written a line of code?
At least at the current state of our discipline, I would say no.
However, a more contentious question maybe – Do Architects need to maintain their coding skills once they’ve achieved the lofty status of architect. Well, I think it depends. Enterprise architects - possibly not (more on that later). However, for application, solution or product architects – I would say yes. There are many reasons why I think this is the case.
Firstly, the job of the architect is to take a definition of what needs to be built and figure out the best way for how to deliver the solution or product given the imposed time and financial constraints (in reality, the architect is also usually involved in figuring out what needs to be built although this should really be the role of the business analyst or product manager). He/she needs to figure out how to break the problem into manageable chunks (high-level design), decide what materials and tools to use (taking into account the current state of the art and the skills of the development organization) and forage for the non-functional requirements or quality attributes. Basically, the objective of the architect is to deliver better faster cheaper. It’s often a difficult job. The architect may also be stretched and be responsible for data design, dynamic modeling and even detailed design activities such as screen design. Essentially, the architect has to provide whatever it takes to ensure the development organization has enough information to be successful in the build out.
The architect may also be pulled into oversight of the development effort. Throwing designs over the wall and turning your back is likely to result in the development organization delivering something different to what is actually required.
Sometimes, models are not enough. They are by their nature abstract which means they are missing details. The details are where the devil lies. The details need to be figured out sooner or later and so the development organization may either choose to figure it out for themselves or involve the architect.
There may be some system requirements that are difficult to articulate in English specifications. Sometimes, code in the form of prototypes provides an ideal communication mechanism to the development team.
The architect is required to look around and observe and evaluate current trends in technology and processes. Maybe, there is some new toolkit or framework that has been developed that promises to help shorten the development cycle or provide some significant value. Of course, the architect has to try out the technology or process outside of the critical path of the project to ensure fit and readiness for the project at hand. Perhaps some prototypes need to be developed. The architect may need to dive in and learn the new technology before making a sound recommendation to embrace or avoid.
The architect shouldn’t be coding on a daily basis. If the architect is spending most of his/her time then I would argue they are not doing architecture. Having said that, coding is a small yet important component of the architect’s repertoire.
In the oft cited parallel world of construction and engineering (of buildings), it is true that to be an architect one does not need to necessarily possess brick-laying skills in order to be effective in their role. However, to be an architect one does need to understand the properties of the materials used for construction.
What about software? Most, in fact pretty much all of the (software) architects I know have some background coding experience. The question to be asked is how essential is it to have coding skills? If an architect can get by without having ever laid a brick, is it possible for a software architect to get by without ever written a line of code?
At least at the current state of our discipline, I would say no.
However, a more contentious question maybe – Do Architects need to maintain their coding skills once they’ve achieved the lofty status of architect. Well, I think it depends. Enterprise architects - possibly not (more on that later). However, for application, solution or product architects – I would say yes. There are many reasons why I think this is the case.
Firstly, the job of the architect is to take a definition of what needs to be built and figure out the best way for how to deliver the solution or product given the imposed time and financial constraints (in reality, the architect is also usually involved in figuring out what needs to be built although this should really be the role of the business analyst or product manager). He/she needs to figure out how to break the problem into manageable chunks (high-level design), decide what materials and tools to use (taking into account the current state of the art and the skills of the development organization) and forage for the non-functional requirements or quality attributes. Basically, the objective of the architect is to deliver better faster cheaper. It’s often a difficult job. The architect may also be stretched and be responsible for data design, dynamic modeling and even detailed design activities such as screen design. Essentially, the architect has to provide whatever it takes to ensure the development organization has enough information to be successful in the build out.
The architect may also be pulled into oversight of the development effort. Throwing designs over the wall and turning your back is likely to result in the development organization delivering something different to what is actually required.
Sometimes, models are not enough. They are by their nature abstract which means they are missing details. The details are where the devil lies. The details need to be figured out sooner or later and so the development organization may either choose to figure it out for themselves or involve the architect.
There may be some system requirements that are difficult to articulate in English specifications. Sometimes, code in the form of prototypes provides an ideal communication mechanism to the development team.
The architect is required to look around and observe and evaluate current trends in technology and processes. Maybe, there is some new toolkit or framework that has been developed that promises to help shorten the development cycle or provide some significant value. Of course, the architect has to try out the technology or process outside of the critical path of the project to ensure fit and readiness for the project at hand. Perhaps some prototypes need to be developed. The architect may need to dive in and learn the new technology before making a sound recommendation to embrace or avoid.
The architect shouldn’t be coding on a daily basis. If the architect is spending most of his/her time then I would argue they are not doing architecture. Having said that, coding is a small yet important component of the architect’s repertoire.
Subscribe to:
Posts (Atom)