I think the most succesful software development teams are those who are fostering a culture of constantly trying new things out.

We have all burned our fingers on new immature technology, applying tools that were not the right tools for the job, or doing something we found out later was just plain stupid. While it may be just to blame whatever idea or product we tried out, putting the blame on the concept of "trying out" is taking a step down a dangerous path as it will lead to blaming those who are "trying".

I once had a talk with a guy that said something like: "We tried using frameworks and it didn't work, so we don't do that anymore" -- That may be trying, but perhaps a pretty early judgment on something as generic as the concept of a framework (It really sounded like the word "framework" was becoming taboo in that company). If you stop trying new things out I guess that means you don't care about improvements. 

Recently I had a talk about experiences with Stored Procedures. Perhaps you tried using Stored Procedures to solve a particular problem and it didn't work out very well. Now, that doesn't necessarily make Stored Procedures something evil that should never be touched again. Or how about build scripts -- How do you know if MSBuild or NAnt is best for you if you haven't tried both?

When we reach software nirvana I think everyone is accepting that trial and error really is the only way to improve, and thus encourage it as an everyday activity.

By Sune Gynthersen

There seems to be some confusion regarding what is lean and what is agile software development. Sometimes they are treated as essentially the same and at other times some (agile people) think that lean is just another management fad, while agile is the real stuff. In my definition Lean is a management system, that under a set of principles has as its ultimate purpose to eliminate waste in all processes. For each different business a lean system will look different. For a large number (maybe the majority) of software developing organizations, agile methods, are examples of processes with inherently little waste. So they form a good starting point for a lean organisation. Below that is a set of engineering principles (test early, continuous integration etc), of which many came together in eXtreme Programming, but has been used by good developers and organizations for many years. These are the sound groundwork any lean organization should build upon.
Computerweekly had this interesting article on the topic yesterday.

By Bent Jensen

Overall Agile 2007 was a great opportunity to be updated on the newest development within the Agile community and meet the people doing  the groundwork
My version of the Conference had three themes:

• Large scale agile transitions.
• Distributed agile
• Lean thinking in software development

Whether these are the main themes for the industry also in the coming year, is hard to tell. I am though very sure they are not at all unsignificant, since so many papers and experience reports were about these topics

The two last days had a few very fun and rewarding moments. David Andersons informal presentation of his results from implementing a Kanban system in software development, was convincing and very, very interesting. I have followed David for some years, and he has come to lean at another route than e.g. Mary Poppendieck David is  one of the big names in the FDD community and has also been heavily inspired by Eli Goldratt ("The Goal") and his thoughts. His book "Agile Software Management" is basically an application of Goldratts thoughts to software development.

What David could show us, was two concrete examples on applying lean thinking, in the form of a kanban to a system - thus limiting the Work In Process (WIP) and very soon get impressive results.

The one example was from an outsourced IT department from Microsoft. They had terrible results and an enormous backlog of work to do. By applying the kanban system they managed to bring down lead time and over some time completely eliminate the backlog.

The other example was from David's current work at Corbis - where he using the same principles has been able to stabilize their software delivery.
You can read more about David and his work at http://www.agilemanagement.net

Friday morning. Mary Poppendieck and Kenjii Hiranabe were leading a Discovery session titled: "Learn Kaizen from Toyota with Mindmaps"
As a big time mindmap fan it was great to see yet another application of this tool. The highlights of the session was  2 videos showing lean applications in practice. The first was a video from Toyota Motor Company, showing the history of Jidoka, also called Autonomation ~ "To add human intelligence to machines". That kind of thinking started when Sakichi Toyoda invented the automated loom that would stop by itself when a thread broke. The second video was even more fascinating. It showed a student of  Taichii Ohno pupils coming  to a Sanyo plant to help them improve productiviy by setting up work-cells and eliminating waste. Seeing changes being executed in real time in the video, while Kenjii was simultaneously translating was a great experience.
The mindmap part of the discovery session was, that each group after the video, would  reflect and create group-mindmaps of what could be learned from the videos. Fun and good learning.

Kenjii Hiranabe has translated Mary Poppendiecks Lean Software Development and a number of other agile books. He has authored  books on software development and has recently written a book on using mindmaps in software development. He is CEO of a company which are providing a tool to combine mindmaps and UML diagrams. http://www.change-vision.com

Now it is time for one weeks vacation, and I intend to be very silent on this site.

By Bent Jensen

At my current project I was hired to make some Swing GUI talking to an EJB server. I was new to Swing GUI but I quickly began searching for a test framework fitted for testing them. I came across Fest (Fixtures for Easy Software Testing). Fest is a quite new project, so the API is still subject to some changes (its working towards a “fluent” style), but you can definitely get something out of the current version.

I came from a project where I used Selenium to make automated functional test of web sites, and in fact Fest and Selenium are quite alike in the way test are defined. Its mostly about finding controls like fields and buttons (or links) and then enter text into them or click on them, and off course assert on some attribute of the UI.

When using Selenium you often find yourself setting id attributes on e.g. the links to be able to find them in your test; in Fest you get the same testability of the GUI by setting names on the Swing components. That way you can find them in your test, and avoid basing your test on a specific position in a component hierarchy that are likely to change.

A test in Fest could look like this:

package fest;

import javax.swing.JDialog;
import javax.swing.JTable;

import junit.framework.Assert;
import junit.framework.TestCase;

import org.fest.swing.RobotFixture;
import org.fest.swing.fixture.FrameFixture;

public class FestTest extends TestCase
{
  private RobotFixture _robotFixture;
  private RecieverFrame _recieverFrame;

  private FrameFixture _recieverFrameFixture;
  private FrameFixture _senderFrameFixture;

  public void setUp()
      throws Exception
  {
    _robotFixture = RobotFixture.robotWithNewAwtHierarchy();
    _recieverFrame = new RecieverFrame();
    _recieverFrameFixture = new FrameFixture(_robotFixture,
        _recieverFrame);
    _recieverFrame.pack();

    /*
     * Make sender frame last, to be able to click on
     * buttons as it requires the frame to be in focus
     */
    SenderFrame senderFrame = new SenderFrame();
    _senderFrameFixture = new FrameFixture(_robotFixture,
        senderFrame);
    senderFrame.pack();
    _robotFixture.showWindow(senderFrame);
  }

  public void tearDown()
  {
    _robotFixture.cleanUp();
  }

  public void testSendMessageToReciever()
      throws Exception
  {
    /*
     * Verify that reciever is in a correct initial state
     */
    assertEquals("No message", _recieverFrameFixture
        .textBox("messageField").text());

    _senderFrameFixture.comboBox("forumSelector")
        .selectItemWithText("FestForum");
    _senderFrameFixture.button("foo").click();

    Thread.sleep(500);

    _recieverFrameFixture.textBox("messageField")
        .requireText("foo");

    /*
     * Example of finding a Swing component and asserting
     * directly on it
     */
    JTable messageTable = _robotFixture.finder()
        .findByType(JTable.class);
    assertEquals("Wrong number of messages", 1,
        messageTable.getRowCount());

    _senderFrameFixture.button("deleteAllMessages").click();

    Thread.sleep(500);

    assertEquals("No message", _recieverFrameFixture
        .textBox("messageField").text());
    assertEquals("Wrong number of messages", 0,
        messageTable.getRowCount());

    /*
     * This is a bit clumsy way to verify that no error
     * dialog is present, improvements are possible.
     */
    try
    {
      JDialog errorDialog = _robotFixture.finder()
          .findByType(JDialog.class);
      Assert
          .fail("Expected no dialog present found one '"
              + errorDialog.getTitle() + "'");
    }
    catch (Exception e)
    {
    }
  }
}

Notice the use of finders to get the components in the Swing GUI, you can choose to find a component by name or class, where the latter makes your test more fragile, I prefer the find-by-name where possible. And it is easy to make your own Matchers to suit your purpose.

A nice feature is that Fest fails if you try to click on a button that is not visible in the frame, verifying that your frame is big enough to contain all your buttons. To improve Fest one could make the assertion failures more informative, they tend to be “Expected false but was true” with little context from the test.

