I finished reading Esther Derby’s & Diana Larsen’s book “Agile Retrospectives: Making Good Teams Great” a couple of weeks ago. Although my experiences with retrospectives are very limited and have no experience of leading a retrospective, the topic was interesting and I decided to order the book, which is basically a handbook for leading retrospectives with very specific tips and guidelines for the whole process.

If you’ve never lead a retrospective and you are thinking of organizing one, this book is an excellent place to start. The whole retrospective process is described and explained very thoroughly with hands on tips on every phase of the retrospective. If you’re looking for such handbook, this is your most definitely one to pick to the bookshelf. But be warned, this comes in a form of a “user manual” – very structured text, which might have been juicier to read, if it had more narrative experiences from the real life.

By the way, the authors have given a presentation on the same topic at Google. Check it first out, and if you’re still interested to know more detailed instructions and guidelines for facilitating the process – Go and buy the book. Another good resource for learning more about retrospectives is Linda Rising’s podcast on Software Engineering radio. Her notes and comments are more on a general level, but are by no means less relevant or interesting.

And once again I find thinking this same thing: although the context of software engineering is often highly technical, the problems are solved by individuals acting as a team.  Soft skills in team work are often way too underestimated compared to technical skills. The better the chemistry in the development team, the better the results -  even if the team wasn’t technically that brilliant.

James Shore, a developer and an agile coach, has kept a change diary on his experiences from a consulting gig where he tried to change a development team to use agile and XP methods. Did he succeed in his quest or not, does not matter, the most important thing is the documentation of the bumpy road.

The notes are rock solid and making much sense, with numerous tips for people trying to make an organizational change. Well, organizational might be a bit heavy word here, ‘team’ might describe the right magnitude. Anyways, must read for everyone trying to make an impact in his/her organization.

One of the key points in the notes, in Chapter 10:

It took me several years to realize this, but now I believe that the Way to Change is No-Change. No, this isn’t some sort of pseudo-Zen mysticism. (Okay, I admit to dressing the phrase up in a zen outfit, just for fun.)

Martin Fowler is some kind of an icon of modern enterprise software development. All those books he has written and also It seems like it is quite hard to find a conference these days, where this loud-mouth isn’t speaking. And it is true, that he has contributed to the business quite a lot: work on patterns, refactoring, agile, DSL, etc.

Some (including myself) might think that this evangelist should step down from the clouds and get his hands dirty on real projects again to see what the real life is in most of the projects. But no one can argue that he wouldn’t be an outstanding at giving public presentations. Actually I think that he’s technical contributions are nothing compared to his savyy presenations skills.

I’ve gathered some of his presentations below. Go ahead, grab some snacks and good drink and enjoy the presentations. Don’t be bothered with some of the hype and over simplification of things. The way he presents issues and takes the audience is something that a very few can do.  One of my personal favourites is the third set (Look mom: No slides at all)

• Tutorial on DSL
• High-flying rant on ESB’s
• Three things Fowler likes in Ruby on Rails
  

I’ve done my fare share of developing Swing apps in my java years. Perhaps 40% of UI development in my 8 years of java experience is done in Swing. Now that’s a quite a big percentage these days, when most of my colleagues have never done any Swing and their UI development is mostly done to web. Since the industry is concentrated to the web, naturally most of the tools (for example testing) are concentrated to web as well.

I believe that integration tests are perhaps the most valuable tests that are written (Acceptance tests excluded, but you create acceptance tests using these tools), so I share my experiences from two very different open source testing tools for Swing. One is called the FEST-Swing, and the other is Marathon.

FEST-Swing

FEST-Swing is a Java API for, which is based on looking up components and making assertions on them. The API is a DSLish ‘fluent API’, which makes writing the tests somewhat pleasant. It can be used with either JUnit or TestNG so it doesn’t lock you in one unit testing framework, and the best part of the project is that it is active (last update was on May 19 2008). For example, I used FEST-Swing for testing my SCJD assignment, and it proved to be a good tool for the purpose – no problems in writing the tests, and it was quite easy to test all the scenarios. I’m not sure how it responds to more complicated UI’s, but I’m ready to give it a try in other projects as well. Very promising indeed.

Marathon

