Thinking Inside a Bigger Box

I’ve published a Norwegian language article titled: “Slik lykkes du med smidig utvikling” (“How to succeed with agile development”) at the company blog for Steria Norway. Go check it out if you understand Norwegian!

I though I’d do something different this time. Instead of describing something technical, I have recorded a five minute video that shows a very neat trick in Java: How to create a bit of code that wraps existing method calls to an object with any behavior you may desire.

This is nothing new, but I’ve noticed that not many developers know how to use it, so I hope this video may be useful:

If you would rather not include a library like cglib in your code and you don’t mind having to create an interface to create this sort of code, you can do the same with java.lang.reflect.Proxy.

As an architect for a team with a large number of people, I have a couple of problems:

• I often make decisions that turns out to be quite crappy.
• Even when I think I’ve written or drawn something that’s smart, it often turns out that it’s incomprehensible to everyone else

Luckily, I’ve noticed that most developers have characteristics that almost always counter these weaknesses:

• Most developers are pretty smart, especially when they’re trying to solve a specific problem.
• Most developers don’t read architecture documentation

So instead of trying to force the developers to read my crappy, poorly documented decisions, I decided to try to see what happened if I instead made use of the opportunities that the situation presented to me. Enter: The Great Wall of Architecture.

There are two rules for the Great Wall of Architecture:

1. Only the pictures on the Great Wall of Architecture are officially part of the system documentation.
2. The architect (me) cannot draw pictures to be included on the Great Wall of Architecture

As a playful addition, some of the developers have signed their work, just like we used to do in kindergarten. You can’t actually see it on the photo, but the hand writing on this diagram reads “made by Christin, 32 years old”.

My hope is that the Great Wall of Architecture will make the whole team feel they can use their strengths on the project. As more drawings come up every day, I’m optimistic with the result.

What if you had to report daily your progress on the tasks you’re programming in your project. Wait, you say: “I already do that in my daily standup meetings“. But if your standup meeting is anything like most standup meetings out there, you’ve got a serious blind spot.

What if I said that writing code doesn’t constitute progress. Code is effort, not value. In order to demonstrate value, you have to be able to show your progress to someone who doesn’t care about code. You have to demonstrate actual functionality, all the time.

In this blog post, I want to explore what happens when you demand that you plan and develop your project solely based on slices of functionality with business value, and what happens if you demand that these slices should become ever thinner: You know where you’re going, your customer knows how far you’ve come, and you’re always ready to ship.

Elephant Carpaccio

The more frequently you want to demonstrate progress, the more aggressive you have to be about how you break up your tasks. The most extreme version is perhaps the one demonstrated by Alistair Cockburn in his Elephant Carpaccio exercise (video). In it, the workshop participants are asked to develop a software system that does the following: “Register the unit price, quantity and US state of a purchase. Produce the total price, tax amount (state dependent) and discount (%-rate depends on total price). If there’s time, also produce reports of all sales per month and per state.”

The goal of the exercise is to divide this task into as many small feature slices as possible. In a 90 minute workshop, the teams each complete five iterations with a demo of new functionality at the end of each. In the video, you can hear teams frequently shout “Slice!” as they perform an internal demo of a functional slice several times in each iteration.

To complete the exercise, the participants develop a battle plan for how to deliver the smallest possible feature slice. For example: Input a sale, calculate and display the total price. “Slice!” Calculate the sales tax for a single state. “Slice!” Calculate the sales tax for three states. “Slice!” Introduce a table with tax rates to calculate the tax rate for any state. “Slice!” Give 3% discount on sales above $1000. “Slice!” And so on.

When you look to slice up the stories on your product backlog into tasks you should complete the next iteration, a few of the same approaches can be useful: If you need a screen to register some data, how about starting with registering just one field? “Slice!” And then register all fields, but without layout or validation. “Slice!” And then add validation. “Slice!” And then create a good layout. “Slice!”

If you split your next story into feature slices, your customer is probably going to be much more interested on your stand-up. If she learns of something she can test right after the stand-up meeting is done, she will probably feel much better about your progress as well.

If you create a carpaccio-style battle plan for how you want to solve the next story on your backlog, you will probably notice the old adage: “Plans are useless, but planning is essential.” Even though you have to rewrite your development battle plan, it will help you to know what to do and to always make progress towards a meaningful next goal post.

Finally, if the tasks you complete all mean progress towards the business goal of the project, you’re always ready to ship. Even if a vicious flu takes out the team for half an iteration, Christmas sneaks up on you as it always does, or, god forbid, the project runs out of money: You will have something you can ship.

One word of warning, though: Alistair Cockburn reports that during the Elephant Carpaccio exercise, people create crappy code. If you want to be able to deliver tomorrow as well as today, you must avoid the temptation of forgetting good engineering practices in order to ship something earlier. Start each slice with a bit of refactoring to get the code ready for a clean addition of functionality. Always write tests for your slices. And keep the code clean: You code may not do everything yet, but what it does do, it should do properly.

Are you ready to create a sprint plan that’s meaningful both to the developers and the product owner? How thin can you slice that elephant?

