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 portable1 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...In taking my dusty copy of Debugging the Devlopement Process from my book shelf to remind myself of the author’s coding priorities list, I also scanned though other sections and chapters. It covers many topics on project management highlighting the mistakes that companies and people often make. The sad thing about this is that 15 years later, companies and people are still making the same mistakes...
1Usually.
No comments:
Post a comment