Lets reflect, shall we?

Ok, so last week I got my copy of Java Reflection in Action (http://amzn.to/uGp3Vo), from Amazon. I was eagerly waiting for it to arrive. Java reflection brings fear to most programmers. They are concerned with its complexity & of course the security risks and performance issues. Reading through the first chapter all three of those myths gets busted.


 It is incredible how much coding reflection can save. The main idea is to utilize reflection to perform tasks that we would do manually. For example, quoting directly from Chapter 1,


1. Examine the program for its structure or data.
2. Make decisions using the results of the examination.
3. Change the behavior, structure, or data of the program based upon the decisions.

You'd not expect the above tasks to be carried out by a program. it is a reasonable assumption. However, you can easily accomplish the above via reflection.

I would like to leave you with the following:

The java.lang.Object class is an instance of java.lang.Class class which itself extends java.lang.Object class and instance of java.lang.Class

Awesome!!,  isn't it? If you know reflection, you would not have trouble deciphering the above!
Add reflection to your toolkit today. This will be the first of many posts.

Follow @janith4real
View Janith Perera's profile

It's time to dive in .. !! Head First !! If you haven't already

This post is a tribute to one of my favorite tech books (If not the favorite tech book of all time), Head First Design Patterns by Eric & Elisabeth Freeman.

Back in 2005, I was exposed to the unique world of Head First books through Head First EJB. Note that this was the time when EJB 2.1 reigned & any Java developer having even the slightest experience of it will know the pain of pre EJB 3.x era (which I won't go into any detail now). Anyway, the Head First approach made EJB 2.x look quite harmless). Their approach includes lots of pictures & characters in their books as well as unique conversational style of writing, which makes reading an enjoyable experience. Oh .. and please note that I am not getting any benefit from endorsing Head First books, I would gladly do it for free :)

HF Design patterns second book I bought, way back in 2006 (I have 12 head first books now!!!). Needless to say I was hooked! The authors explain patterns using outrageous examples,

• Strategy pattern is explained by way of setting flying behavior of Ducks
• A pizza store is used to explain Factory pattern & its variations
• Ordering different types of coffee topped with various condiments in a coffee shop demonstrates Decorator pattern
• The order flow in a Diner between the customer, waitress & the cook shows the Command pattern in action.
• A Gumball machine (yes .. you heard it right) demonstrates State pattern.
• A merger between a diner & a pancake house sets stage for Iterator & Composite patterns.
• And so on .. (I don't won't to spoil all the fun)

The examples are simple & is in Java. So, C# developers may not have any problem there. In any case the code is very simple so any programming language background should suffice.

The Gang of Four (GoF)  design pattern book is widely considered as the bible for foundation design patterns.

However, for a beginner the concepts can be a bit hard to grasp (samples are in C++, which can be distracting if you are not familiar with it ). That's where HF Design Pattern book provides an excellent spring board to the more formal (but quite excellent GoF design patterns book)

So enough said already. If you want to learn design patterns & have fun at the same time, do yourself a favor & get HF Design Patterns. I guarantee that you won't regret it.

Role of Architecture in Agile Projects

The Essence of Agile Development

Agile development is more than a buzzword. It has given rise to popular methodologies like Scrum & XP. The Agile Manifesto [1], sums it up nicely:
 

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Items on the left are valued more in agile development. It embraces changing requirements & its primary measure of success is working software. Simplicity is at the core of agile development. One might argue that there’s nothing simple about Test Driven Development (TDD) & refactoring, but if you look closely TDD is about developing a feature in small steps, by first writing one test at a time and refactoring is about restructuring code in small steps. So, continuing on the same theme, it is no surprise that it also advocates simple design, which effectively means that striving for the simplest design/architecture that works. This is also known as the YAGNI (You Aren’t Going to Need It) principle [2], which discourages putting the architecture in place for future functionality.

 

The Myth Surrounding Architecture in Agile Projects

As highlighted in the previous section, simplicity is valued in all agile methodologies. On the other hand you have architecture, which is perceived as complex & heavyweight. This traditional view is known as ivory tower architectures [3]. So, there’s no surprise that architecture takes little recognition in agile projects & often completely ignored.

One of the most common myths with regard to agile development is that upfront architecture or design is bad. The problem comes from how people perceive ‘architecture’. They still seem to have the traditional view of architecture (when Waterfall approach was prevalent), where it was time consuming & difficult to get right & also done by a single experienced person in an authoritative manner.

Architecture was time consuming simply because of communication delays with the concerned stakeholders (in other words, poor stakeholder engagement) & it was error prone because we were concentrating on getting all the requirements nailed down upfront. This was a recipe for disaster because at the beginning of the project, requirements are not evolved enough for us to make concrete decisions. This leads to costly rework in development & worse, features that are not being used by the customer.

Agile methodologies evolved from the fact that requirements are always changing & consequently in each iteration (a mini development cycle) we develop the software product which reflects the requirements at that point. Therefore, the weight of ‘architecture’ appeared to hamper the ‘agility’. Also, agile methodology discourages Big Design Up Front (BDUF). There is no doubt that BDUF is harmful & a waste of time, but that doesn’t mean there aren’t any architectural issues & design decisions we can make early. In fact, agile principles (stake holder involvement, self organizing teams, no single architect – every stake holder plays some part in it, etc.) make architecture lightweight.

 
Towards Agile Architecture

We need to look at architecture in a different light. We need to make it lean. Traditionally architects who were responsible for architecture were mostly disconnected with other stakeholders & developers didn’t have any say in it, so there were little or no ownership of code. The lean secret – “Everybody, altogether, early on” [4], helps in one aspect. It suggests everybody has some part to play in architecture & all the parties are involved from early on.

Agile practices frowns upon Big Design Up Front (BDUF), but most developers make this an excuse to skip design completely. Therefore, architecture, which is part of design, is ignored. However, there are architectural issues that can be resolved upfront & design decisions that can be made early [5]. Some agile projects have an iteration zero [6] for up-front design work. In fact XP (Extreme Programming) advocates initial up-front design.

Fairbanks [6] suggests that architecture is (Mostly) orthogonal to functionality, which means that it is the most stable part of a software system compared to frequently changing functionality. Coplien [4] has a similar idea when he suggests the separation between system form (what the system is) & system functionality (what the system does).

So, to wrap up: Architecture is important in Agile projects. A little 'lightweight' investment upfront on architecture will go a long way in the Sprints that follow.

References

· [1] Kent Beck, Martin Fowler, et al. Manifesto for Agile Software Development. [Online]. Available: http://agilemanifesto.org/

· [2] Robert C. Martin, Agile Software Development, Principles, Patterns, and Practices, 1st. ed., Prentice Hall, 2002.

· [3] Scott W. Ambler. (2011.). The Agile Architecture: Strategies for Scaling Agile Development.[Online].Available: http://www.agilemodeling.com/essays/agileArchitecture.htm

· [4] James Coplien and Gertrud Bjornvig, Lean Architecture for Agile Development, 1st. ed., John Wiley & Sons Ltd., 2010.

· [5] Robert C. Martin. (2009, April.). The Scatology of Agile Architecture. [Online]. Available: http://blog.objectmentor.com/articles/2009/04/25/the-scatology-of-agile-architecture.

· [6] George H. Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach, 1st. ed., Marshall & Brainerd, 2010.