The Hungry Ant

• Tasty Cupcakes
  A very good site showing different games that can be used to explain agile. I have used a few of these when giving agile workshops and they have really helped me to explain the subtlety of agile.
  (tags: agile)

The question has come up about whether to refactor in big sessions or whether to refactor a little bit at a time. I definitely prefer to refactor as I go along. Fixing little things as I see them. The reality is that if you wait for the “Refactor Session”, firstly it means that for a sprint you are not producing value to the client and secondly the code has been allowed to get into a mess which then needs this big clean up and is much harder to know what to refactor and how to tackle it.

I guess it is a bit like waiting to clean the dishes until the sink is full or washing plates as soon as they are dirty. The first way means you have a dirty sink and plates that end up with dried up food on it (and a reluctance to go near it), the second way means you always have a clean sink and plates are easy to clean. As I have moved away from my student days I realise that the second way is the better way. And so it is with code

If you find a bug in your code, make sure that you write a test to produce that bug, then write the code that makes the test pass. This way you will always be sure that the bug will never appear again.

Due to our distributed way of working, where we meet in person infrequently, we have been having sprint reviews at the end of our sprints and immediately follow with a sprint planning meeting. This is efficient on time but really does not allow much time to react to the information presented, adjust the product backlog and decide on the tasks for the next sprint. We have also not been allocating enough time for the meetings, leading to poor task definition for the sprints.

On larger projects I have successfully had sprint reviews happen on a different day to the sprint planning meetings, giving adequate time to the product owner to make last minutes changes to the backlog and the team to have a pause before ramping up for another sprint and to give estimates to tasks. But in our case it would be impractical.

The sprint planning meeting is not an easy meeting, it takes mental effort as the team are collectively solving technical problems upfront around what to do and how to do it. It is not a meeting that can be done in a hour. For a sprint review and planning ensure that adequate time is allocated, that the product owner has thought about the product backlog before the meeting and that there is a pause between review and planning.

• disambiguity » Design starts with Proposition (ergo Usability)
  A nice explanation of why you need to understand your users and their needs before you start building something.
  (tags: design proposition)

Comments in code can seem useful but they add noise and they get out of sync with the code. When writing code, I think it is better to use less comments to explain what you are doing and to focus on making your code more readable. Use understandable and descriptive method and variable names, even if they are reeeeeaaalllly long.

If you have a long method where you need a comment to explain a subset of functionality, think about creating a private method with the subset of functionality and give it a name that says what it does. You will quickly find that you don’t need the comment, your method is easier to test and easier to understand.

Of course, if you have some insanely tricky algorithm then maybe a comment is worth adding, but I would first suggest if there was a way to make the tricky algorithm less tricky.

When you are splitting a user story into tasks for the sprint backlog, it is better to keep the tasks small so that they can be completed in a half day or day. It is normally easier to break down a task into smaller tasks and it creates more of a flow in the sprint where there is constant satisfaction in tasks being completed and progress being made. I certainly notice the difference when we have lots of small tasks.

The focus of the team at the moment is to introduce a testing framework to all our projects. Although I don’t think you can be agile without testing, the team were not forced into adopting testing but were gently encouraged when it was obvious that testing would resolve a certain suite of problems. From experience, it is far better when introducing a new process like agile, that the team decided to take on a change through need, rather than it being forced on them.

For example, we are working on Drupal web project that has a complex permissions system. This basically requires a developer to check that the system works for all the configurations every time there is a change to the system. As Drupal is mainly configuration programming, a quick change can take time to verify by hand and is error prone. By introducing testing we can automate these tests and improve project development speed, reduce bugs and move to developing iteratively and then introducing functionality on the basis of what we can actually see working.

Coming from an OO agile background, I find the configuration programming nature of Drupal not my technology of choice, but it is undeniably a very powerful system with many modules already developed, and if you understand it you can develop a complex site, of a certain flavour, very fast.

For Agile it brings it own set of problems and we are slowly trying to resolve them. I hope to write about how we are doing agile development with Drupal for a later post when we have ironed out all the problems. But I guess my main problems are how to test and how to iteratively add modules to the production system while not losing data. Problems I am sure that there are solutions for but that the team needs to resolve.

For testing, We have decided to use Selenium for testing our system as we are not programming as such,  so our tests are actually integration tests and need to work through the browser.  Selenium allows you to write test scripts in many languages that are then played through various browsers. It is not perfect but I haven’t found anything that works better yet.

I don’t like sprints where we are not producing functionality to the client, so we are dividing the sprint into some new functionality as well as improving our our agileness.

For the other project where we are developing in c++ and python, as it is a library, our lives are a lot easier as they are more typical development projects with good test frameworks (we are using BOOST and Pyunit) and the team are very close to having a good test suite that will allow us to start improving and refactoring the code.