I originally made a note to write this entry on the 6th February 2009. In fact, I wrote an entry in my personal work / research journal on that date but never transcribed it to a blog. At the time of writing my journal entry, I said “I have become so focused on the work project that I am failing to take time for reflection.” At the time, the pressure was on to deliver functionality and I felt under pressure to deliver to prove my capabilities.
In the desire to reach implementation targets, I discarded my preferred approach of test-driven development and simply endeavoured to implement functionality. The further I pushed in this direction, the more time I spent debugging instead of designing and building. The result was considerable difficulties and a stall in the development. A similar thing happens when we write tests that take too big a jump. In this case, the time in the debugger went up and progress went down.
Some see the debugger as their best friend. I am beginning to see it as my worst enemy and a sign that I am not thinking clearly about my design. In an event driven environment like Flex, the debugger can be the most unhelpful tool. Simple tests and simulating events and interactions has been the fastest way to resolve issues. The thoughts become focused and the problem is resolved faster and with greater ease. Thinking about how to specify a piece of behaviour in a way that enables it to be tested helps clarify the intent of the code and the design that will enable that intent to be achieved.
Writing lots of code quickly doesn't bring about good design. Code duplication is often ignored and the implications of certain actions are not thought through. All programmers go down paths which they need to back out of but without the time of reflection, it is easy to write code that becomes redundant once a better grasp of the requirements and the intention of the code is obtained.
Thinking through how to write a behavioural specification either as a behaviour-driven development specification or as a unit test helps clarify the structure of what is required. With the improved clarity and smaller steps for testing, better pace in implementation can be achieved.