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!!

Pair Programming

Not sure if this is just a way of not forgetting a good blog entry or not but Naresh Jain has written a very useful FAQ on pair programming at http://jroller.com/page/njain?entry=pairing_faqs

If you are interested in trying out pair programming or have found it does not appear to work for you then I suggest you check it out.

Testing Application fail-over using Virtual Hardware

Application availability is one of the key features of many designs. e-commerce web applications are a particular example where the application should be available to customers as much as possible. A common model to achieve this is to have a number of servers available. Should one server fail the other servers pick up the request and deliver the result to the customers computer.

Although this design is simple in concept and with a lot modern server systems straightforward to implement testing the failure scenarios is often a complex and demanding task. Typically this sort of testing is done manually by disconnecting a server from the network or terminating processes on the server.

Virtual hardware can provide a cost effective alternative and provides capabilities that are not available when using physical servers.
Lets take an example

1. The customer clicks on the ‘Add to basket’ for a widget
2. The request is serviced by server A and returns a page representing the basket containing the selected widget.
3. The customer clicks the ‘Proceed to checkout’ button
4. The request is serviced by server A and returns a page requesting payment details for the basket containing the widget.

A fail-over scenario might look something like this

1. The customer clicks on the ‘Add to basket’ for a widget
2. The request is serviced by server A and returns a page representing the basket containing the selected widget.
3. The customer clicks the ‘Proceed to checkout’ button
4. Server A has a network fault so the request is serviced by server B and returns a page requesting payment details for the basket containing the widget.

In production this might be caused by a rodent chewing through a cable at at critical moment or some other hardware fault. But how do we test this easily.

Virtual machines typically use a virtual network connection routed through a physical connection or completely virtualized on a single host server. With VMWare Server and Microsoft Virtual server this network connection can be controlled by the host or by an application controlling the host. The last option is the most interesting because it allows the connection to be controlled programatically in the test code.

A test might then look like (pseudo code)

result = http.request(“www.test.domain.com/AddToBasket?product=widget”)
AssertWidgetInResult(result)
VirtualHost.ServerA.Network = disabled
result = http.request (“www.test.domain.com/Checkout?orderid=” + result.orderid)
AssertPaymentOptionsDisplayed(result)

The ability to automate these tests should not be underestimated. More complex scenarios can be developed and executed easily. The test code can be run frequently perhaps as part of a continuous integration system. Execution time for the tests is now much faster - no manual interventions. Removing the manual steps makes the tests repeatable and less prone to execution error.

Developers, Quality Analysts and Architects gain a much greater understanding of how resilient their application is to failure which leads to a greater confidence that the application will behave as expected in a production environment.

So what is this blog all about?

To be honest I am not too sure. I have a number of other blogs for family and one syndicated through work so why you ask should I have another one. Well this one is for me to talk to myself and anyone else out there interested in hearing what I have to say about writing software.

I love working in this industry! I see it as a privilage that I can be paid for doing someting that I love to do. Hopefully there will be some gems of wisdom here that other people will find interesting, hate or perhaps even amusing.

Only time will tell.