My strategy for focusing
Unfortunately, I believe I'm fairly susceptible to distractions. As I strive towards a goal, if presented with another task that's more appealing, then I can find it difficult to stay on track. I've often been told this is bad, as not being able to ignore distractions will prevent me from getting tasks done. For years I agreed with this, watching other people naturally focus in on tasks, complete them and move on to the next thing. However, learning more about agile and lean development and basic psychology, I'm no longer think this is a pure disadvantage, and I know I'm not alone.
How could it possibly be good?
Simply because, my natural wonderings away from my task often present me or my team with lessons, new tools and / or techniques, and sometimes just a welcome break!
However, sometimes that focus is needed..
Why did I struggle with some software tasks?
The implementation of a software feature, bug fix or similar can vary considerably in terms of size and complexity. What is the state of the development environment? Is it at the same version as production and how can I revert it back if not? Regardless of the current state, can I be assured no colleagues will change it whilst I implement this fix? What are the exact requirements or nature of the defect? What components need to be amended, created, simplified and tested? How will I know when the feature is complete, or when the defect is 'Fixed'?. And even if I know all the answers to these basic, necessary questions at the beginning of the task, can I remember them during implementation?
There's no wonder I struggle to load all of this into my memory and get a grasp of the problem in hand. Often quiet developers might either fail to understand the need of gathering all this information, or maybe manage to ignore some of these constraints allowing them to fix the defect quickly. However, I've commonly seen these 'fixes' be thrown back as fix-failed. "Oh, but the testing environment hasn't got this patch", or "I didn't realise the defect covered that aspect too" is the response followed by a quick refocusing on the defect which is harder now, as they've started to load up the next defect into their cognitive memory.
Notice the word 'did' in the heading? Well, after much reading, and active participation in the agile and lean software communities, I discovered these issues are common and affect true productivity and even mental health in developers. It's simply too much to take in, and I've consolidated on a set of practices that hopefully reduce the impact of these either through eliminating the problem or maybe isolating different concerns to allow me to concentrate on different sections of the feature or defect without having to worry that I'll forget the rest.
- BDD and automated acceptance testing.
BDD (Behaviour Driven Development, or TDD done right :P) is a principle in which collaborative agreement of a system behaviour (feature, defect etc) is reached, and the output defined in a set of automated system tests. These tests will initially fail as the system hasn't been modified to add this behaviour. Then, the developers will lazily adjust the system (applying non-lazy refactoring) stopping only when these acceptance tests pass.
These consistently failing tests provide a framework which constrains my activities and thus provides a framework for focus. Lazily doing the minimum needed keeps me on track to implement the task as quickly, and as simply as possible. I've also had great feedback from developers and testers persuaded by me to try this technique.
- Isolated, configuration controlled development environments.
I've never liked shared development environments. There, I said it. To me, configuration control, versioning, accountability are essential aspects of large scale software development. However, developers like to play, trying such and such library or technique. They may start to fix a defect on a Thursday but due to other commitments might not get chance to conclude this task until the following week. If this work in progress has been applied to a shared development environment, then how will this affect other developers? How could you role out a new emergency release to fix a production problem if needed? You couldn't. This is far more problematic at the database level, but I'll wait for another day to rant about that.
So what's the alternative to shared development environments? Isolated development with continuous integration. Isolated development means that each developer has their own play pit to make changes to the software. They should be allowed to do as they like in this play pit. Experimentation is a great enabler for innovation and improvement. When the developer is done with a feature, and hopefully applied enough refactoring to ensure it's architecturally sound, then they can commit just the assets they wish to commit into source control. This allows controlled, quality changes to be identified and extracted from the play pit into the software being developed.
- Reducing Work in Progress
I've sometimes got confused by the amount of differing threads of activity within a single project. Features being implemented, defects being reported and fixed, releases being released and fixed. During these situations, it's difficult to establish the status of the different threads, and things get even more complicated if dependencies between them exist. Lots of tripping up over each other, and waste through waiting occurs.
Further when a large team is working on such a project, especially at crunch time, it's common to see individuals working separately on features that might mean changes to a shared component. This can be safe to do - presuming good version control tools and practices are applied and automated testing is enabled to prevent integration issues. However, anyone that has tried to merge code in a rush near project completion knows how cautious you have to be. Caution reduces speed at the time you least need to be slow.
If this kind of collaboration is necessary, and two threads are being slowed down due to shared concerns, then maybe the best solution would be to reduce the threads. This means reducing Work in Process - a key tenet in lean. Get the two developers working on different features impacting the same component instead to pair program on the first task, and once done, move on to the next task. If nothing else, it means to developers don't have to worry about what others are doing, and how that may impact their work.
And the wider dreams, goals and programmes?
Well done, if you managed to survive that discussion on how I keep focus on development. I classify these principles / practices that help with mid-level focus i.e. focusing on tasks that might take between a few hours to a few days to conclude. However, I also have problems focusing in the short term (think 10 minute blocks) due to distractions including emails, twitter and conversations. This is a common issue in modern office environments, and I try to use Pomodorro as a tool to combat it. This is a practice that attempts to constrain focus into small manageable blocks with regular breaks. As with all tools, I don't use it all the time, but it certainly helps when faced with a challenging deadline or just wanting to get things done.
Which segues nicely to my longer term focusing problems. I can't remember all of the things I need to ensure a happy life. I've spent countless hours trying to put tasks into electronic calendars, and spend half my time reorganizing tasks as they don't get completed on a certain day. Therefore, reading Getting Things Done some years ago was a revelation. I drank the kool aid, brought Things and even have an empty email inbox (sometimes). I think of it as agile life management.