Enterprise Integration Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

What Is Great Software?

  • submit to reddit
Every so often someone writes an article talking about what great code, or beautiful software, is (or insert some other superlative.) And, surprise! surprise! It always looks like just like the author's code! It's funny how that works out.

Let's take a more interactive approach today. I'm going to present a few choices and support them a bit. Then I'll ask you to tell me why I'm right or wrong, or if I'm simply asking the wrong questions.


Code that doesn't help anyone is just a useless exercise... or is it? Can a detailed and intricate bit of code written for a coding kata, an exercise, be useful? Or is it just thrown away?

What if the code itself is perfect, well written, in fact a great piece of work, but no end user finds it acceptable or usable? Is it still great code?

That depends on your definition of "great", doesn't it?

Automatically Tested

The longer I'm in technology the more I think this is a basic skill set. And I'm not talking about unit tests either. They have their place, but automated testing is much more than just unit tests.

Sometimes they're testing how five objects interact. Other times they're package level tests. Still overs are complete integration tests.

The goal is to have a test suite that provides sufficient safety to the developers, and have it run after every single code change. This size test suite won't be run locally by developers, so we use a continuous integration server (or a collection of them!), to run these tests after code is committed to a source code management system.

The value of having your own code tested after you edit is huge. Having that test run when your co-workers edit your code is invaluable. And having these tests in place when the code moves into production support, and later maintenance mode, completely changes the game.


No matter how large the entire codebase turns out to be, I like small routines, small methods, and small classes. Each routine, and each class, can be easily tested and fairly easily understood. This reduction of cleverness drives down the time needed to write the code, debug the code, and later, support the code.


I've seen lots of clever code. It's fast, when it runs. It shows us how smart the developer was. It also shows us that he or she didn't take the time to finish the job. We start with nothing, then build up the code, often reaching very clever solutions. But then only the truly clever go one step further and break it back down to its component pieces, making it simple again. The insanely brilliant skip the middle step and go straight to simple.


Are you the only one who can read and understand the code? Then it's bad. It might be the way you wrote it or it might be the problem domain, but I strive to create code that's human digestible. Computers are always running faster... my laptop has four CPU cores in it! But the human brain is still slow for this type of work, so let's be sure to optimize for the human brain (where it makes sense). Writing code that you or your coworkers can't read in a year isn't great code.

So what's your definition?
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Dimitar Dimitrov replied on Tue, 2010/05/18 - 4:50am

The article needs some Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} editing.

fred jones replied on Tue, 2010/05/18 - 10:46am

I think point 1 is so important that all other features pale in comparison. If a piece of software isn't useful then the other 4 points don't matter at all.

Perhaps you should have specified that these points are really from the developer's point of view when looking at his own or others' code. It's clear that these points aren't as important to end users of the software.

 I wrote down my thoughts on what makes a piece of software good. My perspective here is more as a power user than a developer. Both those perspectives are pretty similar when using someone else's software.   Obviously these are my own preferences and other people won't care about some of the points on this list, but I'd be interested to hear any commentary on them.

Jared Richardson replied on Tue, 2010/05/18 - 11:25am in response to: Dimitar Dimitrov

Mea culpa... that resulted from two copied spell checked words in MS Word. Word, then the DZone WYSIWIG editor hides the formatting from you, and I scheduled this article to go live at 3 am.

Lesson learned. No more Word for anything DZone related. Thanks for the catch.

Jared Richardson replied on Tue, 2010/05/18 - 12:40pm in response to: fred jones

Thanks Fred.

I do think the first person is the most important, but the following points feed into that. Maybe not for the first release, but for the product's lifetime. A buggy product loses it's usefulness fairly quickly.

Michel Ozzello replied on Mon, 2010/05/24 - 8:02am

Although it is a combination of Simplicity and Understandability, I think you should add a category to your list: Changeability.

This is not just about writing code. In fact it has to do with the way you architect your software (and the code you write to implement that architecture).

You need to make your apps (and associated code) changeable, and try to keep the cost of change as flat as possible, independently from the time that has elapses since you first started implementing your app.

One of the biggest issues of all development projects is that the cost of change skyrockets as time passes... and this is what causes many projects to be delivered off-time and off-budget.

Jared Richardson replied on Tue, 2010/05/25 - 4:35pm in response to: Michel Ozzello

Hi Michel,

I agree that changeability is vital, but it's also dangerous. You must be careful not to make your software overly configurable... then you end up debugging configuration files, debugging complicated inheritance hierarchies, etc. Making software overly flexible can make it overly complex.

Of course, that's no excuse for not making sure it's got the proper level of changeability in place.

I like to use test automation to ensure that the code itself is changeable. If you have a good test suite in place then it's much safer and easier to make changes to the code. If you make a mistake, it's not caught in exhaustive testing or marathon debugging sessions. It's caught by the tests (hopefully running in a continuous integration system.) The tests also help you write more flexible and reusable code. If the code is difficult to test, it's likely overly complicated already.


Michel Ozzello replied on Thu, 2010/05/27 - 4:34am in response to: Jared Richardson

I fully agree with your comments Jared.

When I mentioned changeability I was definitely not talking about configuration... I actually have a personal issue with configuration, and try to stay away from it as much as possible! :) 

Regarding testing, you're absolutely right. You need a solid testing strategy in place to ensure that your code stays sane as it evolves and is changed.


Mikael Couzic replied on Tue, 2010/06/15 - 8:26am in response to: fred jones

What an earthly, materialistic view...

I believe software development can be considered a form of art, in the sense that it is (for some of us) a never-ending quest for perfection and beauty. In that perspective, what makes great software is of the same essence that makes artistic masterpieces.

In another perspective, you can consider that great software is software that pays for your rent. A valid point.

Jared Richardson replied on Fri, 2010/06/18 - 11:25am in response to: Mikael Couzic

Hey Mikael,

Check out Maslow's Hiearchy of Needs. It sounds like you're on a higher rung than most developers. Until the rent is paid, art is a waste of money.

On the other hand, if you never make enough to consider art, are you really living or just surviving?

Mikael Couzic replied on Thu, 2010/06/24 - 8:05am

Well, I guess that means I'm lucky ! ^^

I guess the answer to the question "What is great software" is a reflection of one's answer to "What do you value in life", which means it's purely subjective.

I think my answer would be more objective if I was asked "How do you create great software". 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.