I am using Fest to test multiple Swing frames at a time that communicate together via JMS (Java Messaging) and this can easily be done with Fest. One of the challenges when testing such asynchronous behavior is that your test need to be sleep between invocation and assertion. This is by the way the same challenge you face when testing ajax'ified websites, because your test need to wait until the DOM has been updated by the ajax call.

Fest requires Java5 and can be used in JUnit3 or whatever newer test framework you are using.

Thanks to Alex Ruiz  for putting together Fest.

By Jesper Thaning

Agile is really growing up - I think that is one of the conclusions of what I have experienced the last two days.

Tuesday  Dave Thomas from Objectmentor gave a paper on Lean and Agile in the Large, where he told about his long time experience with large scale development - e.g. the Eclipse Project. To my pleasure I saw, that he actually found there was a set of distinct phases in (at least large scale) software development. Not phases like in a waterfall approach but still phases. He expressed it as: Build it 3 times. First time to understand it, second to get it right, and finally to produce it. This contrasts the more naive implementations of agile I've seen, where it appears that as long as we have a product backlog, we are ready to go, and can produce quality software in each iteration. This is the "Do it right first time" thinking that somehow slipped into some agile practices.

Mark Striebeck told about agile in Google, how challenging it can be to add process and standards, in a company that is completely bottom-up and has a dislike of process and structure. Clearly testing is an issue also at Google, and the Agile Grouplet and the Testing Grouplet (voluntary group of people that want to focus on a specific topic) has done a lot to motivate to better testing practices - for example the "Testing on the toilet"
initiative. Google seems to be a very special, and highly motivating place to work - much like Microsoft and Sun at their peak - the question is whether there will be a bill to pay one day for the lack of structure - or they will keep up and add just enough structure as they need it.

Wednesday had two interesting Experience reports:

Jay Packlick from Sabre Airline Solutions, told about an initiative to revive a tired XP-culture (we are now in a phase where XP teams can be a little old and run out of steam). To work with this problem they had created a Agile Maturity Roadmap, that they used to motivate and make teams more aware of potential for process improvement. It made a lot of sense and seemed to have been done in way that allowed teams to improve by themselves and not by a top-down approach. I belive this kind of model, can also be used by teams starting to adopt agile to guide their gradual improvement. The presentation can be found here. Maybe it will be a serious competitor to  CMMI ?

The next presentation was about CMMI and Scrum. Carsten Ruseng Jacobsen from Systematic, a Danish CMMI level 5 certified organization, had last year run a number of experiments with Lean Software Development, and had implemented Scrum and Early Automated Testing. Since CMMI level 5 requires a high number of measurements, they could provide data (audited naturally) that showed pretty Dramatic improvements in productivity. Overall they were able to reduce costs on projects with 50% with this initiative - and this was only  to be considered the beginning or their lean journey.

Finally Mary Poppendieck spoke about Lean Leadership for a large crowd of people. It was a highly inspiring event, where Mary took the audience on a tour in History, from Frederick Winslow Taylors worker hostile approach to efficiency, over Charles Allen who introduced a programme for training on the job, that then was the foundation for the Training Within Industry programme that made US industry produce quality and high-volume during WW2, where a large amount of the workforce was abroad - to post World War Toyota. She showed how the concept of standard work is often misunderstood. At toyota Standardization is a means to change and improve, where other standardization programmes, seem to be focused on documentation and preventing change (e.g. ISO 9000). All in all a tour-de-force, that also provoked som agile dogmas about leadership and what kind of managers/leaders an organization really need to be successful. The Slides can be found here.

By Bent Jensen

The one paper that made my day yesterday at agile 2007 was the story about how Salesforce.com implemented agile.

Though a young company, they found themselves stuck in quite formal, waterfall oriented environment about a year ago. They had data that showed a gradual decline in productivity within teams, and longer and longer between releases. Not a good position for an on-demand company!

So they dediced to do a lean/agile initiative. They layed out a plan, that included experiments and pilot projects, in a gradual transition, but they decided, mainly because their CEO, in favour of an approach where everybody would go at the same time. That way they would get results faster and avoid dissonance between teams working the new way and teams still in the old world.

After a tough period, with resistance and struggles, they are now in a much sweeter spot, and have seen productivity rise, as well as being in a mode where they deliver 4 versions every year, and as they said "nobody even considers moving the deadline" which would be very uncommon in the past.