Ctrl-1 is the magic “do what I think” button in Eclipse. Whenever I press it, Eclipse seems to come up with something that’s helpful in the current context. In this blog post, I illustrate 10 things that Eclipse hide under the ctrl-1 keypress. This is a follow up on my post on Eclipse stenography.

I got some comments on my last post about Eclipse stenography about the animated gifs. I know this can be annoying, but I considered the alternative: To have you mouse-over or click a picture to animate it. I’m afraid that the pictures will sort of disappear from your attention if I do this. So I’ll try again. But this time, I’ll put the images below the fold. Click on to see the ten tips.

Read the rest of this entry »

When working on replacement projects, I often find I need to make minor changes to an existing database that is still in use by one of several other applications. Initially, it may seem like situation will force you to conform to the current database schema. But there are other options, even though they may not be for those who are faint of heart.

The general pattern when you want to evolve a database that is in use by legacy system, is to make sure that the legacy system sees the same data structure when it reads from or writes to the database. You can achieve this by using database views and “instead-of” triggers that will execute custom SQL code when insert, update or delete statements for the view are executed.

Here is an example: I was once given the challenge of centralizing a database that the customer currently installed one per site. The rub: I could not change the current application. And the new solution should treat some information as shared across the sites and some information as exclusive per site.

Here is how I solved the problem for an example table (let’s say CUSTOMER, with shared column BONUS_LEVEL and site-exclusive column LAST_VISIT):

1. I created the tables CUSTOMER_SHARED, with column BONUS_LEVEL, and CUSTOMER_SITE with columns SITE and LAST_VISIT
2. I populated the tables with the union of the current site databases.
3. I dropped the existing CUSTOMER table
4. I created a new CUSTOMER view as “SELECT … FROM customer_site INNER JOIN customer_shared WHERE customer_site.site = “. Now, the existing applications can see, but not update data.
5. I created “instead-of triggers” for insert, update and delete on customer. The existing applications can now update data as if nothing had changed.

Instead-of triggers is a very handy mechanism for views. They are executed when insert, update or delete statements are executed on the table. Some examples of such a triggers are:

CREATE OR REPLACE TRIGGER customer_UPD_TR
    INSTEAD OF UPDATE ON customer
FOR EACH ROW BEGIN
    UPDATE customer_site SET
         last_visit = :new.last_visit
    WHERE
         id = :new.id AND site = ;

    UPDATE customer_shared SET
         bonus_level = :new.bonus_level
    WHERE
         id = :new.id;
END;

CREATE OR REPLACE TRIGGER customer_DEL_TR
    INSTEAD OF DELETE ON customer
FOR EACH ROW BEGIN
    DELETE FROM customer_site
    WHERE
         id = :new.id AND site = ;

    DELETE FROM customer_shared
    WHERE not exists (
            SELECT * FROM customer_site
            WHERE customer_site.id = customer_shared.id);
END;

This sort of transformation is not without risk, and should be carefully tested and scripted to make sure it behaves the same when you test and when you deploy it.

A final word of warning: Both the function and the performance of instead-of triggers can depend a lot on your database vendor. Make sure you test a solution that use these features with a realistic amount of data.

I’d like to hear from readers who either found the SQL code intimidating or enlightening. I’d really like to know whether my readers are as frightened by SQL-code as non-programmers are by Java. ;-)

So remember: When you’re faced with a seemingly impossible task: Think inside a bigger box!

Sometimes I’m asked to write or speak about something with very little preparation. In these situations, I need a tool that can help me:

• Organize my thoughts quickly
• Prioritize the wheat before the chaff
• Maintain a coherent train of thought

I find a very useful structure for archiving this to be what I call “three-by-three”: Three main points with three subpoints each.

• Forcing myself to keep to a structure will make my thoughts flow more quickly. Coming up with three ideas isn’t hard, so I quickly get something down on paper. Limiting myself to three points forces me to cut out less important ideas, and when I can’t think of a third point at any one level, I can leave it blank, knowing that I will revisit it later
• Using a simple cookie cutter approach allows me to spend more time with the important preparations for the talk, or the important work with the article: iterating over the points I want to make. Nothing improves a talk faster than practice. Nothing improves an article faster than reading it out loud. Deliver early and deliver often.
• Finally, using a simple structure like three-by-thee allows me to clearly get my point across. If I’m writing an article, I can use bullet points or headlines for the points. If I give a talk, I can count down “the number of things I want to talk about” on my fingers. And with only three things to remember, the audience has an easier time following what I’m saying.

Of course, any form can be limiting, especially when you’ve worked with the material for a while. So I have some variations of the three-by-three structure that I often use:

• Three-plus-three-by-three-plus-three: The middle part of an argument needs to be the most substantial one, so I can fractally subdivide this further into three-by-three arguments.
• Three-times-three-plus-one: It’s often good to end on something different, a counterpoint of some sort. I often add a “zinger” to the end of a three-by-three talk
• Let it go: As I iterate over something that started out as a simple three-by-three structure, I often find that it no longer no longer lets me express what I want. Then, as with any rule that get in the way, I break it.

I use the three-by-three structure in my workshops on how to present, as an assignment for the workshop attendants. This greatly reduces the time before they can start practicing their talks and get to that really great, quick presentation.