In the problem at hand, we needed to describe an item that will appear in an insurance policy that must be covered for fire damage.  It turns out that these items are not trivial in their structure, and many things influence the premium that will paid by the policy holder for fire insurance.  So, the first bit of code (in Java) in the test looked something like this.

FireItem fireItem = new FireItem();
fireItem.setIndustry("Building Construction");
fireItem.setOccupationCode("Workshop");
// the postal/zip code for the location of the insured item
fireItem.setAreaCode(7800);
// ignore the number, we actually created a Money class
fireItem.setSumInsured(200000.00);
fireItem.setRoofing("Non-Standard");

After the test passed, we refactored and I sneaked in a factory method which will be used to honor default values and at the same time threw in a fluent interface (the term coined by Eric Evans and Martin Fowler.  After all, I was also quietly introducing Domain Driven Design without actually saying that).

The code looked like this.

FireItem fireItem = FireItem.create()
                            .inIndustry("Building Construction")
                            .withOccupation("Workshop")
                            .InAreaWithPostalCode(7800)
                            .forSumInsured(200000.00)
                            .havingRoofing("Non-Standard");

The FireItem class looked like this:

public class FireItem {
    String industry;
    String occupation;
    // other properties ...

   private FireItem() { }
   public static FireItem create() {
       return new FireItem();
   }
   public FireItem inIndustry(String industry) {
      this.industry = industry;
      return this;
   }
   // other chained methods follow a similar style returning "this" ...
}

Nice! Much more readable. But, we then realised that it’s easy for someone to miss one of the methods in the chain.  That will result in the item having an incomplete structure.  Not good!  

One of the things I tend to do as a coach, is to let the team I am working with, experience the problem, solution and any rewards and smells as well.  Sometimes I even throw in red herring for sake of experience ;-).  So, the third pass at refactoring was to introduce a validate() method on the item which throws an exception if everything was not in place.

try {
  FireItem fireItem = FireItem.create()
                              .inIndustry("Building Construction")
                              .withOccupation("Workshop")
                              .InAreaWithPostalCode(7800)
                              .forSumInsured(200000.00)
                              .havingRoofing("Non-Standard")
                              .validate();
} catch (FireItemException e) {
  // handle the exception
}

Now the user of this class needs to know that the validate() method must be called before they really want to use an item object.  Yuck, that’s smelly!  So, for the fourth design refactoring, I introduced a builder and moved the fluent interface to the builder, still using method chaining but introduced a build() method that did the work of the previous validate() method before returning the well structured item.  The FireItem class now needs the traditional bunch of getters and setters (rant - the framework goodies need them anyway!!)

import static insurance.FireItemBuilder.fireItem;
// ...
try {
  FireItem fireItem = fireItem().inIndustry("Building Construction")
                                .withOccupation("Workshop")
                                .InAreaWithPostalCode(7800)
                                .forSumInsured(200000)
                                .havingRoofing("Non-Standard")
                                .build();
} catch (FireItemException e) {
   // handle the exception
}

Much better!  Note the use of the static import which gives us the liberty to use the static method without specifying the class in code body.  The FireItemBuilder class looked like this.

public class FireItemBuilder {
   private final FireItem fireItem;
   private FireItemBuilder() { 
      fireItem = new FireItem();
   }
   public static FireItemBuilder fireItem() {
       return new FireItemBuilder();
   }
   public FireItemBuilder inIndustry(String industry) {
      fireItem.setIndustry(industry);
      return this;
   }
   // other chained methods follow a similar style returning "this" ...
   public FireItem build() throws FireItemBuilderException {
      validate();
      return fireItem;
   }
   private void validate() throws FireItemBuilderException {
     // do all validations on the fire item itself and throw an exception if something fails
   }
}

Sure, we can improve the bubbling of the exception from validate() to build() and we could do with a better name for validate().  And perhaps, validate() should be on the FireItem class.  But let’s stick to factories and builders and fluent interfaces.  I think these three things work nicely “together”, when used for the right purpose.

In a nutshell, factories are great for creating objects where defaults and invariants are easily honored during the simple call to the factory.  However, if the structure of the object is more complex which makes long argument lists ugly, and some form of validation is necessary  before we can use an object then a builder works beautifully.

Also, note that the fluent interface was used to improve readability and kick off a tiny little DSL for describing insurance items.

An alternative is to allow the object to have an invalid structure but you track it with an invalid state, perhaps using a state pattern.  This is not exactly what the state pattern was meant for, but it will work nonetheless.

The last time I was with this team was in August 2006, and it is really great to work with them again.  So, much more for me to learn from them.

• Architecture Track: Designing for Modularity - one of my pet frustration and, at the same time, fun challenges.
• Agile Track: Managing Diversity in Agile Teams - based on two years of experiences at a rather tough client.
• Java Track: Solving Domain Problems with Aspects - another big challenge for me since aspects are normally used to solve application infrastructure problems.
• Workshop: Bootstrapping your SOA Project - this is a modified version of the workshop I did for IQPC earlier this year.

I certainly did not expect to be doing 4 sessions!  It’s going to be a busy conference but also immense fun.  I hope that I get the time to attend the other talks and learn from some amazing people.  I certainly will be catching up with old friends as well

I will be giving a short introduction to behavior driven development (BDD) at the XP forum on 13 August 2008.  As usual, I’m using the opportunity to subtly throw in some other practices such as coding for readability and designing good messages.  I will also touch on mocking in tests as well.

I’ve been having immense fun putting together some code examples for this talk and I hope to demo BDD using JUnit, JBehave, RSpec (using the rbehave story runner on JRuby to test Java) and JTestR (which looks like a really exciting little project).

Come along and enjoy the fun.  Details and registration is on the JCSE web site.

Update 1: The Source Code for BDD Presentation is now available.

Update 2: The presentation is now available for download here.  It’s a 5MB Quicktime movie file. It’s not a continuous play movie, so you need to click through to the next slide. ]]> http://aslamkhan.net/events/introduction-to-bdd/feed/ http://aslamkhan.net/software-development/unconventional-or-uber-coaches/ http://aslamkhan.net/software-development/unconventional-or-uber-coaches/#comments Fri, 18 Jul 2008 07:08:37 +0000 Aslam http://aslamkhan.net/?p=41 Fortunately, there is always a balance in the universe. The people that balance out the power oriented architects are some of the true leaders in society, past and present. These are the people that live a value system intrinsically and that just becomes pervasive in the teams or groups with whom they work. They lead and they coach, they teach and are taught. After all, building software is a social exercise more than a technical exercise.

Here are some people that I think would have been fantastic agile coaches (in no particular order).

• Mahatma Ghandi stopped ethnic violence between Hindus and Muslims by believing in the equality of everyone. There is one quote of his that stays with me when designing software: “The only solution is that which is just for everyone”. Ok, I may have got the exact wording wrong, but you know what I mean.

• Bruce Lee was a man that sought perfection through serious introspection. He found meaning through the martial arts and when he found it, he realized it was not about the power but the subtleties of understanding yourself.  Again, something from Bruce Lee that helps me find build simpler solutions: “In building a statue, a sculptor doesn’t keep adding clay to his subject. Actually, he keeps chiselling away at the unessentials until the truth of its creation is revealed without obstructions”

• Nelson Mandela forgave those that incarcerated him, completely and selflessly. And in doing that, he taught 45 million people that change is possible. He has an amazing ability to make everyone feel at ease with his humility. There is no private face nor public face. There is just him. So, for the toughest bits in every design, I turn to this great man: “It always seems impossible until its done.“

Happy 90th Birthday, Madiba!

I just wish you could code as well as you coach

It has been a spectacular mess!  It is a textbook on agile gone wrong.  It is a textbook on architecture gone wrong. It is a textbook on how not to write good code.  There are many lessons to be learnt and that has been the most valuable outcome of this project.  I will be speaking on some of these agile lessons at Oredev in November this year.  For now, I just want to reflect on one single thing that popped into my head during dinner with Chris Naidoo from Psybergate last night.

