TDD workshop – Make the right code right

Last week a colleague and I held a presentation about TDD for some of the developers at one of the largest banks in Norway. It was a 3 hours session with a mixture of presentation and 3 demos. The presentation can be viewed here. Here is a quick summary of the contents of the session:

The session was split into three parts:

1) TDD intro – What is it and why should you use it
2) Beyond TDD – Why supplementary techniques is needed
3) TDD in “real life”

3 ways to kill focus in an agile project

Focus is in my opinion, one of the key ingredients in agile software development and teams with the correct focus will consistently deliver more value to the organization than none-focused team. Obviously.

There is more than one reason why focus is important within software development. Not only must the team focus on the stories at hand, they must also focus on delivering the right code for these stories. When you know that 56 % of all errors in software projects stems from the requirements you realize that this is extremely difficult. Yes, software development is hard and it is really not surprising that so many software projects are late, more expensive than planned or even worse: fails to complete at all.

Maven generate archetype

Recently, a colleague and myself decided to brushing some dust off some maven archetypes we created for our employer to fasilitate kick-start development in projects of similar type. Things went smoothly until we hit a problem which wasn´t easily solvable. Searching for a possible solution to this problem on the web, we then discovered that using mvn archetype:create-from-project plugin would give us a great starting point for creating a better archetype.

AspectJ – Lessons learned

AspectJ is a powerfull tool and is able to solve some problems that the Java language is not able to. It gives developers flexibility to solve crosscutting concerns like logging, profiling, security and so on. At the same time, AOP can be dangerous to us and may lead to serious problems if used incorrectly.

Over the last 2 years I’ve been using aspects quite a lot and gained some experience on how to use it. In this post I want to share some of the lessons I’ve learned.

Leaving the code in a better shape than I found it

Yesterday evening I read the latest blog post from Uncle Bob about how refactoring can help you find dead code in your code base. A great post, you can find it here. Apparently, Uncle Bob has a policy that says that whenever he has code up in an editor, he has to try to leave it in a better shape than he found it. I think this is a great policy and although I think I will have problems applying this principle myself I will at least try to apply a policy of leaving code I work on in a better shape than when I started….

6 keys to “Hyper-productivity” in software projects

Some software projects fail, others succeed. Why is this so? Is it possible to pin-point the success criteria for successful software projects? Over the last couple of years I have participated in quite a few “agile” projects, and for the projects falling in to this category I think that I have learned a thing or two. Below is a list of 6 key criteria that I believe is important in order to be successful when doing agile software development:

1. Focus
2. Use XP engineering practices
3. Start small and design for change
4. Know when you’re done
5. Team size
6. People

XP practices – the key to agile success

I firmly believe that in order to be able to develop and deliver software rapidly, also known as agile development, teams need to do xp programming practices like TDD and pair programming. Why so? Well, let’s take the TDD practice first: TDD helps developers keeping their code clean and the design well factored. To me TDD is not so much about test as it is with design. Surely, it will help in keeping your test coverage at a good level and this coverage will help in protecting your code. But much more important is the fact that TDD will improve the design of your application and prevent the growth of technical debt which so often delays software projects.

Another xp practice that agile teams should apply is that of pair programming. I do think that most people now agree that pair programming is far more efficient for most creative programming tasks than the individual approach. The most obvious benefit of this technique is perhaps that it leads to better code and design quality. Other benefits of doing pair programming can be found here: http://en.wikipedia.org/wiki/Pair_programming.
Still I find that if not pushed, people slide back to the habbit of  doing solo-programming.

One of the promises of the agile sofware development methodology is that of more frequent software releases. If we can create good quality software every day we greatly increase the chance of fulfilling this promise.

Android development

This Monday, I attended a talk by Dan Morill (Google) about Android development at the Colorado Software Summit. Having no previous experience with this, Embedded device development is miles away from what I normally work with, I was hoping to learn something new. Indeed I did. The first half of the presentation was devoted to giving an introduction to the architecture of Android, which at least gave me a good introduction to the Android architecture and the SDK

Colorado software summit 2008

Yesterday, 3 colleagues and I, arrived in Keystone Colorado to attend the 2008 Colorado Software Summit. Having spent the entire day (and more) traveling we were very satisfied when we finally could get some sleep. Today is Saturday and since the conference doesn’t start until tomorrow, we have the entire day off to do anything we want. 

This is my first time at this conference and I really look forward to it. The agenda looks really promising with loads of interesting talks. The program can be found here, and hopefully I will have time to comment on some of the talks later in the week..

JavaZone 2008

Last week I attended the 7th edition of JavaZone, hosted in Oslo Spektrum. After a very good conference in 2006, I felt that the 2007 edition was a bit of a disappointment. That said, I was never in doubt that I wanted to attend this years conference and the agenda showed some great promise. The only problem seemed to be that some of the talks I wanted to see were colliding, well it could be worse…. The initial promise wasn’t just a promise, almost all the announced speakers turned up (apart from a few that apparently got ill), and better yet; a lot of the talks were of really high quality.