Talk: If you like it then you shouldn't put some code in it

Talk description

Title:	If you like it then you shouldn't put some code in it
Short synopsis:	Many people say that in the future, ‘every company will be a software company.’ Is this necessarily a good thing? Do we truly understand the implications of it? As people who build software, we’re nowhere near as good at building ‘efficient,’ ‘minimalist’ solutions as we like to think. In this session, we’ll discuss the merits of NOT building things. We’ll look at how we can maximise the amount of work not done by minimising the amount of human drudgery we create with our software. Max size: 500 chars
Long synopsis (optional):	In 1927, HG Wells wrote a scathing review of Fritz Lang's Metropolis, a film in which a peasant underclass toils in servitude to giant automata that keep a society running. Wells, calling Metropolis “the silliest film”, wrote that it anticipated “not unemployment, but drudge employment, which is[...] passing away.” He fundamentally disagreed with Metropolis's core thesis, that automation leads to drudgery. Seventy-one years later, low-paid armies of workers are employed by financial institutions, to manually enter data into five separate systems; and by social networks, to manually decide if images are too gory, or pornographic, to be allowed. Hospitals recently had to go back to paper for a day when an expired certificate caused O2’s mobile data network to stop working. Automation is here, and many of the new efficiencies have been trammelled by new drudgeries. Some examples are easy to mock. For instance, trashy and tasteless IoT solutions, such as the ‘simple’ bike bell that sought AU$85,000 of funding on Kickstarter in 2017, and would only work if paired with your mobile phone (which had to be charged and within range.) On our morning coffee break, we read the news about these things and roar with laughter. “Remember that awful Fitbit for dogs thing? They were running a six-year-old version of Android. Now they’ve all been pwned and made into a bitcoin mining botnet! Hah! What were they thinking?” Most of us will then walk back into the office, and proceed to make exactly the same mistakes as the people who make these terrible ‘connected’ cat litter trays and ‘smart’ toasters. As people who build software, we follow the same thought process every day. All of us are vulnerable to re-inventing the wheel, or building what we think is ‘clever’ or ‘elegant’ without considering what’s best for our customers. We see someone with a problem, dig into our toolbox of technical solutions, and try to sell one of them to fix it, even if it’s in a clumsy way. We also talk about technical debt a lot. Technical debt is, after all, just fancy terminology for stuff we did, and that we know is rubbish. The most effective way of avoiding technical debt is to avoid writing new code. The Agile Manifesto defines simplicity as “maximising the amount of work not done.” We take this to mean minimising lines of code, cyclomatic complexity, or the number of bugs we fix. Some people even use it to legitimise hacks, or “smashing it in.” I think this misses the point. Instead, we could prioritise minimising the amount of drudgery we create with our software. We could minimise the number of hacks or shortcuts our users have to use to get the result they want. And yes, sometimes this means maximising the amount of work we don’t do, by minimising the amount of software we build to solve the problem. Software is a lot of work. Building it, testing it, running it, supporting it, patching it, securing it, refactoring it: once you’ve gone down the rabbit hole, the maintenance burden can be enormous. After all, software means bugs; as soon as it connects to the internet, it becomes an attack surface. Maximising the amount of stuff not done isn’t a radical concept. Mechanical engineers know how important it is to reduce moving parts to a minimum. A bike bell that consists of a clapper striking a metal surface is less complex than a Bluetooth button/mobile app combination, and less expensive; it's also more reliable, and more predictable. “Less is more” is nothing new. This isn’t to say we should all pack up and go home, and never write code again. But we can, and should, do better than to trammel people with unnecessary new drudgery. We can think about this the next time we want to embark on a massive, all-encompassing refactor of an old monolith into hundreds of microservices. We can take a step back, and not waste our time on an ‘engineer’s solution.’ Max size: 5000 chars
Tags:
Speaker directory:

Speakers directory