This Norwegian language blog post summarizes my talk at Oslo Agile Meetup in the beginning of October. Jeg tror ingen egentlig vet hvordan de skal få til bra utviklingsprosjektet. Selv når vi lykkes så er det veldig mye flaks. De fleste av oss tror vi kunne gjort mye bedre. For de fleste av oss holder tilstanden til kodebasen oss tilbake fra det vi synes vi burde ha fått til. Vi har lært en del ting om hva som i teorien skal være løsning:

When your heroes start acting weird, you reexamine their influence on your life. I’ve long been learning, demonstrating and teaching clean code through TDD, patterns and so on. But when I look back, I am now worried that the ideas negatively influence my life and my work and that of others. Many who know me consider me an exceptionally skilled programmer. I got that way because I have often spent my evenings practicing programming techniques and technologies.

I was humbled and encouraged to learn that I was nominated for Nordic Startup Awards category of Developer Hero for my contributions to the developer community. You can vote for me or one of the other great candidates here. For the last ten years, I have felt that the main pain points of the software development world could be fixed by empowering and inspiring those who do the work. From my perspective, I have focused on the developers.

I have an amazing time machine that lets me think better about projects. This is part 3 in a series of blog posts exploring the use of a time machine. In order to get a handle on how to build a feature for your next iteration, take a trip with your time machine to the future to watch how the feature will be demonstrated. It’s often hard for developers to focus on exactly what tasks needs to be performed in order to build a new feature.

One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others. When our team was formed we decided to pair program and rotate partners every day. I had lots of fun programming with Milina, Asanka, Manoj and Chamath, but my favorite session was the one I had with Sankalpa.

I’ve started using an approach for software project estimation that so far is proving to be fairly transparent, quick and reliable. I’ve observed that within a reasonable degree of variation, most teams seems to complete about one “user-relevant task” per developer per calendar week. There are so many theoretical holes in my argument that there’s no point trying to cover them all. The funny thing is that it seems to work fairly well in practice.

Less Overproduction (of unused functions in interface between team members) Less Waiting (for the only person who knows a particular area) Less Motion (as everyone gets more skilled) Fewer Defects (because two pair of eyes see better than one) Less Over-processing (from duplicate responsibility) Less Inventory (as team works on focused set of features and tasks) Less Transportation (handoffs inside a story) Less Underused talent (as everyone gets to share their skills)

I’ve previously talked about the idea of shifting from estimates to budgets. The fundamental point of this article is that it’s more useful to control costs than to predict costs. The problem of this argument is whether it’s possible to develop software in that way. How will the relationship between the developer (or supplier organization) and the customer (or the customer organization) have to change? Is this a chance we’re able to make?

“Show frequently what you’ve done to someone who cares” Are you working in the way you are because it’s a good idea, or just because someone told you to do it? I increasingly hear experienced professionals at Agile conference bemoan the blind adherence to the techniques of Scrum without understanding the principles and values that make it work. I also encounter many software professionals who are overwhelmed by the amount of things that they are asked to do.

