Don't Create Brittle Software

Guest Author

Every developer is a software user/consumer at various levels, and I'm sure that every one of us has run into a dev tool, library, or component that left us cringing. Why is it so difficult to bend to our will? Why does it seem so broken? WHY DID IT STOP WORKING WITH THE LAST UPDATE???

User-facing software shouldn't break or perform in ways that are "ugly", and if your software is a library/component, neither should your API. Whoever your user is, updates shouldn't break things, and failures (of whatever kind) should be handled gracefully. For example...

If your software doesn't facilitate the user's activity, i.e. make it easier, it is at best sub-optimal and may even be unusable. If your library's API doesn't deprecate and migrate changes clearly and gradually, other developers may find it difficult or impossible to use as well.

User Experience (UX) is about so much more than a User Interface (UI). Whatever you develop should be clean, as intuitive as possible to use, and work in expected ways. Highly self-configurable (to the extent possible) is a huge plus as well. If you are developing a library or custom control, its value can be measured by two things:

  1. The ease with which it can be applied to and cover "default" applications (simplicity)
  2. The mechanisms you provide to cover edge cases or "the other 20%" (versatility/extensibility)

These two guidelines apply whether you publish your code as open source or not; after all, the goal of open source software is not to taunt other developers with what could have been and force them to do it themselves.

Keeping these things in mind can help a developer craft better software that is more useful to more people.

Just something that has been on my mind for awhile now...


Have a horror story you'd like to share? Please don't post names - no need for public floggings (!) - but if you have a particularly bad example that you use as a reminder to write better code, please share it in the comments so we can shudder with you. Misery loves company. :)

Join the discussion

Comments ( 2 )
  • Will Monday, March 31, 2014

    I suppose this a bit different than what you're suggesting, but what the hey; all the time I have to deal with programs that are so brittle that they break when you try running them on a modern system.

    I am currently working as a contractor for a large company that used some Java software. So I loaded up this software on my computer (Windows 7, Java 7) only to have it crash spectacularly. After some trial and error I figured out that it only runs on Windows XP and Java 1.4.2. Yes, it still requires a version of Windows and Java that were both replaced over seven years ago. Not only is it so brittle that I can't run it on my modern computer (I have to use a virtual machine), but it's full of confidential information that can be exploited by known security flaws that will never be patched.

    It's one thing to try to improve your own software and find out that a component you need is so brittle its dragging its feet. It's another to just use a mainstream operating system and discover your work-critical software is so brittle that it doesn't work unless you downgrade to something obsolete and insecure.

  • Mark Heckler Tuesday, April 1, 2014

    Hi Will,

    You've just touched on another way software can be brittle: by tying it so closely to a platform that changes to that platform are difficult, or even impossible. Java can insulate devs and their software from much of that, but throw in a bit of native code (or assumed security configuration, etc.) and bad things are always possible.

    Nice bit of detective work finding a stable (started to type "stale"!) platform on which it will run until it can be reworked. With Java 8 SE now out, you have some really great tools in your belt to use to do that. Good luck!



Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.