General

Views From a Speaker at JDD 2013

JDD 2013

I have just come home after spending three amazing days in Krakow as one of the speakers at the Java Developer Days Conference there. The organizers of this conference takes well care of their speakers and you feel welcome all the time. And I am sure the attendees feel the same.

Apart from my talk, my greatest achievement at the conference was to win a a signed copy of Practical API Design by implementing a simple application using bck2brwser. My contribution: Duke2Brwser. Hope this may inspire you to try it out. Just activate the HTML/Java Project Support plugin in NetBeans and go ahead!

A Pragmatic Approach to Continuous Delivery

Summer time means less people at work and more time to think ahead what to do the remaining part of the year. In my case it means that I have signed up for a talk called A Pragmatic Approach to Continuous Delivery at jDays, a Swedish Java Developer Conference located in Gothenburg. Read the abstract here, and vote for it here if you think it sounds interesting.

While I was at it, I also proposed a lightening talk on the same subject to Smidig 2012, a Norwegian Agile Developer Conference in Oslo.

Responsive Web Design Demystified

This post is not about generating traffic. Nevertheless it probably will since the concept of Responsive Web Design is pretty hyped these days. Everybody seems to be talking about it an I am a bit concerned that the wrong people will start thinking it is the solution to everything without understanding what it is.

First of all, it is not about technology. The technologies and techniques involved have been around for a while, even though they are constantly improving hand in hand with the browser support for CSS3 and HTML5.

Responsive Web Design is all about mindset. It is about getting away from the print-on-paper-influenced-960px-wide-look-the-same-in-every-browser way of thinking. It is about convincing the customers that it is not only okay, but actually required, that your site looks different in different browsers. It is about creating the best possible user experience regardless of what browser or device you are using.

Just remember that there are still lots of situations where the responsive approach is not the way to go and a “mobile” or “tablet” version of your site is the preferred solution.

Agile Architect Pattern

Intent

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.