2Paths Team Blog

The day started curiously as I was waiting for the 57, where I came across a quaint wannabe bus driver from Somalia. Naturally, I asked him why he had opted for life over here in Canada. “Here the supermarkets don’t sell bullets side by side with the vegetables”, was his honest reply. I never did get his name, but he did manage to leave an impression.

Anyhow, arriving at the square dusky-coloured Delta hotel, Barbie presented me with my name tag for this year’s No Fluff Just Stuff Western Canada Software Symposium. I inquired if it wasn’t necessary to register, at which she bluntly retaliated, “Are you lying about having paid? Well, you look like a honest guy, but nice of you to ask!”. Charming.

Scott Davis kicked off the show, and before we knew it, he had bewildered us Java techies with some Groovy magic. As his finale, he had Grails spooning off a fully-CRUD enabled web app in a split-second jiffy. Admittedly Grails does hit that sweet spot, which no doubt will have me succumbing to its allure, yet one growing pet peeve I have with it is that it does come with shackles of its own. For one, it imposes its own build tool, namely gant. But since, for better or for worse, most of us use maven as our build tool of choice, i would cast an early warning to the coders behind Grails - choice is key.

Thus, and surprisingly so, the much talked about shiny new toy didn’t earn my first merit, instead the honour went to a talk on Agile testing strategies. Jared, a likable confectionery-throwing speaker, not only talked a good talk, he also walked the walk. Test Driven Development (TDD) is a notion that has been much paraded about on the Agile front, yet until now I have remained skeptical. Until now, I didn’t fully take on board what its potential benefits could be. Enlightened, I now realize that by using TDD this has the knock on effect of it driving the design, hence driving the developer in keeping the code testable, which in turn keeps it simple, modular, and loosely-coupled. Genius.

And with that, I will finish off Day 1 with the quote of the day:
“I can’t fix stupid” ~Jared Richardson’s take on dumb developers.

It seems that just a breath ago you hung, suspended sideways on the playground swing, in weightless sun, to peer across the bar to distant shady green.

And now, blood-draining rush, too fast, too soon, the skin drags down your face in hurtle past the ground toward that shadowed gloom.

This moment marks the midpoint, just, between the light and dark. The rush bequiles that end is nigh, but pull on through, and thrust: feel the arc curve through the dusk and back again, toward the light once more.

When you’re on the stage and the curtain rises, it is easy to appreciate the value of getting it right the first time. If you’re well-prepared and on your game, you can be a star, if not, you’re a soon-forgotten nobody.

Early software development embraced the “get it right the first time” approach, following general engineering practices, but for many reasons, this approach did not always proven to be effective. There are obvious benefits to building a road right the first time, and extensive preparation is rewarded. The software development landscape is neither so well-defined nor as stable as the physical landscape upon which highways are built. Also, the cost of revising a road after it is built is likely higher than for rewriting code.

Nevertheless, it remains an intuitively attractive approach to attempt to get a job right the first time. “Measure twice, cut once” remains a popular expression. It requires a mind shift to feel comfortable embarking on a project knowing it will need to be revised, especially when there are pressing budget and timeline issues.

It helps to consider contexts in which an exploratory, iterative approach is favoured. Agile software development has something in common with the other side of the stage: appreciating the performing arts. When presented with a new play or piece of music, it is a vast unknown to the audience, just as the business problem is an unknown to the software development team. Of course, in both cases, the audience and development team will be drawing on whatever knowledge they have of the work in front of them, whether previous works by the same author, or what is known of the business or similar businesses.

On first listening, the audience can only follow the plot — every new development is seen as arising from what precedes it. The audience should not try to comprehend it all. The first time, the audience should just go along for the ride, with the goal of getting a general idea of the work. On the next experience, the audience will know the outline of the story, and can begin to appreciate some of the nuances: how are they being manipulated to expect one thing, when another thing is really happening? how are themes and resonances being developed below the surface? Shakespeare and Beethoven are not fully comprehended after many, many listens, and as author Jorge Luis Borges said, “Only rereading counts”.

With software development, we acknowledge that the business problem is difficult to understand and constantly shifting, impossible to grasp on the first pass. By the time one spends enough preliminary effort to get it right, the business has changed and the solution is wrong after all. We have found that the most effective approach, in many cases, is to get a quick overview of the problem, then lay out a simplified solution. By going through this exercise, knowing it will not be completely right, both the company and the developers gain insight from the exercise, and are in an excellent position to build on their experience.

Having functional software to explore, the company will have much incisive feedback regarding how that software does not serve their needs, as well as how it does. Through subsequent iterations, client input from direct experience is quickly applied back to the software by 2Paths. The same issues will be revisited, and based on the evolving software, the solutions gain depth and sureness. We efficiently build up a store of experience from not getting it right, in order to confidently converge on an effective solution for the business when the curtain finally does go up.

Check out the art from the “2007 World Latte Art Champion, Jack Hanna”

Link

We can aspire to greatness