Thinking Inside a Bigger Box

Why and how to use Jetty in mission-critical production

This article is a summary of a seminar I had on the topic. If it seems like it's a continuation of an existing discussion that's because, to some extent, it is. If you haven't been discussing exchanging your app server, this article probably isn't very interesting to you.

By putting the application server inside my application instead of the other way around, I was able to leap tall buildings in a single bound.

What is the right iteration length?

When picking iteration length for an agile project, there are mainly two forces that you have to balance: The rate of learning is proportional with the number of iterations, rather than the length of the project. This means that shorter iterations help you get better faster. But each iteration has some overhead with sprint reviews, retrospectives and planning. You don't want this overhead to dominate the effort spent on the project. For some reason, most projects I've seen with little experience in iterative development prefer three week iterations. Personally, I prefer two week iterations. Here is the breakdown:

Three week iterations: After three months, you've spent about 7% of your time on iteration meetings. You've had 4 opportunities to improve.
Two week iterations: After three months, you've spent about 10% of your time on iteration meetings. You've had 6 opportunities to improve.
One week iterations: After three months, you've spent about 20% of your time on iteration meetings. You've had 12 opportunities to improve.

Going from 93% to 90% efficiency for a 50% increase in learning seems like a good deal. Going from 90% to 80% efficiency for a 100% increase in learning, not so much. These numbers are of course greatly simplified. You might also consider:

With shorter iterations, the planning time may go down. But this takes practice - it doesn't happen automatically.
With very short iterations, you may not have experienced enough to learn much from the retrospective. However, if you find that you do a timeline, and most of the things people remember happened the last week, it may not be because that's the only time something significant happened.
You may consider different frequencies for different ceremonies. For example, on my current project we want to have demos with our power users. But they have to travel far to visit us. So we only have a full demo every other four weeks. We plan every two weeks and have an internal review and retrospective every two weeks.

What's the right iteration length for your project?

Blogging with colleagues

If you wonder why this blog has been so quiet lately, it not (just) that I'm getting lazier. Together with several of my colleagues at Steria Norway, I've started up a blog at http://sterkblanding.no. "Sterk blanding" is Norwegian for "potent mix", and we hope that as representatives for several disciplines, we will be able to give a broad perspective on IT and management issues. I've not yet decided what posts to publish here and what posts to publish on Sterk Blanding. My present idea is that I'll publish most of my English articles here at Thinking inside a Bigger Box and Norwegian language articles at Sterk Blanding. But I can be persuaded to change my mind. For my Norwegian readers, enjoy my articles on Sterk Blanding:

Hvordan komme i gang med blogging: Some tips for people who're considering to write on a blog
Hemmligheten bak gode spesifikasjoner: How to change your tests from specifying behavior to specify intentions
"Det var dyrt"-øyeblikket: The sobering moment in my project when both I and my customer realized that the transparency of Scrum meant that we could see how much the project was really costing.
Hvordan endre en statisk klasse til en dynamisk singleton: A step by step guide to an important strategic level refactoring in legacy systems: Changing static calls to use a singleton that can be mocked.
Med Ram Yoga: Smidig brukervennlighet: Some practical tips on how to use agile software development and user centric design to complement each other

Using Eclipse Better

I've pair programmed the Java EE spike kata in Eclipse with a number of people, I've found that a number of keyboard short cuts and preference settings recur as useful new information. I've compiled the most popular ones in this article. The article is subject to change, but I won't change the number of shortcuts.

Top five shortcuts

There are some keyboard short cuts that everyone who uses Eclipse should know:

ctrl-1 (quick fix): You hopefully use this shortcut to get quick fix support for compiler errors and warnings. Did you know that you can also use it to assign parameters to new fields, rename variables, and invert if-statements and equals-checks? Learn to think of ctrl-1 as asking Eclipse "what can you do make the code better (or just different)?"
ctrl-space (complete): Again, you hopefully know that you can use ctrl-space to complete the name of variables and method names. But did you know that you can type "equa<ctrl-space>" in the class body and have Eclipse override the equals-method for you? Or that you can type "getNam<ctrl-space>" and have Eclipse create the whole implementation of a getter for name (if there's a name-field in the class). Or that you can type "Test<ctrl-space>" and have Eclipse fill in the Test code template. Think of ctrl-space as asking Eclipse "guess what I'm about to write"
ctrl-f6 (next editor): Use this to cycle between open files. It really should've been bound to ctrl-tab, but you can do this yourself.
f3 (go to definition): Place the cursor on a method call or variable usage and press f3 to go to it's definition.
ctrl-shift-t (open type): A nifty dialog to go to any class in your project. Did you know that typing PerCoT will take you to PersonControllerTest?

Top ten runner ups

Here are some eye-openers that people enjoy learning:

alt-ctrl-down (copy current line): Creates a new copy of the line under the cursor on the next line. Without wiping the clipboard! Try it while selecting several lines, too
alt-down (move current line): Moves the line under the cursor down one line. Works with alt-up, too. And with a number of lines selected. A quick way to move code around with the keyboard.
alt-shift-left (extend selection): Progressively selects a larger syntactic element in the editor. Hard to explain. Try it out!
ctrl-shift-m (static import): Replace a call to Assert.assertEquals with a static import of the org.junit.Assert.assertEquals and a call to assertEquals.
ctrl-F11 (rerun latest command): To run for example the same test again, you can usually press ctrl-f11. Sadly, a few years back the Eclipse team tried to improve this and failed. Fix it under Windows->Preferences, Run/Debug -> Launching. Change "Launch operation" to "Always launch previous".
f12 (activate editor): When you perform an operation where some other pane got the focus, use f12 to return to the editor again.
ctrl-N (new <something>): Create a new class, XML file or whatever. Be sure to use the filter
alt-shift-l (extract local variable): My favorite refactoring. Select an expression and press alt-shift-l to assign it to a local variable and replace all uses of the expression with that variable.
alt-shift-m (extract method): Your bread and butter refactoring to split up complex logic in understandable units.
alt-shift-i (inline method/inline variable): The inverse of both alt-shift-l and alt-shift-m. Together, these three refactorings let you resculpt your code while being certain that the behavior is unaltered.

Top three properties to change

When I sit down with new programmers, I almost always help them make the following changes in the preferences. Find the preferences under Window->Preferences:

Use ctrl-tab (and ctrl-shift-tab) to switch between open editors: Go to General->Keys, type in "next editor" in the filter. Select "Copy command" and type "ctrl-tab" in the Binding field. Do the same for "previous editor" and ctrl-shift-tab.
Type filter: Do you wonder why Eclipse can't understand that when you say List, you mean java.util.List, not org.hibernate.mapping.List or (ye gods!) java.awt.List. Well, you can make Eclipse understand. Put classes and packages you don't like under Java->Appearance->Type filters. If your project is like mine, putting org.hibernate.mapping.*, antlr.*, java.awt.List, and com.sun.* in the list makes List unique to java.util.List. Then "organize imports" and completion works as you want.
Static import favorites: Do you find yourself using static imports with the same few classes again and again? The preference Java->Editor->Content Assist->Favorites lets you list up classes which will have their static methods checked when you press ctrl-space to complete a method call. org.junit.Assert.* is a good first candidate.

Learning your tool

All IDEs are rich and powerful tools. Spending some time to learn a few new tricks is well worth the effort.

Getting started with pair programming

As it turns out, one of the least used practices of agile development is also one of the most powerful. Up into the start of last year, I only worked sporadically with pair programming. Last year, I was lucky enough to be part of a team that used pair programming all the time. Since I've experienced real pair programming, I never want to give it up. Pair programming offers benefits to many stakeholders:

As a developer, you will have more fun at work. You will get to know your colleagues better and experience flow practically the whole day. You will be tired by the end of the day, but you will also feel like you've accomplished good work.
The team will have a higher quality code base that everyone is comfortable with.
As an architect or team lead, you will have a good way to contribute even if you only have a little time before a meeting. You will also have a better chance to influence the rest of the team, instead of just issuing edicts that nobody follows.
As the project manager, you will have a more flexible team. If someone gets sick, goes on vacation or moves to another project, there won't be a big problem.
As the customer, you will get better quality code faster.

With these benefits in mind, why doesn't everybody pair program? Well, it is unfamiliar, a little scary, and exhausting when you start out. Most developers are not used to having other watch them code. Or to focus on the task at hand the whole day. Here are some techniques I've seen have effect for teams transitioning to pair programming:

Code dojos: Everyone on the team gets together and programs a sample program or a spike together. Two people sit at the keyboard, while the rest watch on a projector. Rotate pairs frequently. This lets everyone get comfortable with coding as a social activity.
Pair programming should be the norm, but allow for exceptions. If people only pair program occasionally, they end up not pair programming at all. If people are forced to pair program when they just need some time by themselves to think, they will not be happy pair programming.
The pair programming star: Write the names of the team members in a circle. Every time two people pair program, draw a line between their names. Keep the pair programming star in a visible location.
Facilities: The furniture can make it harder to get started pair programming. Consider using two mice, two keyboards and perhaps two monitors per PC to make it easier. Or use VNC for desktop sharing.
Give it time: Pair programming is exhausting when you first start doing it. It will take a while before people are comfortable with the new pace. But once they switch, they will never want to go back.

Resources

For more inspiration, see these presentations from the Smidig 2009 conference (in Norwegian):

Jøran Lillesand: Derre e itj smidi!: On why pair programming is the very foundation of successful agile projects
Ørjan Lillevik og Kari Røssland: Parprogrammering gir driv: On what it feels like to be on a team that adopts pair programming. From reluctance to joy.

My first katacast

After seeing some of the great examples of coders working on practiced problems on KataCasts, I decided to try make my own. I am not happy with the pacing of the video. I'm about a minute too early relative to the music. But I thought I'd post the video here, to see what you all think. Comments are welcome! I hope the video will demonstrate how to use refactoring effectively to drive the design of a program. I chose the FizzBuzz kata - that is, to generate a sequence of numbers where every number divisible by three is replaced by "fizz" and every number divisible by five is replaced by "five". The music changes to be more aggressive just as I induce a new requirement into the kata: The FizzBuzz generator should be programmable, so, in the kata, numbers divisible by two are replaced by "coconut" and numbers divisible by seven are replaced by "banana". Thanks to Emily Bache for the inspiration for the kata. Enjoy!

Fizz buzz code kata from Johannes Brodwall on Vimeo.

The video was made with IntelliJ IDEA Community Edition on Windows Vista (!) with BB FlashBack Express (free screen recorder), converted to AVI with Windows Media 1 codec and uploaded to Vimeo.

Observations from katas

Lately, I've been working on two code katas, that is, programming exercises that I repeat until the motions are secure in my muscle memory. The katas I've chosen are:

Java EE Spike: An application that stores People with names to a database and lets me search for them. I've repeated this pair programming with several different programmers.
Programmable Fizz Buzz: Create a sequence of numbers 1,2,fizz,4,buzz,fizz,... you know the one. And the twist: Make it programmable, so that for example numbers divisible by 7 should be replaced with "coconut".

I've learned a lot from repeating these exercises:

Using test-driven development it takes me longer to get to something that "should work in principle", but shorter to get to something that works correctly.
When refactoring to a new data structure, add the new structure while keeping the old one, make switching between them as simple as changing a single line. Delete the old when it works.
There's always an automated refactoring you still want to help you out. Extract Parameter Object was my big one.
Writing for example a method invocation and then using quickfix to have the IDE generate the method is the quickest way of writing code available to you.
After 8 iterations, the Java EE Spike takes me 80 minutes solo. Pair programming with another programmer who had practiced: 65 minutes. I don't know why!
Pair programming a moderately complex kata like the Java EE Spike is fun. It's also a good chance to discuss different roles of different tests.
There is a huge difference between a test that takes 3 seconds to run and one that takes 0.5 seconds when you're test driving. More surprisingly, there's a big difference between a test that takes 0.5 seconds and one that takes 0.01 seconds
If you think test-driven development is not for you or that it's bunk, you probably write really slow tests.

What are your latest coding observations?

Å trene på Java EE

For å bli bedre må man trene. For å bli bedre med avanserte ting, må man forstå de grunnleggende tingene bra. For å vite hvorfor man bruker avanserte verktøy, må man prøve å jobbe uten dem. Derfor har jeg de siste ukene trent mange ganger på å lage en veldig enkel webapplikasjon i Java. For hele applikasjonen har jeg startet med å skrive testene før koden som implementerer funksjonaliteten. Dersom du vil prøve deg på samme øvelse, inneholder denne artikkelen litt informasjon for å komme i gang. Start med koden under og følg feilmeldingene. Send en kommentar dersom du ikke kommer videre fra en feilmelding, så får vi en FAQ.

Oppgaven

Løs et så enkelt som mulig problem som involverer websider og database med så enkel teknologi om mulig. Oppgaven jeg har laget går ut på å opprette personer med fullt navn og søke etter personer basert på navnet deres. For å gjøre oppgaven så lite som mulig har jeg valgt å la personer kun ha ett informasjonsfelt: Fullt navn. Denne oppgaven tar cirka 2-3 timer uten øvelse og du kan få den ned i 60-90 minutter med trening. Du kan naturligvis velge en annen oppgave, men uansett hva du velger: Det er mer lærerikt å gjenta den samme oppgaven flere ganger enn å utføre en avansert oppgave. Når jeg utfører oppgaven er det viktigste jeg lærer meg å forstå feilmeldingene som guider meg gjennom utviklingen. Dersom du trenger hjelp til å komme til de første feilmeldingene kan du se resten av artikkelen.

Tips for databasemigreringer

En kollega spurte i dag om mine topp tips når det gjelder databaserefactorings. Her er mitt svar:

Ha en organisert struktur med at man gjennomfører navngitte migreringer (a la Ruby-on-Rails sine migrations eller dbdeploy). Typisk er det vanlig og velfungerende å navngi scripts med løpenummer (001, 002, ...) eller timestamp (20091124071300, ...) og ha en tabell i databasen som holder styr på hva som har blitt kjørt
Bruk views og materialiserte views for å støtte tilbakekompabilitet (NB: Oracle er veldig sterk på dette, andre databaser kan slite)
Om mulig, gjør hver migrering bakoverkompatibel på en versjon av programvaren. Dette er lettere å få til jo hyppigere du releaser programvaren
Skill endringer i skjema (for eksempel: legg på en kolonne) fra migrering av data (for eksempel: populere kolonnen). Feilene vil typisk ligge i #2 av disse, og den er lett å gjøre transaksjonell, mens skjemaendringer ikke er transaksjonelle i de fleste baser.

Har jeg dekket det viktigste da?

Why don’t we call our customers “clients”?

Lately I've been thinking a lot about how easy it is to lose sight of the goal of the project and instead focus on whatever means someone first thought was a good starting point when the project was first conceived of. And I think it all comes down to words. The first years I was working in this business, I didn't see any distinction between "the user" and "the customer". Once I started seeing the distinction, I started to understand that the person who is going to use the system we're developing is not the person who defines what the system should do and neither of these is usually the person that pays me to develop the system. So I starting distinguishing between the product owner, that is, the customer and the end user. But the product owner often calls the person I call "end user" his "customer". What's going on here? Let's check the dictionary:

CUSTOMER Main Entry: cus·tom·er Pronunciation: \ˈkəs-tə-mər\ Function: noun 1: one that purchases a commodity or service 2: an individual usually having some specified distinctive trait CLIENT Main Entry: cli·ent Pronunciation: \ˈklī-ənt\ Function: noun 1: one that is under the protection of another : dependent 2a: a person who engages the professional advice or services of another 2b: customer 2c: a person served by or utilizing the services of a social agency 2d: a computer in a network that uses the services (as access to files or shared peripherals) provided by a server

I've seen suppliers approach their work by asking for a specification of a product to deliver and then trying to deliver something to that specification for payment. The mental model is that of a customer going to the grocery story asking for "eight pounds of CRM software". My experience with organizations with this sort of mindset has always been unsatisfactory. On the other hand, I've seen suppliers approach their work as an agent of the organization that pays them. "Our job is to enable someone else do their job better." This totally changes the way an organization deals with this relationship. The word "customer" may not be conductive to this sort of thinking. Instead, we should think of ourselves as agents acting on behalf of a client. As an agent, your responsibility is to enable your client. This includes helping your client to find better means of reaching their goal. By the way, wikipedia defines the word "agent" as "a person who is authorized to act on behalf of another (called the Principal or client) to create a legal relationship with a Third Party". If the "third party" is the computer, then a good developer is an agent acting on their clients behalf in dealings with the computer software. Why doesn't the software industry use the word "client" instead of "customer"?