If you want more information about The Agile Architect Pattern, see my previous post about it here at this site.

Guide the team to reduce technical debt before it becomes a problem.

Motivation

The nature of agile development is to deliver working software continuously. This means that the focus for all actors (Product Owner, Scrum Master and Team) is on the functionality delivered in each iteration. As a consequence, technical debt is considered okay and is likely to increase for each iteration completed. Often, this is allowed to go on until the debt has reached a level where the velocity of the team is starting to decline. After a while something has to be done, and the term Refactoring Sprint is introduced. A refactoring sprint is in this context an iteration totally devoted to paying off technical debt, thus no functionality is delivered for an entire iteration.

How it works

The Agile Architect Pattern prevents the scenario from the motivating example from happening by introducing an Agile Architect role. The Agile Architect can be seen both as a member of the team and as well as a stakeholder. This makes him/her able to both work with the team members, guiding them while trying to identify architectural issues as well as discussing requirements for future iterations with the technical resources from the client. While the team has a iteration-by-iteration time frame, the agile architect can see a few iterations ahead making sure the architectures evolves in a way that (hopefully) will not cause major problems ahead.

When to use it

The Agile Architect Pattern should be used in any project spanning over enough iterations likely to cause the technical debt large enough to slow the team down. It is important that the Agile Architect is comfortable both in the code domain acting as a guide for the team as well as on a higher level of abstraction to be able to interact with the client technical resources.

1. Coins are also money
   Project Coin contains a couple of nice language changes that will make life as a programmer much easier. See the project page for details.
2. Dynamic languages
   invokedynamic adds support for dynamically typed languages on the Java platform.
3. New File System API
   File operations have always been pain in Java, but with this new API most of the issues are solved. Manipulating symbolic links for example.
4. Concurrency
   The Fork/Join Framework provides a set of utilities you would benefit from when writing concurrent programs, giving the possibility for true parallelism on the Java platform.
   
5. Modularization
   A refactoring enabling the Java SE platform to be downloaded as required by the VM as needed. 
   
6. Enhancements
   A lot of enhancements regarding classloading, unicode, locale etc.
7. It’s new
   And new things are always more motivating to work with than old, at least in the context of programming languages.

To be honest this is not very much for a major version of a programming language, especially since it has gone nearly five years since the previous version. But it shows that Java is still alive after the whole Oracle story.

I think I have got it all up as it was now, with a few new features such as link to my google+ profile and the nice little +1 button below the posts. Next time I am definitely going to follow the recommendations of backing up the data…I think…

The main area of conflict or misunderstanding is usually around how to create a common architecture or framework (…ouch…) for the entire organization. Most managers and old school dinosaur architects seem to believe that this is best done in long meetings and by producing endless powerpoint presentations and documents containing every buzz word in the world.

I can not stress enough the importance of building an architecture from something that already has been proven to work. And to be able to do that, you as an architect have to get your hands dirty doing some actual coding. An architecture should always be communicated through code, not by slideware!

Since it is such a diverse conference, it is difficult to point out a single item that was the main trend at the conference. But if I should pick one thing, I guess it would be that most of the talks I attended more or less circled around the Get Real! theme of the conference. Hopefully this means that the industry is getting more mature. Don’t want to be a self-fulfilling pessimist, so it is just to be optimistic

See you there next year!

@Test
public void spaceFiller() {
   int l = 5;
   String result = MessageUtil.spaceFiller(5);
   if (result.length() == l) {
   } else {
      fail();
   }
}

When I came across the test code above I wondered who on Earth would write such a thing. The answer came shortly after when I had a look at the method it is testing…

/**
 * Space filler.
 * Creates a string filled with spaces of the wanted length
 *
 * @param length the length of the wanted string
 * @return the string
 */
public static String spaceFiller(int length){
   String s = "";
   for(int i=0; i < length; i++)
      s = s.concat(" ");
   return s;
}

The good thing is that they actually wrote a nice and clear JavaDoc explaining their own stupidity…

The only comforting thing about this is that as long as there are projects like this, there will be plenty of work for software consultants to clean up the mess. Just a pity that the first couple of weeks will be spent writing unit tests to be able to start refactoring the code. Good thing that writing unit tests are pretty fun and addicting, or to quote one of Kent Beck’s tweet earlier today “… tests are like potato chips”.