Software Projects as Rock Climbing

This post http://www.codinghorror.com/blog/archives/000830.html on CodingHorror struck a chord with me. I had always thought that my favourite sport was similar to writing software but this really makes the point well.

Simple Cruise Control Block Diagram

I realized today that I had not seen a simple block diagram of a typical continuous integration system and how it interacts so I thought I would put one together.

Software Development Tools

Java Development

• Eclipse (Web Development) http://www.eclipse.org/webtools/
• Checkstyle Plugin
• Format on save plugin
• JAD Plugin (Windows)
• JUnit http://www.jnunit.org
• CheckStyle http://checkstyle.sourceforge.net/
• Corbatura
• Simian
• AspectJ

.NET Development

• Microsoft Visual Studio http://msdn.microsoft.com
• Resharper - essential refactoring support http://www.jetbrains.com/resharper/
• NUnit http://www.nunit.org
• NAnt http://nant.sourceforge.net/
• NullSoft Installer http://nsis.sourceforge.net

Ruby Development

• RadRails www.radrails.org
• TextMate http://macromates.com/

Tools

• Subversion http://subversion.tigris.org/
• Trac
• ANLTR http://www.antlr.org
• Parallels
• Emacs

How done it looks implies how done it is

Kathy Sierra and Dan Russell have an excellent article on prototyping and how the prototype influences the audience
http://headrush.typepad.com/creating_passionate_users/2006/12/dont_make_the_d.html

Makes very interesting reading. Have to admit I have fallen into this trap before and spent some time persuading people that the application is not as advanced as the prototype could make them believe. Matching the maturity of the prototype to the maturity of the application makes a lot of sense.

Courage to do the right thing...

Doing the “right thing” is often hard

Being sure that you know the right thing to do is not that easy either.

So why do we often need courage to do the right thing? Surely doing the right thing is what we do all the time right?

We all live in an imperfect world constrained but time, resources and our tools. Often doing the right thing seems too expensive to do and doing some less than perfect updates to the code or environment feels so much more attractive.

So why do the right thing when doing a less than optimal change delivers a result that works? Surely doing the 'simplest thing' that could possibly work says that making pragmatic decisions is ok?

Often it is difficult to put into words why doing something is the right thing to do. Often is is just a feeling that something needs to change. The trouble with these sorts of feelings is that the do not go away - and in a way I am glad that they don't because often putting off doing something about them turns out to be a bad idea.

If at all possible listen to your feelings 'do the right thing' and change the code.

Technorati Tags: Courage

On the subject of lists

When I am under pressure to deliver and there are a million and one things going on both in and out of my life I start making lists. I know that I should do this all the time because I know it really works but when the number of items on the list is small I always think I can hold the list in my head. It is only when things get interesting that I resort to list making.

But what should go on these lists. The bottom line is almost everything. I keep at least two lists both in priority order, one for work and the other for the bits I try to do out of work.

The list for work items helps me maintain balance by keeping the high priority items at the top I know that I just need to work my way down the list. By having a list for personal stuff I can make sure that in the odd moments when I am not actually working I know what I should be doing.

Having the lists mean that I do not have to keep remembering what to do next.

Simplify your life - make lists!
There are some excellent descriptions of how lists can be made to work for you over at the http://www.pragmaticprogrammer.com. In particular http://www.pragmaticprogrammer.com/titles/rdbcd/index.html

Managing your day

Working as a coach I sometimes hear the complaint that interruptions and additional tasks cause significant pain to a development team.

Often people are asked to do things that were unknown at the start of a sprint/iteration but appear to be urgent/important when the sprint is under way. Since these activities are unplanned and unbudgeted taking on these tasks can put the sprint goals in jeopardy. It may be that the requests seem innocuous - an hour here or there, what harm can it cause?

Individually these additional tasks may not seem significant but these interruptions add up and can start taking over. They also establish a pattern for the future and people get used to asking for more and more of your time.

Switching tasks and not being able to complete one task before being pulled off onto another one should not be underestimated. It is not easy to pick up some development work even after a break of an hour or two!

Keep a list of things that you have done during a sprint that can be used to adjust capacity in the next one. Make sure that the Scrum Master or Iteration Manager is aware of these interruptions (they should be consulted anyway). Make sure that these additional tasks really are more important that the current goals!!