They themselves attributed the following to their success:

• Executive commitment
• A dedicated, cross-functional rollout team
• Focus on principles over mechanics
• Focus on automation
• Radical Transparency
• Leverage existing agile training
  
  

By Bent Jensen

Just arrived at my hotel in Washington DC, 18 hours since I left my home this morning. I had to fly Copenhagen-Stockholm-New York and then take the train to Washington DC - mainly because of my late purchase of tickets. A pretty long ride, but I managed to get a couple of hours sleep over the Atlantic and the train-ride was not bad. Occasionally a nice view and I had good company in another Agile 2007 Participant. He was VP of development in a software company, where they are having development spread out over most of the Globe (I do not think they had developers in Africa - but that was probably the only part of the world they did not have presence).
They were about to embrace Agile development, and we had a good chat about the challenges associated with coordination of several teams, in different locations and time-zones.

Tomorrow is the first day of the conference. Looking at the program it seems like it is going to be five interesting days, with lots of opportunity for learning and getting new perspectives and input.

The Conference is very popular this year and was sold out about a month ago. Hopefully it is a sign that Agile Development is becoming more mainstream, and not that we are just more and more consultants spreading trying to convince companies to work a better way

By Bent Jensen

How do you define quality in a software product? Few defects, no crashes, happy customers?

I believe that software quality really comes down to a few metrics. One is the amount of defects that makes it out of your lab. Another is your ability to maintain the product throughout its life cycle.

The bug metric is one I think most people in the software industry would agree on. So one might ask, why are we still creating them in high volume? Are we really at a point where it is not feasible to lower the rate at which we introduce bugs? I hardly think so. I think developers need a change of attitude towards bugs.

I like to tell myself that for every bug I pass down the "software assembly line" to the testers, I am responsible for the time they waste on finding, reproducing and reporting this bug. Or even worse, if they don't find it I will be responsible for wasting my customers' time.

In case the testers actually find my bug I am furthermore responsible for delaying the entire feature by introducing a need for a "bug fixing phase" where I will be debugging issues that should never have made it into the code.

If I introduce multiple bugs I will most likely also be responsible for wasting somebody else's time on prioritizing them.

I think most developers know that the total cost imposed by defects, rises exponentially over time. But what is really important, is that developers need to accept that they are the key to introducting less bugs, and managers need to accept that trying to push developers to deliver features faster is not going to lower the defect-introduction rate.

What do you think?

By Sune Gynthersen

When writing code I often spot some optimization opportunities, which I typically leave for later, just writing a small comment:
    // ToDo: Optimize this
I believe it is important to first get the behaviour right, and only consider detailed optmizations later.

Then one day the "optimization"-task becomes the top priority on my list, and then I am tempted to start by looking through all my recorded optimization opportunities to try and figure out which one will give me most performance for the least amount work. But then I think twice and instead look around for my favorite profiling tool. Because all the many times I have done this optimization exercise in the past the profiler have always found that the best optimization opportunity was one that I never even considered. So typically I end up never implementing any of the small optimization opportunities I have marked for myself. Maybe I should stop comforting my self by writing them, and just skip them...

I have used several commercial profiling tools in the past, and generally enjoy their ease of use: they can typically profile many different types of applications (web, libraries, command line) and they also typically have a "hot spot"-feature that immediately show you the way to interesting optimization opportunities. On Java I have been using OptimizeIt from Borland, and on the .NET platform I have used dotTrace from JetBrains.

However I recently discovered the open source profiler NProf. And while this tool does not have all the usability features of the commercial alternatives, the core profiling functionality is good enough for its inclusion in an open source tool chain.

NProf can only profile an executable, and I was using it for a web project. But fortunately I have a lot of tests, both unit tests and integration tests. And it didn't take long to write a small executable wrapper around one of my thorough integration tests and then firing up NProf on the resulting executable. And what did I see: that the most important optimization opportunity would be caching of configuration settings, cutting around 33% off the main call sequence of my application, something that had never occured to me...

To site Lord Kelvin: If you can't measure it, you can't improve it.

By Lars Thorup