Is technical debt the Pinocchio’s nose of software engineering?

Technical debt seems like the Pinocchio's nose of software engineering; the ‘lie’ that something is finished perpetuates and causes it to multiply in size. Matthew Heusser in his article[1] says in other professional bodies people are referred to as ‘shysters’ or ‘hacks’ if they breach the confidence placed in them. As an example of good professional practice, Matthew describes a lawyer who would drop a case rather than compromise their counsel.

Whether the pressure to ‘get things done’ is internal or external to our engineer; let’s assume for now that they want to do the right thing.Our hypothetical engineer may choose to leave as in Matthews’s example of a lawyer but he then faces is the ‘better the devil you know’ dilemma (fear of the unknown). Another solution may be to find technically competent teams in their organisation who create a professional environment.

The strange thing about these questions of practice is that we all know that time invested in testing and other code hygiene issues pays off even in the relatively short term. Take for example the data from InfoQ that tells us "defects per thousand lines of code, decreased between 40% and 90% relative to the projects that did not use TDD"[6].

In his article Matthew goes to to say "the solution is not to try to measure the debt. If you do that, you’ll take a proxy measurement, which the team can exploit. More time spent measuring more things quickly becomes a death spiral" [1]. Intuitively the only way to avoid an ever growing debt is to avoid it in the first place; this seems like your mom telling you to save for things rather than taking a loan, you know you should, but few do. Another perspective from Ben Scofield is that "adequacy is very interesting. For one thing, adequate performers win more often than they lose" [5]. Given how seductive the allure of ‘winning’ is, the problem becomes how to avoid needing a hero complex in order to do the right thing.

Matthew’s reference to the ‘zero sum gain’ principle evoked another old favourite: the no win scenario. The answer could be the ‘change the rules of the game’. This is mentioned as a solution to the ‘no win situation’ [2] popularised by (among others) the character James.T. Kirk in the fictional Kobayashi Maru training simulation [3]. Try imagining a ship full of software engineers in the same simulator saying ‘sorry guys - we have a deadline so you’re just going to have to sort out your own life support problems’.

To understand how to change the rules of the game first we must change ourselves and our comprehension of the situation. One technique that I found useful is described by Andrew Hunt and David Thomas in ‘The Pragmatic Programmer’ as ‘Tracer Code’. The idea is that you change the assumptions of what you have to deliver in order to learn more about what it is you are trying to build [4].

Ultimately the answer has to be to find a way to avoid stepping on the slippery slope of saying something is ‘done’ when it is not finished. As Matthew says at that point you are a few measure-and-manage steps away from a death spiral.

References:
[1]November/December 2011 Better Software, P18: 10 Thoughts on Technical Debt by Matthew Heusser.
[2] http://en.wikipedia.org/wiki/No-win_situation
[3] http://en.wikipedia.org/wiki/Kobayashi_Maru
[4] http://pragprog.com/the-pragmatic-programmer/extracts/tips
[5] http://pragprog.com/magazines/2010-08/in-defense-of-mediocrity
[6] http://www.infoq.com/news/2009/03/TDD-Improves-Quality

Thanks to Julian Harty for his editorial input.

The art of refuctoring

I recently saw @jasongorman present at JaxLondon on refuctoring. Unlike refactoring you try and reduce the readability of code to make you indispensable to your employer.

Here are my top ten 'refuctorings' in no particular order:

1. Prefix all class names with the name of your employer and at least one TLA.


2. Include @note comments in your file stating that the code must be thread safe. Then implement it in a way that is unsafe for multi threaded use.


3. Prefix all member variables with either m_, s_ or p_, try your best not to follow the convention for their meanings i.e. use s_ (static) on non static private member variables.


4. Make sure that you inherit all of your member variables from a parent class.


5. Use bit level logic as much as you can, especially in application high level application code.


6. Only write a comment if it is misleading: Include jokes like 'this method could blow our memory' to make the caller think twice before using it.


7. Copy and paste public static methods between classes, take the time to rename them, reformat the layout and generally make it hard for static analysis to realise it is the same code.


8. Avoid using brackets on if statements, just indent code after the first line to make it look like it is part of the if block.


9. Optimise your code by manually in-lining supporting methods to increase the size of your code. Don't forget to take the time to change the variable names and layout.


10. All methods should be at least 500 lines with fully expanded if statements nested as deeply as possible. If you have some if statements in your pre-amble of a method why not repeat those tests throughout the code.

The most important thing to remember is that you need a really good unit test suite so that you can make all of these changes, safe in the knowledge that you have not broken the code.

The idea of the exercise is to try and make you think of ways that you could make code worse without breaking it. It is amazing how many anti patterns you can come up with as part of this exercise. I can highly recommend the session with Jason.

For more information on the courses Jason offers see his website Codemanship

Open source accessibility testing library

Website testing and accessibility have been interests of mine for a while and over the last couple of months I have been supporting the web accessibility testing project: I helped develop a core rule set of automate-able accessibility issues based on the WCAG standards and Open-Ajax in Java.

One of the key criteria for the library was for it to be used in a number of different environments like WebDriver based automated tests to inspect dynamic page content or static analysis of crawled pages running inside a map reduce job.

If you're interested in getting involved or using the library please contact us via the project page.

Back at the yoke

Last weekend I finally got around to taking a flying lesson that I was given for my birthday last year. It was actually Friday and I think everyone in the south of England was thinking about being outside. It was a very good day for the time of year: I think the next day set a new record high temperature.

I haven't flown for a while so was pretty excited. The flight took us south east over the Thames estuary. The visibility was great and the feeling of being back in the air was awesome. I have always thought flying was as close as you can get to a state of divinity.

It didn't take me long to remember my turning skills, the glider lessons really helped. In no time at all I was pushing further over, going for the 60° turn which is 2G. I was having way too much fun to take pictures unfortunately so these few are all I managed.

In such a small plane the turbulence was quite noticeable but meant I had to learn to let go of the controls and let the plane find it's way.

The school was really helpful at giving me all the information I need to understand what's next: the sky's the limit

Learning to turn with the California Superbike School

A couple of weeks ago I took a training course with the California Superbike School. Before arriving I had some apprehensions but they were quickly dismissed.

The level 1 course which I took covered throttle control, turn in points, fast turning rider input and riding lines. I have to admit that before the course I thought my riding was pretty good but during the interaction with my coach 'Hollywood' I was able to unlock a totally different level of riding. The overall effect was that I was more controlled and confident mid corner; the changes in turn in speed and turn in point also made a huge difference by increasing my confidence in the bike's ability to turn in fast.

I would seriously recommend the course to anyone who like me lives in the saddle. I haven't had any track time before but I think that might also be about to change.