Senko Rašić

A practitioning bit-shifting magician turned cat herder.

Is software development a proper engineering discipline? On one hand, it looks like it should be – computer science is a rigorous, hard, math-based science. The hardware is deterministic.

As anyone involved with the discipline will attest, though, it's sorely lacking. Just Google for “if programmers made ...” or “if software engineers built ...” for the cheeky, but not entirely untrue, comparisons.

Why are we so bad at it? Is it because we're really struggling to be something we're not? Or are there other reasons we're failing?

Let's do a cheeky comparison of our own.

Bridging the gap

Suppose you want to build a bridge. Right off the bat, you know a few things:

  • which two places across the water you want to connect
  • how many lanes and of which type (car, train, bike, pedestrian) you want to support
  • terrain on both sides and the weather patterns
  • typical building materials for the bridge and their properties

Based on this, you can design the bridge architecture. It'll probably go through a few iterations – maybe number of lanes will change based on the cost projections.

During the design, you'll never:

  • cheap out on the architects – it's vital you get this right and the design phase cost is small compared to the overall project budget
  • rush the design phase – most of the calendar time is spent chasing around stakeholders (getting people to decide on building a bridge in the first place, chasing permits, etc) so there's no need to rush the architects

Once everyone signs off on the plans, you know exactly how and what to build, down to the bill of materials. Then you go and build the bridge.

Once it is built, it is done, except for regular maintenance. The terrain doesn't change, the materials don't change their properties, and you definitely don't attempt to move the bridge or add another lane in a year.

You also don't expect terrorists to be attacking the bridge, and you usually don't account for once-in-a-thousand-years natural disasters. If you try to, you'll be accused (correctly) of over-engineering and being insecure. There are standard safety factors and you don't need to go over them except for a very good reason.

I'm not a civil engineering myself (I have a bit of background in mechanical engineering), but I don't think any would find the above description and assumptions wrong. Simplistic, yes, wrong, probably not.

In contrast, in software development you often:

  • don't know the exact requirements, or they will change throughout the development process
  • want to keep the software as configurable and adaptable as possible (no hard limits on the number of users or amount of data, for example)
  • can't account for all the differences in the platforms your software will run in (either native desktop/mobile, or across web browsers)
  • deal with platforms or frameworks that change rapidly and in a ways that make you rethink the design of your software
  • need to interact with poorly specified and/or poorly working 3rd party components (even if they work great, network stability can always be a problem)

What's more, with software:

  • we expect to need it to change – either to evolving business realities or to keep up with the underlying platform changes
  • we expect it to be reasonably robust against malicious attacks

In contrast to civil or mechanical engineering, when we talk about “designing the solution” in software development, we talk about having a high-level architecture with roughly fleshed-out components (what they are, what they need to interact with). It's not even close to the level of detail the architecture plans give the bridge builders.

This means that the design phase in civil engineering doesn't map to solution design in software development – it actually maps to the entire programming effort, which is the bulk of the work, cost and time in any software development project.

BRIDGE  |   Design   |              Building             |
 APP    |             Programming             |   Ops    |

Copying bridges

Ok, you build one bridge. How hard is to build another just like it? Well, you repeat the whole process again in its entirety. Hopefully you do reap some savings due to the fact that you're now more experienced and have established supply chain connections, but that's it. The majority of work is still there and if everything else stays the same, the budget won't be very different.

In software development that's – you just make (or deploy) a new copy. Done!

What does this mean for builders themselves? This means in civil engineering you get more money for building (executing on the plan), while in software development you get more money for developing the solution (the design part). You just don't hear about multinational mega-corporations of architects on a level with FAANG.

Interestingly, the multinational mega-corporations handling ops do exist (PaaS, IaaS, app stores). They combine infrastructure, distribution and operations – in our comparison, in the civil engineering world they'd be an amalgam of builders, utilities and shipping companies all fused into one.

Cost of failure

