Productivity: Learning productivity Programming Reflection
by Daniel
leave a comment
Reflection for improved performance
Regularly taking time to pause and then review and reflect on how you could improve, and then experimenting based on those thoughts is key to personal improvement and increasing productivity. This technique has really been highlighted to me since starting to use Agile development methodologies like Scrum where at at the end of each sprint (short iteration period) a retrospective meeting is held. These meetings allow those working on the sprint to pause, review and reflect on their performance during that sprint and to discuss how performance could be improved. The regular retrospective meeting is in my mind one of the most important innovations introduced by Scrum and Agile, as otherwise retrospective activities were limited to once per development cycle after shipping the product.
I think that those short development iterations and regular reflection sessions at the end of each iteration introduced by Agile/Scrum are perhaps the two components of these methodologies that help drive process improvement the most, but they are perhaps also the easiest to overlook. It would seem that the natural inclination for most workers (especially when stressed) is to not stop and think about how they are working, which means they do not truly understand their work flow and this limits their ability to improve their performance.
Some of the most productive individuals I’ve met, or have heard about, are those that regularly take the time to pause and think about how they are working not just about what they are working on and then experiment to improve. This habit goes against the instinctual urge most of us seem to have when ‘busy’ which is to not stop to think about the how as we think we don’t have the time to spare. This is a huge misconception, as taking time to pause and think about how we are doing things and how we can improve can yield large gains in terms of increasing productivity and reducing frustration.
Another overlooked aspect of reflection is that it can make a mundane repetitive task more interesting and stimulating by turning it into a personal challenge: can you tune your work flow and improve your performance on a set task? For example, habit can even be applied to repetitive manual tasks like mowing the lawn: can I mow the loan in a shorter period, where can I save time or remove repetition?
In summary, pausing and reflecting during your working day and then experimenting to improve can help drive a habit of efficiency which will increase your productivity and potentially improve the development process for your whole team, and this is what all development efforts need to suceed.
Adventures with Test Driven Development
I’ve recently had a chance to use Test Driven Development (TDD) while developing a new piece of software; this is something I’ve been wanting to do for a while but was waiting for the chance to try it out with a completely new project. The work involved wrapping a C library with a C++ wrapper and then wrapping that C++ wrapper with a managed C++ wrapper so I could then use the library in a C# application. I originally planned to use only one C++ wrapper but I couldn’t figure out a way to deal with abstract C structures in managed code so I ended up creating the C++ wrapper to isolate the managed code from those abstract structures.
For those that have not heard of TDD, or can’t remember what it involves, it is essentially a methodology that encourages the use of unit tests and quick iterations to develop software that matches the functionality specified in the unit test. TDD can be thought of as a five stage loop where one complete rotation is one iteration of the software, the five stages are:
- Write a new unit test.
- Run all the unit tests and see if the new test fails.
- Write the minimum amount of code to make the test pass.
- Run the unit tests and see the test pass.
- Refactor were necessary to remove duplication.
This sounds simple and it really is; the core of the idea is that the test in step one is effectively specifying some new functionality, which we then test and if the test fails, implement in the simplest manner possible in step three. This is followed by making sure all the new tests plus older tests still succeed in step four, and then in step five we refactor the program as required to remove duplication.
I’ve always like the idea of unit testing software as it seemed to me it would make regressing testing very easy and gives the developers more confidence in the quality of their software, as well as making refactoring a lot easier as the unit tests provide a simple and easy way to test to see if the refactoring caused any unexpected breakages. All these benefits observed during my trial use of TDD, plus one unexpected benefit, made me think a lot more about my program composition and my interfaces. This proved an unexpected bonus and was mostly born from a desire to make it easier to test my classes and methods.
One of the most common arguments I heard against unit testing is that it costs more time than it would to not write the tests; this is simply not true as this chart highlights. Writing tests for TDD may take longer to do than implementing the same solution without tests but the cost of fixing the bugs are moved forward in time with TDD which makes them a lot cheaper to fix, as the closer in time the detection and correction of a bug the quicker (and hence cheaper) the fix. So the assertion that unit tests mean ‘X% less features’ is simply wrong; unit tests mean more features as they make bugs cheaper to fix. This does not mean TDD and unit testing is not without flaws. I’ve yet to hear of an easy or simple way to unit test Graphical User Interfaces (GUI) as well as we can currently test source code.
In summary I’d recommend you give TDD a try if you haven’t already and if you’re using a .Net language I’d recommend NUnit as your unit testing framework.
Becoming unstuck
In my previous post I talked about being bored and dealing with that, now its time to talk about being stuck and how to deal with it effectively. For me there is a few flavors of being stuck:
- The brick wall: you’re working fine and then suddenly you’re stuck and you’ve no idea how to continue.
- Recursively stuck: this one is hard to spot. You’re trying solutions to something but each attempt takes so long to work through that by the time you’ve tried it you’ve forgot what started that attempt, you then try the first thing that comes to mind which often is the last thing you tried, repeat until you notice…
- Too many options: something that appeared straight forward on closer examination has multiple potential solutions and you’re not sure which.
My approach to becoming unstuck is as follows:
- Take Notes: As soon as I realise I’m stuck I start taking notes: what I think I know, what I suspect, what I’ve tried and what I want to happen. Doing this helps me prevent myself getting bogged down by attempting the same solution repeatedly. Also by recording what you think and what you’ve tried you give yourself an agenda of potential solutions to work through as you attempt to solve the problem, as once you’ve ruled everything on your list out what you are left with is usually the issue, although at times that may seem ridiculous!
- Ask Google: There are very very few new problems in the world that haven’t already been encountered by someone else and chances are there is something Google can find for you that may give you the pearl of insight you need to solve your issue.
- Ask the community: Chances are unless there is some sort of general community for the language and/or technologies you are dealing with, which you can ask via email, forums or IRC about your issue. A lot of the time Google will give you results from these communities if their archives are somewhere the Google spiders can reach.
- The cardboard programmer: This solution sounds silly but it works, find anyone (they don’t need to be technical at all) and then step through your problem with them talking over the source code. A lot of the time you will realise your error mid way through your explanation!
- Ask an experienced co-worker: Find a more experienced co-worker and ask them about your problem in an intelligent fashion e.g, giving details on the issue and what you’ve tried.
My golden rule for becoming unstuck is:
- Never be stuck for long! I can’t emphasise this enough, this is an industry where programmer productivity is the number one priority, not solving the issue yourself. If you’re totally stuck don’t sit for more than an hour (ideally half an hour or less) before you start involving more experienced people in finding a solution. Don’t believe me? Watch the most productive programmers around you, I would put money on them never sitting for long if they are stuck before they start asking for help, it is not a weakness, it is simply more efficient!