The project was initially started by the ThoughtWorks developers, so I thought there might by something to it and I decided to give it a try. The framework is based on capturing user interactions and recording them as Python scripts. Of course you can edit these recorded scripts later on using any text editor, because the scripts are valid Python, not some proprietary format. I tried this on one quite complicated (lot’s of user interface logic and decision making) project and I ran into problems. The scripts recorded by the recorder all required some manual editing before I could re-run them from the Python file.

Frankenstein

Sidu Ponnappa sent a comment to my “about”-page concerning another open source framework, the Frankenstein. It is hosted at openqa.com, the same site that hosts Selenium. Like Marathon, this is also started in the ThoughtWroks labs. After a quick try Frankenstein is a clearly on a very early stage of it’s development. For example, the documentation is extremely lightweight, with practically no examples.

The framework allows you to record your UI actions, which are then saved to Ruby scripts. After a few try and errors I managed to record some actions and run the saved Ruby scripts after minor changes to the scripts. What I liked about this one was the simplicity of the recorder, and the possibilities that the Ruby driver brings to testing the UI’s..

I saw a video of a one-armed American high school kid, Porter Ellet, playing one of my favourite sports basketball. Not only did he manage himself against the others, but he is actually the team’s leader in scoring with only a single arm!

That really requires determination to Get Things Done. And that is a quality what we all software developers should have. To get things done in the best possible technical manner, despite of managerial and technical obstacles. It is easy to just get thing working, but to really finish of with robust, readable and testable code that meets all the possible requirements that the client didn’t event think would exists, is a whole different thing. It requires determination to give that extra push, that separetes the best software from the average.

The Dzone community portal offers fantastic cheatcheats for different technologies (They call them actually RefCardz). These short 1 to 5 page printouts are loaded with information on a specific technology, or a part of technology , such as Ajax, Spring configuration, EJB3 DI etc..

The best part is that they add a new RefCard every week!

Google released a new service a few weekss ago, the Google App Engine. At a first glance it seems to be a very interesting service, which they call an alternative to the LAMP stack. It offers a server environment for your code, persistent storage and integration to other Google’s services, plus the runtime environment (Python). And of course all of this is free.

• 500Mb of storage for scalable applications
• Persistent storage (Sort of a database)
• Python environment for dynamic web applications
• Application framework (However you can use your web-framework of choice)
• Integration to Google services (User authentication, Datastore, Email, URL Fetch API)
• A development server to emulate live Google services

I signed for a free account today, but unfortunately it looks like a few others have signed in as well. At the moment they don’t offer accounts any more. Perhaps the service was more popular than they expected. Anyways, I can always develop my services on my local environment, and upload them when I get the server storage.

We’ll have to wait and see does this mean a growing number of interesting web applications in the coming months. At least you can’t blame it on the missing infrastructure anymore, can you.

A personal note: QCon conferences seem to have interesting topics and presentations. Not just vendor specific stuff like BeaWorld, but platform independent presentations from developers view point in the spirit “For developers, by developers”. Should try to attend either one of these next year..

For starters, check out the slides from JAOO at London. One of my favorites is Linda Risings presentation on efficent working, and I can personally agree on many of the notes.

TDD, Test-Driven Development has been here for a while since XP introduced it in the late 90’s. However, the concept is not that new. The great Edsger W. Dijkstra has written a few words on TDD as well, and it dates back to 1972 an his article “The Humble Programmer”.

“Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. Argument three is essentially based on the following” observation. If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance.

I’m not sure did the big D mean the unit-testing approach of today, or theoretical proofing of algorithm’s correctness. Nevertheless, the idea took 30 years to really get ground in the mids of programming professionals. Kudos for Dijkstra anyway!!

By the way, really should read more these oldies but goldies from the history of computing.

A few days ago I read Martin Fowler’s article on using Agile software process with offshore development and one particular comment was so true that I have to mention it here. ThoughtWorks, the company Fowler works for introduces new team members to a codebase by making them fix bugs before starting to implement new functionality. I’ve experienced the benefit of such approach myself a few times.

First clear benefit is, that you really get to know the design and architecture when you must read and most importantly understand the code around the bug. After understanding the code around the bug, you can fix it without breaking something else. It really is the best way to understand the system behind the use case as a whole.  Reading some out-of date design/architecture documentation just doesn’t tell the same story as the code does.

Second benefit is that when you have fixed some bugs, you start to get familiar with the patterns and style that other developers have used through out the code.

Finally, when it is time to add new functionality, you a) know how to fit it into the system, and b) your fellow coders understand what you wrote, because the style (hopefully is similar)