If a bridge collapses, that's a huge problem, even if noone gets hurt. If software malfunctions, in most cases it's not a big deal (sometimes it is and then it's newsworthy). More often, if it works but badly, people scrape by.

Nowadays you can even fix the bug and push an over-the-air update – no need to recall all the cars of planes you've built with the defect.

This means the cost of failure (either catastrophic, or failure to live up to the expectations) is much lower in software than in either civil or mechanical engineering. That again means the return on investment (ROI) on any effort mitigating that cost is small, discouraging spending time and money on it.

So software today is buggy becase it can be. It's slow because it can be. It's insecure because it can be. It's not due to any lazyness of programmers, incompetence of managers or malice of big bosses. It's how the world works – if you spend too much on quality where not required, your competitor can spend the same money to grow faster with no downside.

Yet it is not obvious that it is unequivocally a bad thing. Consider the failures of famous projects with (near) unlimited budgets and perfectionism, such as Duke Nukem Forever. It makes as little sense to overengineer a software product as it would be for a building. Tech moves at breathtaking speed, and we've come so far in just a few decades, because it often can “move fast and break things”. Software can be more adaptable and quicker to the changing needs.

As software becomes a vital part of more and more things in the real world, the costs of failure rise. Whereas you might be only slightly annoyed at having to restart your Facebook app, you really don't want any trouble from the software controling your two-tonne car while you're doing 80 on a highway.

If that means more software will need to move slowly and avoid breaking things. And maybe we'll be more like the bridge builders.

Internet, in 2018, was not a safe place.

By this I don’t mean spam arriving in our inbox, viruses or malware lurking in software downloaded from less-reputable places, or phishing sites masquerading as our favorite e-commerce platforms.

These risks are real, but well understood and widely recognized. However, in the past years there has been an increasing evidence for, and occurrence of, completely different kinds of risk that most of us online are exposed to.

Examples of these are pervasive tracking of behavior online, appropriation of personal data by the apps or sites we use, data breaches, and junk media optimized to maximize engagement.

Before I go over each of these in more detail, a disclaimer: I don’t think everyone’s out to get me, or that big corporations such as Google or Facebook are inherently evil. I do think that companies, big and small, are incentivized to behave in ways that create or increase these risks. That is, the default is to behave in a way that makes things worse.


Dispelling one particular critique of UBI

Universal Basic Income (UBI) has started appearing with increasing regularity in research and experiments all around the world (Finland, India, …Oakland?). Of course, the scheme has both benefits and drawbacks, its proponents and critics, but in the absence of experience from a large-scale long-running UBI program, it is hard to evaluate what would actually happen.


Voice-controlled AI assistants are advanced enough to be dangerous

Useful voice recognition, combined with AI capable of parsing specific phrases and sentences, is finally here. Amazon’s Alexa, Apple’s Siri and Google’s Assistant are showing us what the future will be like.


What Shellshock can teach us about emergent behavior

As I write this (September 2014.), the Internet is in panic over a catastrophic remote code execution bug in which bash, a commonly-used shell on many of the today’s servers, can be exploited to run arbitrary code.


Which is not to say you can’t make money out of it

A common theme nowadays in the open source developers’ circles is that you can’t live writing open source. There are sad accounts of people abandoning their (popular) open source libraries, frameworks or programs, because they suck too much of author’s time and with little or no financial gain. Others try their luck at Kickstarter or Indiegogo campaigns for funding a few milestones of their project, or set up a donation system via Gratipay, Flattr or Patreon.

This conflates several different approaches to making money off of open source, each of which requires a different way of thinking about how the money is related to the work.


How I accidentally quit Twitter and Facebook


This is an old article from my Croatian blog. It would lose much in the translation, so it is reposted as-is. To spare you the effort of learning Croatian: it chronicles my adventures in trying to purchase and furnish an apartment, in a manner similar to Kafka's The Trial, except there's a happy end and I'm not a literary genius.