Good Tools

I have this image of a metal-worker who has just finished manufacturing a fine tuned machine part. I see him running his fingers over it’s surface to feel it. This affectionate gesture is a key ingredient in quality assurance.

This came to me as I am working on some code (PHP server with a Flex/AS3 client).  I encountered  some poorly implemented components and the quality thing to do was to improve them (this is sometimes referred to as re-factoring). I have decided not to do that and it’s bothering me, but I am sticking with my choice.

Working with code means there is nothing tangible to run my fingers over. Actually “running my fingers over a component” in programming is called unit-testing – it is achieved by “activating” the component independently and checking that it behaves properly. Debugging tools are required to do this – they provide a means to activate, control and inspect the component. The environments & tools I am working with (all open-source) are missing functional debugging capabilities and tools.

I am not running my fingers over my components because I don’t have the tools to do it.  Because I don’t have tools to run my fingers over my components I make lower quality components, which sometimes don’t function as expected, which force me to fix and change my components. Because I have a lot of fixing and changing to do, a lot of the time I spend coding I am in a “failed” state of mind. Because I am in a “failed” state of mind I am not passionate about what I do. Because I am not passionate about what I do I create mediocre components – which require quite a bit of “running fingers over”… and on and on…

Why is this bothering me? I like to like what I do. I like quality, I have great faith in quality.

Why did I choose to stick with what I have? There is a bigger picture in front of me. The code is part of a larger project. The quality of the project can tolerate the existing code. Quality needs context – I can continue to pursue the highest quality code, but that would be at the cost of a higher quality process. If & when it will become relevant, the project will create a context for me to go back and to improve the code.

My take on this:

• Get good tools
• Appreciate the tools I do have
• Aim for uncompromising quality
• Compromise quality when it’s relevant
• Have a bigger picture so I know what is relevant and what is not
• Get good tools