DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
11 Monitoring and Observability Tools for 2023
Learn more

A Ranking Order for Coding Priorities

Roger Hughes user avatar by
Roger Hughes
·
Mar. 26, 12 · Interview
Like (0)
Save
Tweet
Share
5.79K Views

Join the DZone community and get the full member experience.

Join For Free
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 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 Development 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...


1 Usually.
Coding (social sciences) Software

Published at DZone with permission of Roger Hughes, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Building the Next-Generation Data Lakehouse: 10X Performance
  • The Power of Zero-Knowledge Proofs: Exploring the New ConsenSys zkEVM
  • Authenticate With OpenID Connect and Apache APISIX
  • A Beginner's Guide to Infrastructure as Code

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: