Program vs Software

TL;DR. No matter how hard you try to keep the best talents in the world, you win some, you lose some. Instead of falling into the “talent shortage” trap, out-teach the competition as DHH advised. Find the best software that suits the job. Software is for machines, programs are for humans.

More software means we SHOULD be able to write minimal programs.

When I was in college, my teacher asked “What is the difference between program and software”? I don’t remember my answer but in the 21st century, this question is still relevant as it was during the 1990s.

However, I still remember what my teacher told us about software: it is large-scale and being written by team of developers.

In this age of microservices (new term for the age-old concept of service-oriented architecture), we still face the issue of program vs software argument.

So what is the fuss all about?

I would argue that at the time of this writing (year 2016), the software industry is still young.


Because the software industry has still not figured out about FUSS!

F — functionality (is it working?)

U — usability (is it easy to use?)

S — security (is it secure?)

S — speed (is it fast?)

Granted, we have the Linux kernel that is stable and has and still serving thousands upon thousand of servers and mobile devices.

Granted, we have TCP/IP that is implemented across all operating systems and is the backbone of the Internet.

Granted, we have Go and Rust that are good examples of modern programming languages.

However, those are basically static software. The specifications are clear-cut. Sure there are a lot of moving parts but that is the nature of software.

For software that deals with distributed systems, this domain has yet to reach its full potential. You may list all the great ones (Riak, Cassandra, Docker, Kubernetes, Erlang and others) but still, they seem like islands that are great at what they do in its particular space.

All these great software are nothing if they are isolated and can’t talk to each other.

So we have JSON, MessagePack and others to wrap data in a certain format to make suitable for data transport.

We have ZeroMQ, NATS, Project Iris and others so we can orchestrate moving those data in and out of networks and applications.

We have configuration management so we can orchestrate the nodes (physical/virtual machines) that holds the infrastructure software.

We have container runtimes so we can orchestrate the containers moving in and out of nodes and networks.

All these are great and we are certain that we are moving in the right direction.

But still, working in the IT industry is hard, stressful and artificially complicated.

It’s because we are still harboring the bad parts that entangles the IT industry like the following:

  • ORM
  • Continuous Integration — CI is for software, not for programs and apps
  • class-based OOP
  • YAML — read the case against YAML at
  • Java
  • everything-is-a-container mentality
  • everything-is-a-virtual-machine mentality
  • APIs, APIs and a lot more APIs

You know what is sickening in the software industry? Everyone has an API. When you have a lot of APIs and haven’t figure out clear abstractions, the IT industry is going to be deluged with more and more APIs.

This trend is going to go on unless we design great protocols.

Protocols are the antidote to this never-ending flood of APIs. We don’t need more frameworks. We need more protocols that better address the issues.

So when I say the software industry is young, you should think of better ways.

That is, for the software industry to mature, we should be able to do the following things:

  • You can work at 8 hours max per day (or even less)
  • You can sleep without the dreaded on-call
  • You can debug your application or program just by using unit testing, not continuous integration
  • Unit testing is for small programs (microservices) and you can parallelize its development
  • Software is for heavy-duty tasks and is better left for large-scale team of developers (For 90% of users, you just write programs)
  • You orchestrate applications through messaging (like NATS or NSQ)
  • You orchestrate nodes (physical/virtual machines) through CLI tools (see POC here)
  • Containers are immutable. If it needs to be configured, you create a new one and throw the old one
  • In short, software do the heavy lifting. What is left are programs or microservices for mere mortals (so you can go home early and see your kids)
  • If you can make application development easier for programmers, there is a correlation that you can make operations a lot tenable for sysadmins (no firefighting required)

Subjectivity aside, leave a reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s