In order to smoke test web applications, I like to run-to-end smoke tests that start the web server and drives a web browser to interact with the application. Here is how this may look: public class BookingWebTest { private DataSource dataSource; private Server server; @Before public void createServer() throws Exception { dataSource = DataSources.getTestDataSource(); new EnvEntry("jdbc/applicationDs", dataSource); server = new Server(0); server.setHandler(new WebAppContext("src/main/webapp", "/test")); server.start(); } private final WebDriver browser = new HtmlUnitDriver(); @Test public void shouldShowCreatedBookings() throws Exception { PersonDao personDao = new PersonDao(dataSource); Person person = new Person(); person.

Many sources of stress on projects come from forgetting what our roles are. Scrum championed a simple set of roles with the development team, the Scrum Master, and the Product Owner. The first problem is the people affected by agile projects who fall into any of these categories, many of which are important. The second problem comes from forgetting that the only roles with authority, the Scrum Master and the Product Owner are the least important people on the whole project.

As I’m working with smaller and more agile projects, I’m increasingly seeing the classic way that Scrum is executed as more of an impediment to agility than a helper. This is especially the case when it comes to the classic Sprint Planning as described in [the Scrum Guide](http://www.scrum.org/Portals/0/Documents/Scrum Guides/Scrum_Guide.pdf): “For example, two-week Sprints have four-hour Sprint Planning Meetings” In the Sprint Planning Meeting part 1: “Development Team works to forecast the functionality that will be developed during the Sprint.

There are only so many ways to test that your persistence layer is implemented correctly or that you’re using an ORM correctly. Here’s my canonical tests for a repository (Java-version): import static org.fest.assertions.api.Assertions.*; public class PersonRepositoryTest { private PersonRepository repository; // TODO < == you must initialize this @Test public void shouldSaveAllProperties() { Person person = samplePerson(); repository.save(person); // TODO: Make sure your repository flushes! assertThat(repository.find(person.getId()) .isNotSameAs(person) .isEqualTo(person) .isEqualsToByComparingFields(person); } @Test public void shouldFindByCaseInsensitiveSubstringOfName() { Person matching = samplePerson(); Person nonMatching = samplePerson(); matching.

After having worked with Scrum for a number of years, I still witness sprint reviews where the team’s demonstration of the product is confusing and the value produced in the sprint is unclear. The demo may consist of just a bunch of different functions and screens without any meaning. Or maybe the team is just talking about what happens behind the curtains in the database. Or maybe the demo just doesn’t display the value that the team was supposed to give to the stakeholders.

When a software architect gets a good idea or learns something new, he has a problem. The main job of the architect is to ensure that the right information in present inside the heads of the people who should build the application. Every new piece of information in the architect’s head represents a broader gap between his brain and that of the rest of the team. The classical ways of adressing this gap is for the architect to write huge documents or sets of wiki pages.

Do you ever feel it’s hard to get real progress in a sprint towards the business goal? Do you feel the feedback from a iteration picks on all the details you didn’t mean to cover this sprint? Do you feel like sprint planning meetings are dragging out? Then a Rainbow Sprint Plan may be for you. Here is an example of a Rainbow Sprint plan: A customer wants cheap vacations The customer signs up for daily or weekly notifications of special flight offers Periodically the System checks which customers should get notifications The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email The customer accepts the offer via SMS The System books the tickets on behalf of the customer The system confirms the booking by sending an SMS to the customer The customer can at any point see their active offers and accepted offers on the system website The customer enjoys a cheap vacation!

I’m working on this idea, and I don’t know if it appeals to you guys. I’d like your input on whether this is something to explore further. Here’s the deal: I’ve encountered teams who, when working with SOA technologies have been dragged into the mud by the sheer complexity of their tools. I’ve only seen this in Java, but I’ve heard from some C# developers that they recognize the phenomenon there as well.

An “Agile” project is one that actively seeks to incorporate changes as the project progresses, rather than assuming that the plans from the beginning of the project will work for the whole project duration. Not all organizations want to adopt “agile” as their project metaphor. And some organizations that do adopt methods such as Scrum do it without becoming as “agile” as Scrum promises. Instead of criticizing these organizations of “agile heresy”, I would instead like to offer some useful experience from Scrum, even if the word “agile” doesn’t appeal to you.

I hate giving promises for things I can’t control. I can promise that I will attend a party or that I will set aside time to help you with your problem. I cannot promise that the party will be fun or that your problem will be solved. Giving promises on effort is honest, giving promises on outcomes is dishonest. A team that commits to an estimate is promising something they cannot control.

As a user, I can add social security number, so patient logs have social security numbers As a developer, how would you react if you were given this user story? Would you throw it back in the face of the product owner, or would you try and understand it? How about the following dialogue? Developer: “What are we hoping to achieve with this story?” Customer: “We hope that the patient logs will have social security numbers.

Do you know how to apply coding practices the technology stack that you use on a daily basis? Do you know how the technology stack works? For many programmers, it’s easy enough to use test-driven development with a trivial example, but it can be very hard to know how to apply it to the problems you face every day in your job. Java web+database applications are usually filled to the brim with technologies.

I recently attended the XP Days Ukraine conference in a rainy, but beautiful and Christmas-decorated Kiev. I conducted a coding dojo and gave a talk where I demonstrated pair programming live together with Dima Mindra. After the talk, I got a few questions about how to run a Coding Dojo. This article is meant as a guide to anyone wanting to start up a Coding Dojo, whether it’s in Kiev (Mikail/Aleksey), in Odessa (I’m looking at you, Dima!

The next half year, I’m scheduled to give the talk “Experience Agile Programming” in Kiev, Gothenburg and Riga. In the presentation, I pair with a local developer and show a coding kata in Java, Ruby or CoffeeScript. After the presentation, I engage the audience in a discussion of what they saw, when they would use it, etc. I might also show a few more programming tricks if time permits and the audience requests it.

Instead of using Scrum, maybe we should use MyScrum. It’s like Scrum, with the stuff added that you think will super charge your MyScrum. This is my MyScrum: I want to measure velocity every week I want to demostrate the product with a cadence that makes sure users show up to the demo I don’t want to have story point estimates, I want to have story point budgets I want the product owner, not the team, to own the budget/estimate (but they team may veto) I don’t want commitments or forecasts from the team, I want measured historical progress I want to plan per story, not per sprint I want the developers who will develop a story to follow it (or pass the baton to other developers) from detailing to deployment.

The term Extreme Programming (XP) was coined in the nineties. Originally, it described a set of practices that have mostly been widely adopted today. Among these practices were continuous integration, test-driven development, user stories and frequent releases. These practices are hardly radical or extreme today. So what does “extreme programming” mean now? To me, the idea behind Extreme Programming can be summed up as follows: What would happen if we take what we know works, and do it to degree that seems at first unreasonable?

On larger projects, I’ve always ended up resorting to writing down a lot of detailed specifications, many of which are wrong, irrelevant or we might not be ready to answer them yet. On small projects, the dialogue between the customer and the developers can flow easy, and good things happen. The quick analysis Developer: … so we’re going to complete the current task tomorrow or the day after. Could we discuss what to do next before you’re off to your next meeting?

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I have written a few words about the dojo part of the exercise in a previous blogpost. After “classical” TDD-training, I decided to try something different and gave the group a competition to play with: Extreme startup, a workshop with software created by @rchatley and @mattwynne. The workshop was a huge success and I’m hoping to repeat it soon.

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I chose a format that let people work more independently rather than the classical style of “lots of people passing the keyboard around and looking on the code on a projector”. The result was an informal, competitive and engaged workshop where people continued playing with the exercise long after the official program was over.

This blog post is a summary of my lightning talk at XP2011 I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box.

Teams gather around task boards to plan their day. If the conversation and the task board match, we stay on topic and we understand what the rest of the team talks about. The last month, my project has redesigned the task board with this in mind. Here is a picture of our task board as it looked a few weeks ago: Each column represents a day. The top swimline represents testing tasks, the second swim line represents development tasks, and the bottom represents outside influences.

One of best ways to get the full effect of pair programming is if everyone programs with everyone else. This maximizes learning in the team. Here are three simple tricks we’ve found useful to get the pair programming to flow better. Magnets: Getting away from task ownership is essential to get pair programming to work. Instead of writing names on the cards that represents the tasks the team is working on, we place magnets with pictures of the team members on top of the tasks on our task board.

I’m getting a little fed up with descriptions of project development lifecycles starting with waterfall, and then describing iterative and agile development in waterfall terms. What happens if we start on the other side? Project development lifecycles Agile: The project creates a roadmap for a year or two, commits to the scope a delivery in a few weeks to a few months, adapts their commitment as they learn more and irons out the details of each task just prior to when it’s performed.

What do you do if you want to have a reliable system? You make sure you have redundancy: More than one component can do a certain job. You back up you valuable data to a separate system. You have two servers to provide your critical service, in case on fails. Yet, many projects have no plan for the inevitable absence of people with critical knowledge. We practice pair programming to get redundancy.

When I started pair programming daily, it changed my life and my projects for the better. I often point to pair programming as one of the most influential possible interventions on any projects. Very often, an audience member with a healthy degree skepticism will inquire about the research into pair programming. Sadly, the practice of software engineering research has not come very far in this area, so the questioner is left unsatisfied.

“Refactoring” is the practice of “improving the design of existing code without changing its behavior”. It’s an essential part of software maintenance. Done well, refactoring will make sure your code base is easy to maintain. Done poorly, refactoring will lead you into a dangerous swamp where you’ll be stuck forever. Good: In order to really get the benefit from refactoring, I think we have to do it all the time. I resolve to always leave a code file in a state where I could be satisfied if I never got to improve it in the future.

I’ve published a Norwegian language article titled: “Min supre produkteier” (“My excellent product owner”) at the company blog for Steria Norway. Go check it out if you understand Norwegian!

The more I code, the more I’ve learned to appreciate keeping the code clean even during complex refactorings. By “clean”, I mean that the code always compiles and the test always run. I often find myself in a situation where I have a method call that’s starting to accumulate parameters. Something like this: showPersonCreateForm(writer, firstName, firstNameErrorMessage, lastName, lastNameErrorMessage,....); After three or four parameters, the need to refactor is starting to become evident.

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!

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.

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.

Pair programming and test-driven development are some of the practices that are most often talked about and least often actually understood. So I’ve decided to undertake the task to teach myself to program a simple, yet realistic problem with a pair programming partner. The goal is to create an entertaining and realistic performance that portrays what it feels like to work like this. I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session.

According to Wikipedia, stenography or shorthand is “is an abbreviated symbolic writing method that increases speed or brevity of writing as compared to a normal method of writing a language”. Just as a stenographer learns to take down information really fast, a good programmer can learn to write code really fast by taking advantage of his or her tools. In this post I’ll show you my secret code stenography tricks.

Everyone has heard horror stories about pointy-haired-bosses counting lines of source code to track the progress of a project. We roll our eyes and laugh at their stupidity. But before you laugh too much, you might want to find out whether you’re really any better. Most of what software projects measure are not things we care about. Not things we really care about. Do you really care about the number of coding standard violations in your code?

Smidig 2010: Norges største smidige konferanse Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort! Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

“Design” is a verb, not a noun. If I want to create a good program, studying the process of getting there is much more important than the resulting software. This is why I use coding katas as a form of study. I find an interesting problem problem and then solve the same problem over and over again. In this blog post, I will focus on six principles of software design. I will illustrate each with a screencast from a kata.

My colleague Thomas sent me a very interesting link about attempts to solve Sudoku using test-driven development. The article, somewhat unfairly, pits Ron Jeffries’ explorations of Sudoku using test-driven development against Peter Norvig’s “design driven” approach. I found both attempts lacking. However, while Ron Jeffries freely admitted that he didn’t even know the rules of Sudoku when he started, both Norvig himself and his readers fawn over his solution. I didn’t find it very understandable.

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.

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:

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.

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.

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.

At ØreDev I ran into Lasse Koskela. We started talking about estimation techniques, and we both felt that the dominant estimation technique of relative estimation with planning poker has been unchallenged for a very long time. We found ourselves wondering what the next big idea about estimation will be. After throwing a couple of ideas back and forth, we decided to invite to a workshop comparing a few estimation techniques. We decided to call the workshop “The Malmö Experiment.

I’m working on a collection of patterns for early releases with Niklas Bjørnerstedt. Here are some of my thoughts based on this work. In a few different projects, I’ve noticed that the idea of “where are we going” seems to go though a familiar pattern: “The old system is the requirement document, just make the new one do the same things”. After a while, someone will realize that it’s rather pointless to replace a system with a new one that does the same thing, which leads to… “Analyze the business processes and make the new system automate all decisions that a human used to make.

This Norwegian language article introduces a short two-page guide I’ve written to explain Scrum to people who’ve only just heard of it. I samarbeid med våre dyktige redaksjonelle medarbeidere på Steria, har jeg forfattet en “3 minutters guide” til Scrum. Denne tar for seg spørsmålene som “hva er egentlig Scrum”. [caption id="" align=“alignnone” width=“360” caption=“Dette er Scrum”][/caption] 3-minutterguidene kan lastes ned fra Sterias hjemmesider. Jeg planlegger å følge opp denne guiden med en guide som beskriver hva som skal til for å faktisk lykkes med Scrum.

Every Scrum-team should use their taskboard to support their particular way of working. I’d like to share the way we use our taskboard at my current project for your inspiration. [caption id=“attachment_447” width=“300” caption=“Colored ink, paper and makers support team process”][/caption] When I started my current project I went to pick up sticky notes and marker pens for the taskboard. I grabbed, more or less at random three colors of notes (red, green, yellow), four colors of pens (black, red, blue, green) and five color sticky bookmarks (yellow, green, blue, orange, red).

What will the daily experience of software development look like, say, five years from now? Have our current processes reached their peak, or will the world continue to change? Alan Kay said “the easiest way to predict the future is to invent it.” Here are some ideas of the future I want to invent: I hope it will be dramatically better than what we currently do. [caption id="" align=“alignright” width=“240” caption=“Steel pipes (by monkeyc.

This is a Norwegian language copy of an article I published with Niklas Bjørnerstedt in the Norwegian computing magazine ComputerWorld Studier som utgir seg for å være vitenskapelig utført viser seg stadig å ikke tåle nærmere granskning. Kommersielle tenkesmier tar mange snarveier i kampen om å få frem oppsiktsvekkende resultater. Forskeren Magne Jørgensen har gjennom årene bidratt til å “avsløre” flere tvilsomme studier og dermed bidratt til å heve den vitenskapelige standarden innenfor systemutvikling.

This blogpost is a Norwegian language tribute to one of my home city’s great poets Med takk til Joachim Nielsen Ta en titt inn på skjermen din æ’kke testen grønn Det var mye værre her om da’n da var alle tester røde Skulle vært her i forrige uke, da hadde byggserver’n stopp Alt jeg tenker på er test og kode og bygg og mat hver bidige dag Alt kan refaktoreres, alt kan leveres Alt kan refaktoreres, og ingen ting blir bedre

In this second podcast in the Oslo Developer Conversation series, I talk with Robert Martin about FitNesse. We discuss the origins of FitNesse and it’s relationship with Fit, the relationship between acceptance tests in FitNesse and unit tests and the new Slim-tables in FitNesse. See the (English language) podcast at ProgramUtvikling’s site. Comments: jhannes - May 26, 2009 In the PodCast, Bob mentions Parnas tables as an inspiration for FitNesse table structures.

Doing the Code Dojo at Oslo XP meetup last Monday, I realized a new concept that I’ve been using unconsciously for a while: I only add to the structure of my system when I have a test that cannot be satisfied by the current design. The rules of test-driven development tells me to wait to create a more advanced design until I have a reason to do so. And that reason should be a failing test.

Agile development is easy to understand and hard to do. One of the hardest things to do is to base plans and actions on value instead of effort. An article by Alistair Cockburn includes a story that illustrates the point: A boy is behind on his German language home work. He now has to read ten stories and answer a set of question for each. He will be graded on the number of correct answers.

My friends at ProgramUtvikling just published the first PodCast in the series Oslo Developer Conversations. In this PodCast, yours truly interviews Uncle Bob about software craftsmanship. The podcast is still only available as video, but audio will come shortly. I had a great time doing this interview and I’m particularly happy that we managed to have a good combination of a technical discussion and an informal discussion. I’m looking forward to doing lots more of these in the future.

The hard choice between duplication, paralysis and chaos A common programmer credo is “Don’t Repeat Yourself” (Pragmatic Programmer) or “Once and only once” (Extreme Programming). Like all credos, we risk following it even when it is not appropriate. The larger truth is that we have choice between three evils: We can duplicate our code, thus duplicating effort, understanding and being forced to hunt down twice. We can share code and affect everyone who shares the code every time we change to code to better fit our needs.

Top five signs that you might not be working on an agile project: Your iterations do not produce anything that could be put into production You’re not testing your work You tasks are called “code the UI for the foo”, “update the bar component” and “test the work done in the previous iteration” Your iterations are called “specification”, “testing”, and “preproduction” And the top sign that you might not be working on an agile project: You might not be working on an agile project if your iterations are three months long Happy Holidays, Merry Christmas and Happy Monkey, everybody.

The Norwegian computing association has released guidelines for contracts regarding agile projects. Wednesday, November 26th I will be part of a panel debating this work and the combination of agile and contracts. This Norwegian language blog post contains my introductory remarks for the debate. Kom på debatten på Oslo Lean Meetup på onsdag og delta på debatten! Jeg er ikke en prosjektleder, en advokat eller en politikker, så jeg kan ikke si så mye om hva som må være med i en slik kontrakt.

Agile software development has learned about informative workplaces and stop-the-line quality management from lean manufacturing systems. Here are my implementations of it at my last project: All is well This video shows how our project looked when all is well. The large green light in the front shows the status of our build server. The green flashing lights show the status of our staging and production server. For the production server, the frequency of green blinks indicates the load of the system for the last 10 minutes relative in % to highest load ever observed.

This is a rough Norwegian language translation of the article JKE Day 1: Toyota Kyushu - The Manufacturing Ballet by Kevin Meyer (improvements on the language are very welcome, comments on the contents should go to Kevin). The reproduction has been authorized by the author. Unlike the rest of my site, this article is not available under creative commons license. Jeg kom over en artikkel som demonstrerte hvor bemerkelsesverdig lean production system kan være.

The Norwegian Agile User Group conference, Smidig 2008 was on Thursday and Friday. Both days started with three hour sessions of Lightning Talks, followed by three hours of open space work groups after lunch. We have been very happy with the format. The lightning talks give people food for thought. The best lightning talks are formulated around a provoking hypothesis. Kai Gilb talked about how we should focus on value instead of function.

It’s been a while since I promised to write top five unit testing tips, so I guess I should better start writing #2. As with my first example this one is based on a real-life story. Your code is worth nothing if it can’t be tested. Change your code to make it more testable. In my last project, we used a pipes and filter architecture, with messages being passed forward through a chain of services.

I don’t normally post just a link to another blog, but More thinking about “Agile” vs “Waterfall” by Jason Yip is just too important. It the most well-argued, well-referenced, short post I’ve seen about the subject. Here’s a taste: Be careful about saying that Waterfall is more disciplined. The waterfall model is simple and structured but the “discipline” is in following prescribed steps as opposed to “discipline” in thinking. The second kind of discipline is by far the more important.

I’ve looked over some of my code lately, and found ways that I often improve my tests. I’m planning on writing a blog post for each of my five favorites. First out: Using the data storage. I upgraded our API for billing customers. I had a few compilation errors in my code, as the API had changed somewhat. After fixing these errors, I was left with a test that broke mysteriously with a MethodNotFoundException.

Looking back at my projects for the last two years, we’ve had a tremendous improvement in the way we’re working. There are many things that we have done to make it better, and I’m be hard pressed to pick just three things I’ve learned. After much consideration, my favorites are: Partial production; Whole team; Requirements = Tests. Partial production: Using real production data for production in various scenarios has been extremely helpful.

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.

Many people enjoy splitting testing up in a myriad of test types: Acceptance Tests, Functional Tests, Integration Tests, Performance Test, Technical Tests, Unit Tests. I have myself been guilty of such terminology as “embedded integration tests” and “requirement tests”. However, what unites the tests are more important than what divides them. The divisions are fuzzy, and they should be. All tests have but two purposes: To tell you if you’ve completed a new requirement, and to ensure that you haven’t broken something that worked.

Myopia: the inability to see distant objects as clearly as near objects. PreferredConsumer.com What makes a good statement? In my experience, a good statement is one that people will disagree with frequently. One of the internal quality auditors at my company has an excellent plaque in her office: “If you and I agreed all the time, one of us would be superfluous”. So, in the spirit of disharmony: Agile development is all about being myopic, that is, short-sighted.

Recently, there has been a discussion about code comments on the pragmatic programmer mailing list: “Should you comment or not? What should be commented?” The one point I haven’t seen expressed succinctly is the following: Given a finite amount of time and a codebase with some … issues (which codebase doesn’t have issues?) what is the most useful thing you could do with your time? How often is the answer “comment more”?

A is for Apple You may have already known that A is for Apple. But did you know that O is for O’Reilly? Check out what Google reports for single character queries. (From Ward Cunningham’s Weblog) [via Artima Weblogs]

This book talks about the role of a tester in an XP project. So it is about acceptance testing, not unit testing (see Test-Driven Development by Kent Beck for that). The long and short of it is that I would really like to run an XP project with people who have read, understand, and become excited about this book. My experience is that a project suffers from not having someone who’s job is 100% quality.

Test-Driven Development describes in detail this technique from Extreme Programming. In addition, the author spends some time teaching the reader a useful set of mental tools for writing better code. TDD is a very fast read, but it is full of useful information. If I wanted my developers to only read one small book about software development, this would be it. Note: The back of the book lists it as “Software Engineering/Testing”.

This is exactly the kind of thing I have been looking for in C#. I am still some ways away from having looked at it as thorough as I would like, but it looks very good. Basically: Attributes that are processed compile-time with any code you like. This is the basic building blocks for AOP.