In Let your examples flow, Dan North describes how “Don’t Repeat Yourself” (DRY) isn’t necessarily the most important guideline for tests. While I agree with his conclusions, I think the DRY principle is still extremely important for tests.
Print This Post
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.”
Print This Post
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?
Print This Post
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.
Print This Post
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?
Print This Post
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.
Print This Post
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å: Hele organisasjonen arbeider for de samme målene.
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:
Print This Post
In my last article, I showed how to implement authentication with Ruby on Rails. But security is about more than simple login. For many applications, we want to grant permission to manipulate a resource to a set of users. In this article, I will guide you though adding functionality so that users can modify the permissions for who gets to edit an article.
Print This Post
Three challenges for agile projects
When I join projects now, I want to challenge all the stakeholders to make three commitments:
Currently, much project is doing very well on simulated environment and pretty well when it comes to demos. We’re still struggling with delivery within 10 % of the business case.
How are your projects doing on this scale?
Print This Post
As my previous Norwegian language article turned out to be one of the all time top hit articles in my blog, I will continue to write a few articles in Norwegian. This one is on an idea on how to do reseach on the success of agile projects. Next week, I will return to another popular topic: Testing.
Under paneldebatten på Geilo-seminaret til Dataforeningen, satt Magne Jørgensen meg, Lars Arne Skår og Niklas Bjørnerstedt litt til veggs med et ganske enkelt spørsmål: Hvordan kan vi vite om smidige metoder virker? Perspektivet til Magne som forsker på utviklingsprosjekter fikk meg til å tenke på spørsmålet, men før jeg fikk kommet med et forslag til svar. Derfor skriver jeg det her i stedet.
Å forske på et spørsmål som “fungerer smidige metoder” er veldig vanskelig. Mitt håp er at noen i stedet vil ta et skritt tilbake og se om man kan få svart på det mer interessant spørsmålet: Er det en sammenheng mellom hyppig feedback og lønnsomme prosjekter?
Print This Post
Subscribe (atom)