We’ve been recently working on moving the legacy UI code to MVP. This week has seen my focus move from doing some of the initial work, to a support role within our team. So the focus has been on fixing live issues that we currently have within our system. I might blog about the reasons I think we have these support issues in the future.
As the week has progressed (it feels like a long week, maybe because it’s a short week!) – I’ve been getting more involved with a colleague who is now converting the legacy code to MVP. It’s been extremely interesting pairing/mentoring the developer. My colleague is quite new to MVP and test first approach so it has been interesting to see how focus can be lost quite easily – thinking about other sections of the system.
I think this is to do with focusing on the problem at hand, not getting distracted by other issues and just solving the current red issue – the broken test. Once this is green we can think about things which might be important or not be – i.e. how can we improve the current design and the current code base. Or even add another test to highlight the current hacked – I’m very much of the ilk of doing the simplest thing to green. Maybe I’m just plain lazy or like to KISS. Maybe I want to ensure that my focus is on the smallest possible thing. A former colleague always used to say, “I can only concentrate on one thing at once.”
This has made me think about a number of things. Developing software is hard; thinking about an entire system and its interactions is even harder. Sometimes developers struggle to focus on their current problem and get distracted by something completely different (i.e. the entire system!).
This is the reason it’s important to write tests first. The act of writing the test focuses the mind on what it is we want the method/SUT to do, we can then focus on doing the simplest thing to get the test green. Once this is done we then focus on refactoring. We then repeat. This ensures that we keep focused as we write the code – it’s a very nice rhythm, and very rewarding (amazing how seeing something go green gives me a thrill!!).
I recently sent out the code kata that Roy Osherove put on his blog – the string kata. It’s interesting that the notes say ensure you do not rush ahead of yourself and do not scroll down. Something any human being would want to do, we are thirsty animals for information and problem solving! I know that some people might struggle with this!
I suppose this poses a couple of questions for me:
- Are we killing the inquisitiveness by stopping people from rushing a head, or just simply focusing the brain power of the individual/pair (I know that in a pair one will concentrate on the code, and the other on the design) on the problem at hand?
- Do we currently struggle to focus on a single thing?
- Can the human brain multithread?!