A Ranking Order for Coding Priorities

In my previous blog I light-heartedly asked whether or not you should tailor your coding style to suit the business domain that you’re working in. The idea is that different business domains will demand different things from their software in terms of coding style. For example, software written for the defence market must be robust as a crash may cost lives, whilst software written for a market that under goes constant legislative changes, such as taxation, must be written for maintainability, and in advertising, where the projects and software lifespan are short then software should be written to be reusable.

Although I’ve never seen it applied to business domains before, the idea of prioritising key traits in your coding style is not new. I first saw the idea in a book written by Steve Maguire, published by Microsoft Press in 1997, and called Debugging the Devlopement Process.

In this book, Steve discusses the idea of establishing a ranking order for priorities when writing your software. He lists what are his priorities and invites you to order the list to suit your priorities. His original list contains the following:

• Size
• Speed
• Robustness
• Safety
• Testability
• Maintainability
• Simplicity
• Reusability
• Portability

Now, in terms of the software business 1997 is a long time ago, styles change and languages are developed. 1997 was the year when the CD-RW drives and media were introduced, memory was expensive, processors were slow and the language of choice was C/C++.


Allowing for the passage of time, that fact that we Java programmers don’t usually consider size or speed and that Java is portable¹ then the list can be cut down slightly:

• Safety
• Testability
• Robustness
• Maintainability
• Simplicity
• Reusability

The next thing to ask is whether such a list is still applicable today, so taking each item in turn...

Safety

In listing “Safety”, Steve was really thinking about programming paradigms and algorithms. Some techniques are safer than others; for example using a look-up table to return a value is a safer approach than using a logic-driven approach that calculates the value for you. This idea still appears to be a valid design consideration.

Testability and Robustness

To me, these two items belong together. Well tested code is by definition more robust. If you’re using Test Driven Development (TDD) then you may as well cross these items off the list as they're ingrained in your process. If you’re one of the large band of programmers who don’t use TDD - and there are lots around who don’t - then these items should remain...

Maintainability

I guess that this alludes to the style of your code, the clarity of your thinking and how well you can express yourself. In terms of style I generally use Uncle Bob’s as described in Clean Code, which I’ve probably mentioned before as being one of my favourite books. Uncle Bob’s style is... well, clean. Methods and classes are short, they obey the SRP and they’re cleanly laid out. This is still a key attribute of good software.

Simplicity

Should you aim to write simple code? The answer is definitely ‘yes’, that doesn’t mean you should write simplistic code, just the simplest code possible to get the job done without any embellishments, gold plating, or features which might be required in a future release. The idea is writing the simplest code possible has been taken to heart by the Agile Community, indeed Shane Warden and James Shore in their book The Art of Agile Development devote a whole chapter to the idea, which includes concepts such as “once and only once” and “you ain’t gonna need it”.

Reusability

I covered writing reusable code in my previous blog. Reusable code is a really good idea and still as relevant to day as it ever was.

In Summary

I guess that to summarize, you’d have to agree that things have moved on since 1997, but it seems to me that good ideas still prevail it's just that they’re expressed in different ways...

---

¹ Usually.