The Hungry Ant

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.

The quote below was taken from railsstudio.com and gives a nice succint description of how a company that has embraced agile should feel like.

“Our approach involves on-going customer collaboration, complete automated testing, and iterative delivery (weekly demo releases). Our approach to Risk Management is to complete the highest risk tasks as early as possible. We believe in built-in quality. Testing is multi-level and automated. The code base is non-redundant and normalized (no duplication). We welcome (and request) frequent Customer functionality reviews and accept ongoing requirements changes, and improvement. Our design is feature driven, domain focused, and evolutionary. Iterations are each focused on delivering features of greatest current value to the Customer. “

I know most of the world knows this.

But firstly, if you are not using Source control like subversion or git then you should be! Even if it is just one developer.

Secondly, when you commit something to the repository add a comment. It may seem like extra work, but there will come a time when you need to revert your code and you need to know which file to revert to and that little comment will make a massive, massive difference.

Commenting is even more important on distributed teams, as it may be that a team member is not available to clarify something, and that comment might give you the little clue that saves you time and helps you understand the intention of the change.

When trying to work with an agile philosophy it is extremely important that you have the confidence to allow you to improve the code easily (refactoring). This usually means writing tests. Having a strong testing culture from the outset allows you to feel confident to change code in the face of new requirements and learning. Without them, very rapidly your team will start to shy away from changing a certain piece of code and start to build in workarounds.

I liken this process to work-hardening of metal. At some point without tests we have brittle code that is inflexible and easily breaks. Testing allows the code to stay soft and malleable and lets us change code without fear.

I notice often with developers that are new to agile methods that they are scared to touch the code that has already been written and I have to encourage them that with tests we shouldn’t have fear.

I like the practice of refactoring often, sometimes a little bit here and there as I come across something that could be improved. I find this to be an easier way to keep the code “soft” than to just have a refactor session.

Testing also offers us other benefits in terms of better interfaces, more robust code, a form of documentation and a means to know when something is done.