Rant/someone might just actually use your software

Begin Rant

2015-09: My observations of bad software is that they often exist as a fluke of nature, much like the platypus. As such, I have a word for fellow software programmers.

First, understand that when you write a line of code, there is the small, small possibility that your code will be running thousands of times a second on billions of machines worldwide. If that code is bad in some way, then you will be hurting billions of people and maybe trillions of dollars. Your petty mistakes can be magnified to unimaginable proportions. On the other hand, if that code is well-written, it will be consigned to the same fate as the elements that make up our universe, something so universe and so under-appreciated that it will be thought of as the air we breath. And everyone will breath a little sweeter air with each breath because underneath it all, your well-written line of code is making things work well and right.

Second, it doesn't matter what kind of programmer you are. In my experience, although professional programmers (both in mind-set and salary) write a ton of code, for some strange reason I don't understand, it seems the amateurs are the ones who end up writing immortal software. I don't understand why this is, but I suspect it is because the universe is here to remind us to be humble.

The conclusions of the first and second points are summed up in this way: Try really, really hard to write good software. And if you write crap software, please don't give it to anyone or share it.

Writing good software is very, very hard. We're all here to learn, and none of us have the final answer, but I hope you will make an effort to write good software. Let me give some tips.

Research

Holy cow! How many times do we have to re-solve the same problem? Go pull up Google or your favorite search engine and go find out more about the problem you are trying to solve. Trust me, the chance that you, a professional or an amateur, have found a new problem, or even a new *good* solution to an old problem is roughly 0. We have been coding for long enough, as humanity, that there really isn't much left to discover. 99% of getting the right answer is just doing what's already been known to work.

To put this in to perspective, imagine you want to become a top-rated chess player. What should be the first thing you do? Well, go play a few games of chess, and maybe you'll win, but you're not really at the level of top-rated players until you've learned about pretty much every significant game that's ever happened. You can't hope to compete with Magnus Carlsen until you've learned everything that Magnus Carlsen knows, and the vast majority of what he knows is the same thing that every other top chess player knows: How people have played chess for the past several hundred years.

Once you've mastered a particular problem, that is, seen how thousands and thousands of other people have tried to solve it, then and only then can you hope to find something new. Otherwise, you're pretty much doomed to do what every lesser chess player would do against Magnus Carlsen: Make a mistake that has been made thousands of times before, which Magnus Carlsen will happily exploit.

I understand that there is little hope for you, and amateur or a professional, to get to the level in software programming that you are something like what Magnus Carlsen is in the chess world. That's not the issue. The issue is that you can do some research, find out what our programming equivalent of Magnus Carlsen has done, and copy his moves, adapting it to your situation.

So when faced with a new problem that *you've* never seen before, go do a bit of research until you can learn more about that problem. Please.

Handle your errors well.

Murphy's Law applies here. Every line of code you write, something *will* go wrong. Maybe not in your tests or in the first ten trillion times the code is run, but one of these days, that problem *will* surface, and if your code isn't ready to handle it, *very bad things will happen.* There is a reason why Exceptions are such a powerful programming feature: They actually help with this problem. So learn about them, how to use them.

• When* (not if) something does go wrong, what is the right behavior? Here are possible things you can do, with commentary added by me.

• Stop. This is a really, really, good answer, and I think it should be the default behavior of all programs. When something goes wrong, and it doesn't know what to do, STOP. Yes, everything breaks, but it is ALREADY broken. Now the users of the software will see that the software is broken and they'll have to figure out why and how to fix it. So I suggest:

• Explaining WHY you stopped the program! This could be a simple log message. (You DO have a logging system, right? If not, add it right now.)

• Continue, ignoring the error. This is bad, and I mean, REALLY bad. If something is out of the ordinary, continuing along, especially without even noting the strange condition, is a recipe for utter disaster.

• Continue, logging the error. This could be the right decision. I mean, if I'm writing code that is calling out to other services that could be up or done, it will be unusual when one of the services is down. My code should note that fact, and then do its best to continue, particularly because that type of error is quite common. If I'm relying on a hundred different services, and they have a 1% chance of being down at any moment, then my code will never run at all until I teach it how to handle one of the servers being down.

Language Design / File Formats

Please, do not invent a new language. Do not invent a new log file format. Do not invent a new config file format. Do not invent a new text file format. Do not invent anything that has to do with storing or retrieving data. Just, no, don't do it.

I recommend:

• Using an embedded language if you need a new language inside your program. Lua is quite popular, and despite my hesitations to it, it is much better than other alternatives and probably is what you are looking for.
• Using Python if you want a "high level" language. Python is simple, it is adaptable, and you can plug in whatever you need into it.
• Using C for low-level programming. Do a bit of research to see how big projects use C, and adapt one of their programming styles.
• Using *ANYTHING ELSE* but a new programming language.
• Using Lisp if you insist that you have a new way to program. Trust me, Lisp can handle that "new way of programming" idea you have.
• Using JSON to store structured data. There is no reason to use anything else nowadays.
• Using JSON for config too.
• Using the standard log format for log messages for your language of choice.
• Using HTML, LaTeX, or some other common format for text formatting.

There are very, very smart people who know hundreds of languages who do invent new programming languages that try to fit a specific niche. You are not one of them. No really, you aren't. Because if you were, you would've stopped reading this a long time ago.

Free Software

Lots of amateurs (or even professionals) start writing code with the intent of becoming famous or rich. Trust me, I know you are, because I do it all the time too.

However, if you've ever been a user of someone else's code, you'll quickly realize that you'd like to make your own changes to it.

Please license your software with the GPL or similar. This is so that when you die, or get bored, someone else can continue to improve your software. If you don't, one day, someone will have to judge between using your code or writing their own, and they'll end up choosing to write their own software. All that work you did will be wasted.

So license your software with GPL. I know it means you're going to have a hard time making money with it, but really, the way companies make money with software is by holding the users hostage and then exploiting the fact that your software is useful for them. That's far more valuable than the software itself. Offer your services as a domain expert. Offer to write code for them for a fee. Trust me, once someone is your software prisoner, make their imprisonment as light as possible, and they'll actually thank you for it, and maybe even send you cookies and cash.

Comments?

Send me an email at jgardner@jonathangardner.net