trajectory

notes from the field...

Accountability

So what would you do? You’re riding home to see your 4 month old son and your lovely wife, in traffic and doing all the right things - obeying all the rules.

The car next to you cuts hard across you, no indication, turning into a side street without being in a turning lane.

You touch the side of the car and glance off at pace trying your best to correct and turn away from any obstacles, hit the curb and go flying over your bike as it lands on you while you skid and scrape your way along the hard footpath…

Sort of like sliding along a cheesegrater at speed. You bounce hard but you’re OK and you stand up quickly to assess the damage - you’re OK - this is amazing.

Then the guy driving the car jumps out, and says, “I’m sorry, I made a late decision, didn’t check, didn’t indicate and this is all my fault - can I do anything to help?”.

A motorcyclist comes running over after seeing everything and exclaims, “That was a serious hit mate are you OK? Do we need to call an ambulance?”. I’m still standing, shaken and stirred and bleeding but … I’ve had worse falls and thankfully all is well.

My reaction was not one of anger - this person openly apologises and claims responsibility for his actions, as opposed to the many others on the roads who would probably have just driven away.

I almost felt awkward asking the guy to pay for damage to my gear, and my bike.

Not the best thing to happen to me - I’m sore and I can’t sleep well because one side of my body is pretty banged up but I will heal, and he is genuinely sorry for this.

I’m thankful for his approach, and I call him when I get home (I insisted on riding home) and let him know that things are fine. I’m so glad to see my family.

He will most certainly pay more attention, and I will ride more defensively given what is at stake.

I’ll probably make a friend after this is all done.

Technology Background: Agile Web Application Development in an Enterprise Environment

Continuing from my previous post about agile development in the corporate context, I will describe the technology we used to be able to rapidly deliver web applications. To deliver 50 web applications in a year we needed some basic structures in place:

  • An application framework which would allow us to rapidly create and maintain web apps, with in-built flexibility given ever changing requirements
  • An underlying infrastructure that would serve 150 apps (suggesting a 3 year lifespan)
  • A modicum of secure controls over our application environment and infrastructure so as to autonomously deliver our work
  • Automation
  • More automation

We chose to use the following:

  • The Symfony MVC framework, and somewhat confusingly, the JBoss Seam framework [1]
  • Red Hat Enterprise Linux as it was our corporate standard Linux - to create dev, test and prod environments
  • Apache, MySQL to round out web serving and the database of choice
  • A small arsenal of shell and perl combined with clever sudo access for non-root users to give thorough and secure control over these hosts
  • Atlassian Jira and Confluence for issue tracking and documentation respectively.
  • Atlassian Fisheye and Crucible plus Subversion for development peer review and source code management respectively.
  • Socialcast for inside the firewall microblogging and collaboration

With all of the above, we were able to manage the delivery of an entire web application from concept to reality without the need to engage any other IT teams. Well, that’s not entirely true - we needed to create new URLs for these apps, so we’d need to request a new CNAME record which would take sometimes 2 weeks…(!!!)…

We quickly realised that there were common components being delivered repeatedly - such as the authentication layer in these applications needed to authenticate against Active Directory. Or, that employee lookups were being performed against that corporate directory. We quickly developed reusable modules of code that would allow any app to have these common functions without needing to write any code.Knowing what I know now, I would humbly suggest a few changes to the above stack - but more of that will be covered later …

I discussed these structures at a recent cloudcamp in Auckland - suggesting that a PaaS approach to deployment scalable web apps would be ideal for this team, however venturing outside the firewall - especially on cloud platforms is a pretty big ask for a somewhat conservative company.

[1] With all due respect, we included Java in our stack just to appease a few people who felt there is no other choice for the “Enterprise”

Milestones

For the last three years, I worked for an Australian Telco - having been a founding member of a tiny team tasked with the delivery of short, sweet web apps that can be delivered quickly, and will resolve “low hanging fruit” business problems. The team was created to rapidly respond to smaller business problems that were often overlooked, or subject to inappropriate costs as they were forced through a large project lifecycle.

The idea was simple:

  1. deliver high value and incur low cost - use open source MVC framework, OS and Database (LAMP)
  2. minimise overheads - one developer paired with the customer’s single representative
  3. focus on delivery of small scope iterations and highest quality - 4 weeks to deliver a functional application
  4. charge nothing to the business for application development and hosting

For a low operational cost (4 developers and 9 virtual machines running a LAMP stack), the team continues to deliver on all fronts.

For those interested, I have elaborated elsewhere about the business justifications for this team.

We had three tenets:

  • integrate with nothing - build standalone apps (exception here is the integration with the company LDAP directory for SSO)
  • never build a public facing application - your work lives on the intranet alone
  • ensure you can deliver something useful and of value in maximum 4 weeks

For those interested, I have elaborated elsewhere about the technology used by this team.

I finished my tenure with the Express Solutions team on the 27th of January, 2011. I will miss the team, our leaders and our customers. Three years is a long time to do the same thing, and I have decided to move on in the spirit of challenging myself to continuously improve and learn.

Here’s a brain dump of the things I have learned.

  • Work for engaged customers. There is no better partner than one who is motivated to deliver something of high value.
  • Build a team of “(external) polymaths”:http://en.wikipedia.org/wiki/Polymath. People who can write great code are not enough. They should be articulate, communicative and able to manage complex delivery.
  • Quality is everything. A four week deliverable will never be lauded as huge success unless it works beautifully on day one.
  • Reuse is paramount. Effort is cost - and it makes no sense to repeat your effort.
  • Remove administrative overheads. Automate the creation of infrastructure, and empower yourself to impose change easily, safely and regularly.
  • Move fast and be smart. Deliver something small every day if possible - especially in a 4 week life cycle.

So, about a year ago, I put in place a plan that sees me take the next step in my professional career.

I signed up for a business partnership with a focused, motivated and very decent individual and together we strive to do the above, and with a pretty interesting toolkit at our disposal. More about this later…for now feel free to check out our company website.

Suffice to say - Express Solutions is a team that means a lot to me - and I respectfully single out two great mates and colleagues. eHabib and Massive were my partners in the creation of the team, and I sincerely hope our paths continue to cross in many adventures.

Onwards…