The Road to Computing

The road to computing is paved with dangers. Beware of pitfalls, potholes, ravines and disasters ahead. Even sacred cows!

Class-based OOP


The pitfalls of class-based OOP as mentioned by Eric Elliott does not apply merely to JavaScript but to all programming languages which support that paradigm. Golang eschew it in favor of interface-based composition. You may use your favorite programming language without classes, and you will be more productive. Read interview with Andre Staltz.

You may get to your destination with class-based OOP but the road ahead is riddled with potholes.

Agile methodologies


This is the danger you will get into when you ignore the primacy of individualism over methodologies. Software development, project management or the like is inherently dynamic and as such, demands more concentration than abiding by the rules of methodologies as if they are written in stone. The workflow of methodologies gets in the way of solving the actual problem domain which is more important.

Read Against Method by Paul Feyerabend



This is the consequence when you sell class-based OOP books and Agile methodologies to conferences and the entire market of gullible who cannot think for themselves. Looking for a full-stack developer is like looking for a unicorn, let alone a DevOps.

IT is 20% software development and 80% system operations.

The problem with the IT industry today is that, software are not yet mature. That is why the market is confused of the difference between software and program. Software, if you look into it, are really infrastructure software that powers the industry. It is the kind written by experts or those with considerable operations experience.

Program (or application) on the other hand is purely business. If you’re a business application programmer, you don’t need to learn low-level primitives like Golang channels. You may use event-based concurrency like what you can see with Node.js or EventBus. But if you insist, you may also use Golang context. But that’s about it.

So the long-term solution to the DevOps mania is for companies and the open source community to reduce complexity (engines) to software that is easy to use and easy to learn (usability) with minimal interface.

To illustrate, AWS doesn’t care about your apps. All it cares about is providing SDKs and 24 x 7 operations of its system.

Everything is a container


Make no mistake about it. I am not against containers.

The problem is when you think that everything is a container.

You see, using container is just one way of solving the distribution problem. Using virtual machines is another.

The trick is, use container or virtual machine where one is better for the situation, not because somebody else tells you to do so.

But you better be prepared when you use containers. You will reap the benefits of using container only if you reach the complexity being faced by PaaS providers or something of that scale.

Sure, there is virtual machine sprawl. But take note. There is also container sprawl.

There is no silver bullet.

API sprawl


JavaScript fatigue? Frameworks? Libraries? Modules? Packages? You name it.

You can see API sprawl regardless of programming languages.

In open source, it’s called diversity.

In business, it’s called fragmentation.

It is important to note what Jesper Louis Andersen had said about protocols, instead of APIs.

Protocols are far better than APIs because they invite multiple competing implementations of the same thing. They debug themselves over time by virtue of non-interaction between peers. And they open up the design space, rather than closing it down. In a distributed world, we should not be slaves to API designs by large mega-corporations, but be masters of the protocols.

Skills Gap


The industry calls it talent shortage.

Baron Scwartz calls it as a lie.

The so-called “talent shortage” is a lie — the real shortage is of companies that are willing to invest in talented people.

Flame Wars


This is the consequence if you don’t know how to differentiate subjectivity from objectivity.

It is Paul Feyerabend vs Karl Popper at best!

Ludic Fallacies


The Ludic fallacy is the misuse of games to model real-life situations.

In computing, we have two Ludic fallacies:

  • education-industry mismatch – IT education is broken. IT learning is mainly self-learning.
  • production environment in your laptop – oh c’mon. Do you really believe this? Even The Twelve-Factor App won’t be able to simulate your production system. Just watch Erik Meijer.

Fallacies of Distributed Computing


This is the ravine you will fall into if you believe those fallacies.

Sacred Cow


There is no sacred cow in the IT industry. The only cure to this malady is to think for yourself


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s