Here goes!  The project has failed because of power brokering.  Too many people are fighting for power.  Power gives control and control gives more power.  The fundamental value system of the entire team (client included) has been compromised because of the desire for power and control.

The net result is personal conflict.  Personal conflict is not healthy.  Conflict in driving at solving a problem is healthy.  If there is battle for power, there is always personal conflict because politicking will happen. Teams get fractured in power alliances and off-line caucusing occurs.  Egos are reinforced and confidences are destroyed.  One person posturing superior than the other, forever trying to be top dog for the sake of being top dog.  There is never a winner in a power battle and everyone loses.

At an architecture level, as designs emerged, they were shot down like moving tin ducks at a carnival game.  The power player won and the architecture and design that went into production was that of the person that had power at the time.  It was not the team’s architecture.  So there was not sense of responsibility in the team that resulted in no pride in work delivered.  Sensible and rational thinking is lost when a leader is blinded by power and the team exists without purpose.

So we had a power oriented architecture.  We also had a power oriented methodology.  And a power oriented value system.  And power oriented development.  I am not innocent.  I did my own bit of power grabbing as well.  I destroyed myself and violated my value system … a bit.  I did realise that if I stopped fighting against power, there will be no fight for power.

I have only 3 people from the original team, me included.  One of the power brokers has moved on to a position of greater power but has less direct influence on the team.  There is a new power player in the wings.  The team is fresh, new, no power battle scars.  So we won’t fight the battle.  Too many lives have been lost.  This is not Ghandi’s passive resistance.  To resist, even passively, is to take a position in the battle.  Instead, we will resort to a value system that treats people equally, responsibly and give each person the dignity they deserve.  I wish could give that dignity back to those that have left, fallen in battle.  You know who you are.  I wish I could have done more.

Architecturally, we have resurrected one of the tin ducks that was shot down about 18 months ago.  Not by me, but by someone else who came to the same solution independently.  But it’s not a “I told you so” situation … that will start the power battles again.  So BDUF has returned, TDD has returned.  The agile practices that we cherish and shout out will be implemented again, through natural and progressive adoption, each person adopting agile practices at their own pace, guided by a value system shared by all.

Power oriented architectures and power based management does not work.  Agile embraces a simple philosophy:  think about the next person before you think about yourself.  Agile is not about loss or gain of control, it is about collective ownership.  Once you grok that and live that, then it does not matter how bad your architecture is, how unreadable your code is, or how late your are on the project. It is simple: because the team is still equally responsible for everything, moving forward out of the mess, in small steps is do-able.  There is no blame because there is no power battle.

This project has changed me to be a worse person and it has changed me to be a better person.  I hope the others on the project have the same carthatic realisation that I had with Chris Naidoo.  Chris just didn’t know that happened during our conversation.  Now he knows.

By the way, I now realised that there are many power oriented architects in many teams that I have worked with in the past.  I just did not know that it was always a power issue.  Drop me note if you have come across any power oriented architects that create power oriented architectures.

The heart of my workshop centered on the theme that you cannot steer clear of business or domain knowledge, even if you try to design your services by wrapping existing software assets.  It just has to align to reality in the business, otherwise you will just create another architecture that has a fractured line to the business needs.

The other interesting theme that arose, unintentionally, was that it may well be easier to sneak in SOA by thinking in services and building some solutions covertly.  Once value is delivered and becomes noticeable, then start spreading out to the next cell … almost virally.

I summarised the main thoughts in the article on DZone at http://architects.dzone.com/articles/top-down-soa-aligning-business.

But everything is not everything.  A raucous revolt has been going on for a long time and there are just a few dictators hanging around clinging onto power.  The actions have created their own federated colony where they rule over the data.  “Rule” is a tough description.  Data are actually the protected citizens.  They are governed by a glorious constitution that ensures that their rights are not violated.  They behave within the guidelines of the constitution.

This new frontier is, indeed, a difficult world to understand.  It is even more difficult for the tourist companies putting together glossy brochures selling vacation trips to this world.  How do you describe a vacation utopia for something that is abstract.  Really, we can’t see an action but we can see data!  It is genuinely abstract; the action is a kind of energy that exists and binds the data.  It’s like saying that we can’t see the 4th dimension, but we understand it and know it exists because we can see the three dimensional shadows it casts into our universe.

If you’re still wondering what these extended metaphors are rambling about, then let me cut the meat closer to the bone.  BI architecture is stuck in stale techniques of moving and accessing data around the enterprise and it uses procedural techniques (the actions) to achieve this.  Everything is centered on data and data is centered on creating efficient actions as slaves.  In the world of equality - the one with the nice constitution - encapsulated behaviors (actions) protect the integrity of the data.  There are defined contracts and objects are the carriers for behavior and data.

There is so much that can be learned from this ignored world.  For example, the problems of scalability has been solved with statelessness.  Contention for shared resources have been solved with highly concurrent techniques that remove semaphores and other dead lock creating protection schemes.  The freedom to work with data in forms that are natural to the data is clean and efficient.  If data looks hierarchical in structure, then we can use use storage that naturally works with directed graphs, with lazy loading thrown in for good measure.  If data looks dimensional, then we can use a single multi-dimensional table that tolerates variant hash maps for individual columns.  If there is a need for massively parallel processing, then we can use map-reduction techniques over a distributed file system in a massive cluster of commodity hardware.

BI desperately needs change.  So throw away the clay tablets and start thinking laterally.  It’s a lot more flexible.  And if the tourist companies selling vacations want to take advantage of the new frontier, then they better understand the laws that govern this world.

Data exists because of the actions and not the other way around.  Get with the program and embrace the techniques, tools and agility of the new frontier to build better BI solutions, instead of trying to get everything to conform to that old clay tablet.  The body did not create consciousness, consciousness created the body.  Here’s the bottom line:  BI is stuck because it is a body without consciousness.

For me, I’m “just an earth bound misfit learning to fly” .   I’m still grappling with impedances and shear planes between these dichotomous worlds, trying to get others to see the value of using multiple disciplines for the symbiotic benefit of both.  I’m still “tongue tied and twisted” but a little step closer to “learning to fly”.

** Lyrics from “Learning to Fly” by Pink Floyd.

 Note: Most people know that I work for a company that crafts business intelligence solutions and that I work on the enterprise application development side of the company.  Unfortunately, I really do think that BI is lagging behind the times and that it needs a serious jolt.  The plethora of proprietary, non-agile tools and practices is still a problem.  Perhaps there are others out there that can enlighten me on the strides they have taken to built better BI architectures.

I think there are several layers in A-*. I have no idea what is stacked on top of what, but Here is my A-* stack as I think of it right now, and we’ll try and refactor it later to gain deeper insight into the layers of responsibility and order that must evolve out of the chaos.

