Language Costs

Different programming languages will affect the time it takes to develop a system based upon that system’s requirements and functionality of the programming language.  In some cases businesses will already have policies about what languages to use and some code may already be written and available under the organization’s purview.  Reusing and reworking code is common practice in the industry.  It can save quite a bit of time.

Not all languages are equal and not all languages are up to the task at hand.  Having clearly defined requirements for the software is important to ensure that the right language is selected for the task.  Some languages can be easier for humans to understand, but will come with a larger hardware requirement.  Just because the Raspberry Pi can run python doesn’t mean python is a low-level enough language for the high-calculation tasks you need performed.  You might just break your pi!   (BTW the Pi3 went on sale this week!)

I can’t help but think of a great article on coding from that argues in part that reducing the lines of code required reduces the amount of maintenance required in the long run.  Different languages will require different code length and each line of code has a maintenance cost to it going forward.  Code may perform a task, but it comes at a cost.  The cost of maintenance in the long run is a serious factor because when vulnerabilities are found they have to be patched.  Well documented code built for easy maintenance is important.  Target’s 2014 hack came due to a vulnerability in the HVAC system.  Whoever wrote the HVAC code needed to be able to get in there and close the hole quickly.  The code’s documentation must have been key in helping programmer’s patch the hole that cost them an estimated $200,000,000.

My final thought is on how the lifecycle of the language you select affects the product going forward.  Parse recently announced that it was closing shop, Apple recently open sourced Swift, and Microsoft has put .NET up on github.  In addition Docker isn’t just a thing now.  It’s a big thing.  When looking at how to build your tools the popularity of a current technology and its longevity not only affect the potential use, but also the potential for documentation as it’s being constructed.

You will hear me repeatedly argue for open source solutions in part because if an open source project ever dies on the vine, you can still recreate the technology to get your data back from the project (unless you’re yahoo and something bad happens while you’re compiling).  If you build on close sourced technologies you marry yourself to a company that may or may not be there.  You marry yourself to that corporation’s strategy tax.  If you go open source then you can jump into the driver’s seat when you see trouble ahead and steer your project to safety.