Why Do I Write Code in [insert language here]?

Starting this past Wednesday and continuing today (it will go on into next week if you must know), the frogs in my comic have hired some pythons to write software because they heard it was trendy. For the record, the Python programming language was named after Monty Python, not a snake, but that makes little difference when you are trying to select a language for a new project.

So the question is, do you pick a language to code in because it is practical or because it is popular?

And how do you even measure a programming language's popularity?

It turns out there are several groups that try to measure language popularity utilizing different methods. Take a look at the following...

• TIOBE Index
• Programming Language Popularity
• PYPL Index

So by most measures, Java and C remain very popular. It's important to see this in real objective data, because sometimes our understanding of programming language popularity becomes skewed by media attention. Often, languages that people talk about very much are used very little in production systems.

I found that all very interesting, but when I am starting a project (or re-starting, or upgrading) I try to pick the most appropriate language for the job. If there is more than one viable language for my system requirements, I pick the one that is most familiar to the team (which may be just myself). In other words, I tend to take a very practical approach to language selection.

Sometimes there is little choice. If you want to create an iOS application, your options are very constrained. This kind of specialization in certain product spaces is nothing new. When I was writing BBS Door Games in 1995, nearly all development was done in Pascal. I don't know why, I didn't really question those types of things back then. Of course, I only knew of 3 programming languages at the time...

Other times there is too much choice. If you want to build a web application, your options are nearly limitless. Personally, I have written REST web service applications in Java for a WebLogic application server and in JavaScript for Node.js. The JavaScript ones tend to be easier to write, but that doesn't mean that it's always the better choice. Knowing your particular requirements and the properties of a number of languages are the keys to making the right decision.

The take away from this is that if you want to be an extremely effective software engineer, you should be familiar with many languages and not be afraid to learn new ones. If you pick a bad one for a project, at least it's a learning experience. Don't make the same mistake again, even if it means learning something completely new.

Amphibian.com comic for September 26, 2014

Bad Requirements Create Bad Systems

One of the most important lessons I've learned as a software engineer is the importance of good requirements. Requirements definition is absolutely the most important part of a software development project. You can have the best engineers in the world but if your requirements are terrible your system will be terrible.

You might find other lists on the Internet of things that make requirements "good." I'm going to give you a list of what makes requirements bad.

Don't ever write requirements like these...

• Bad Requirements are Ambiguous. If you tell me, "The system should be able to be dropped from a height of 8 feet onto a wooden floor without breaking it," I will build you a system that will not break the floor when it falls onto it. The system, however, will shatter into a thousand pieces.
• Bad Requirements are Subjective. If you tell me, "The system should use pretty colors," I am not going to build your system. If you tell me, "The system should be fast," I am not going to build your system.
• Bad Requirements are not Testable. If you tell me, "The system should never crash on a Saturday afternoon," I'm going to ask you to watch it every Saturday to make sure it doesn't.

All of the examples I just gave could be rewritten to be good requirements. It just takes a little more thought.

• The system shall not break when dropped from a height of 8 or more feet onto a surface with a Brinell hardness of 1.6 HBS 10/100 or greater.
• The system should use only pink and purple as display colors for text.
• The system should process inputs at a rate of 3 per second.
• The system should have a mean time between failures of 87 days.

Remember, you can't build the right system from the wrong requirements.

Amphibian.com comic for August 15, 2014