• People Layer: This layer is responsible for establishing a team ethos. It is vital to creating a common work ethic in the team, shared values and principles. It is the lowest common denominator. In high conflict teams with high discord, things fall apart easily. Under these circumstances, you need to drop to philosophical introspection of your team values such as honesty, respect, reasons for existing on the project/or building the solution.
• Project Management Layer: Managing a project founded on agile practices, even those that use agile practices partially, is no easy task. There is a dedicated layer of responsibility that keeps track of project velocity, prioritization of stories, facilitating feedback and managing change. Sure, we embrace change in agile projects but it still needs to be managed within the prioritized list of stories and other constraints of the project. This is different from traditional PMBOK style project management and deserves its own layer of responsibility.
• Development Layer: This layer embraces the technical practices of the software developers. It includes niceties like continuous integration, test driven development, code refactoring, single code repositories that guarentee one version of the truth. This is, perhaps, the one layer that is best understood and have tangible actions at the code face.
• Architecture and Design Layer: This layer is more than it’s really cool acronyms like YAGNI, DRY and BDUF. The focus is on gaining deeper insight into the problem domain. It very likely shares a gray and fuzzy area with the Development Layer and that’s ok. It really doesn’t matter that we have spillage into the development layer or vis versa. As long as we focus on gaining maximum understanding of the problem domain and modelling the solution as simply as as is possible.
• Run-Time Layer: This is an oee one that I’ve dwelled on for a while. Sometimes the run-time environment really gets in the way and obstructs fluidity and rhythm in the development and architecture layer. It may well be the least agile of all layers in A-*. So, choose wisely … if you can. Let me explain a little further by example. The Ruby on Rails folk have made many screen casts that show how you can change code and you can just reload the page and, magically, the change is visible. Now compare that to someone writing EJB’s. Write, package, undeploy, deploy … it’s just painful, even if you are POJO+TDD inclined. The EJB container will bite you, eventually. So, in some respects the RoR runtime is more agile than the EJB runtime. (Aside: I think the only agile runtime in Java world is OSGi because it supports dynamic loading and unloading of classes and multiple versions classes in the same namespace. Now that’s agile!)
• Environment Layer: The place where the team work is an equal contributor to agility. From how your workpace is layed out to desk configurations in an open plan office space, it is significant. Audible and visual communication is important and this may overlap ever so slightly with the people layer. I think the environment has a dedicated layer of responsibility in A-*.
• Toolbox Layer: The tools you use can help you become more agile. I find that a flip chart, white board and multi-colored markers keeps me fluid and helps me progress rapidly, especially when I am working in the Architecture and Design Layer. We all have our special favorites that include the full blown IDE with our special key bindings, code diff tools, and even specialised items like shared whiteboards. I know of one team that has a Skype bot that acts as their JIRA interface - chatting to thet Skype bot allows them to update statuses and query JIRA. What tool ever keeps you agile has a place in this layer.

Perhaps, you have some other thoughts about what goes into A-* and what should be taken out. Maybe you have some real world insights that go beyond my meagre learning experiences. Drop me a note … I really would like to know how your A-* stacks up.

1. Old Habits + Old Technology = Predictable Outcomes
2. Old Habits + New Technology = Drastically Altered Consequences

Note: I may have got the wording a bit wrong but the essence is the same.

On the same weekend I was reading Jimmy Nilsson’s book Applying Domain Driven Design and Patterns (which is an excellent read, by the way). In the opening part of the book Jimmy describes what he has tried previously in his attempts to achieve good object oriented designs. By his own admission, he was not very successful. I’ll put my neck on the line and say that the problem was a case of formula 2 (but it’s not the first time I’ve been wrong :-))

I see formula 2 playing out often. A new technology emerges and we want to push the boundaries but our mindset is still a step behind. We use old habits with something new, miss the target, and sometimes create a mess of consequences which was never expected. I am certainly not innocent in this, either. To make matters worse, we sometimes use the “drastically altered consequences” to prematurely judge the new technology. The problem is not necessarily the technology, it is more likely that we used the new technology with a perspective of old habits. (Aside: Maybe formula 2 is also one reason for misuse of technologies.)

On the hand, I think formula 1 is the reason that we have legacy code and tried and tested technologies. The comfort and safety of old habits working with old technology makes a lot of sense. I still come across high quality Visual Basic 6 or Delphi applications written by highly productive teams that are not just in maintenance, but are actively being developed with new enhancements, etc.

In order to make a difference, we need to change our thinking which forces us to consciously alter our habits. It is only when we shift perspectives and behaviors will we be able to grasp a new technology or technique and make progress with minimal side-effects. The next time I am up against something new, I need to make a conscious effort to drop preconceptions and habits and make some adjustments.

There are some classic cases of formula 2 that I come across in many projects and teams. Here’s my top two.

1. Relational/Set Oriented Thinking + Object Oriented Language = High Maintenance Consequences
2. Stateful Client + Stateless HTTP = Low Scalability Consequences

What else have you come across?

I will be running a full day workshop title Understanding How an SOA Project is Structured. It’s actually a wee bit more than the title suggests … look at the workshop page and see what I mean.

Why not sign up and join in?  It’s going to be fun