Thinking Inside a Bigger Box

The TED conference has some amazing talks. If you never knew you were interested in car seats for children, classical music, or feet (yeah!), some of these talks will blow you mind.

A recent video that really moved me was Benjamin Zander, the conductor of the Boston Philharmonic. His insights and inspiration is invaluable for everyone who considers themselves a leader.

“The conductor doesn’t make a sound, he depends for his power on the ability to make other people powerful… I realized that my job was to awaken possibility in other people.”

At the last meeting in Oslo Lean Meetup Geoff Watts talked about BTs transition to agility. The most memorable part to me was when BT transformed a huge, waterfall type project with a delivery schedule measured in years into an agile project. The project set out to convert all BT customers to a new network with a brand new set of services. The new objective was simpler: Deliver one service to one customer in eight weeks.

The common approach when organizations undertake a huge project is to try and deliver everything in one big bang. That trick never works, and BT was exceptional for realizing it. The eight weeks goal was indeed reached, not with one, but with four customers. This might not sound like a lot, but after several years with nothing to show for it, this is a huge win for any project.

How did BT facilitate the transition to agile? The order from up high was “everyone needs to deliver something every 90 days.” In order to achieve this, all projects start a ninety day delivery cycle with a three day off site meeting with all stakeholders to find out how the project can deliver something of value within the required time. Surprisingly, according to Watts, it almost always works.

An interesting lesson is that a shorter delivery time means that the projects have to focus on doing less at a time. Yet projects report a greater sense of progress. In essence, they slow down to speed up.

BT is a huge organization with lots of cultural legacy. If they can deliver huge infrastructure projects in increments of no more than ninety days, why can’t you?

People always talk about how learning is something that happens in groups. Last week, I got reminded of the point as a task I had previously struggled with alone became trivial in a pair programming episode.

The first time I tried coding “a bowling scoring program” was in 2001. I’ve practices the exercise many times later. In 2004, I tried to write a more challenging version: Write a program that prints the numbers that should be displayed on a score board for a partially played game of bowling. I got bogged down and sidetracked, and didn’t come up with a very good solution at all.

Last week, my company invited Ron Jeffries and Chet Hendrickson to give a short course in pair programming and test-driven development for 15 of our developers/testers. Ron and Chet has coded this particular program a number of times, but never with the score board variation I mentioned.

In the second half of the course, I sat down with two others of our developers who had never worked on this exercise before. We quickly finished the simple game, and then someone proposed the score board. I said “oh, that’s way too hard, we’ll never finish it in time for the course”.

To make a long story short: I was wrong. Together, we solved the problem in no time flat.

Three years ago, I was asked by one of our teams to give advice on how they should write a parser for a structured file format. Just having read up on SAX again, I recommended that they looked into designing it as a push parser. A push parser works by the design that the parser generates events each times it reads parts of the input. These events are sent to an event handler, which then builds up the internal object structure or whatever the program needs. A push parser is a very object-oriented approach to parsing.

About a year ago, I took over the reigns, as it were, on this project. The strategy I had recommended had resulted in a horrible design. After having spent a total of a few weeks to fix issues with it, I finally gave up and rewrote it as a simple procedural parser. The rewrite took me three days plus about a day of fixing some edge case bugs. The resulting code was a tenth the size of the push parser.

This leads to my dilemma: As a senior professional, what should I do when I’m asked to give advice on software design?

Read the rest of this entry »

Warning: This article requires a lot of editing love before it is very useful. It might be somewhat incoherent. Read at your own risk. ;-)

Silo (software): A silo system cannot easily integrate with any other system.

In software, the term “silo” is used to refer to a system that is constructed as one unit from the front end to the data storage. Everything is tied together to work with the rest of the silo, but not with other elements.

This is considered a bad thing.

The problem comes when we want to integrate the system with other systems or reuse parts of the system.

Many of the new ideas in software development has as one of their big goals to try and rectify the silo problem. In general this is achieved by splitting up the system into services that may or may not be distributed across different computers.

But the badness of the silo hinges on two claims: First, that the applications built as an integrated stack cannot be integrated with, and second, that a system of distributed services can be integrated with.

Read the rest of this entry »

This article is a Norwegian-language version of my article Four bold claims about SOA.

Dette er et utkast til en artikkel jeg ønsker å få publisert. Jeg setter stor pris på tilbakemeldinger om uklare tanker og formuleringer.

To av de vanskeligste problemene vi møter innen programvareutvikling er integrasjon og det som gjerne kalles “business-IT alignment” eller forretningsorientering, altså: IT skal understøtte virksomhetens strategiske mål.

Tjenesteorientert arkitektur, eller Service Oriented Architecture (SOA), hevder å kunne løse begge disse problemene. I det siste har jeg forsøkt å lytte mer aktivt til påstander fra evangelister av SOA, og jeg begynner å få en forståelse for hva det er SOA foreslår som løsningen på problemene vi står overfor. Dette er min oppfatning av påstandene om hvordan SOA skal løse problemene med integrasjon og forretningsorientering:

• Web service-standarder vil løse de tekniske integrasjonsproblemene (“WS-stjerne-påstanden”)
• Å sentralisere integrasjon via ett knutepunkt vil løse de organisasjonsmessige utfordringene rundt integrasjon (“ESB-påstanden”)
• Å modellere funksjonalitet som en arbeidsflyt mellom tjenester vil gi oss bedre forretningsorientering (“BPM-påstanden, del 1″)
• Å kunne restrukturere arbeidsflyten mellom tjenestene vil gi oss en en smidig forretningslogikk (“BPM-påstanden, del 2″)

Read the rest of this entry »