This is the fourth in a multi-part series that examines the negative reactions developers have to low-code platforms. If you’re a completionist like me, you will want to read the previous posts before you continue: Low-Code Replaces Developers, Low-Code is a Black Box Solution, and Low-Code is Not Code.
“Move fast break things,” is today’s de facto startup motto. The idiom implies that a few bugs are okay as long as you’re fast. Despite distancing the company from this belief in 2014, Facebook’s Mark Zuckerberg popularized this idea as a positive attribute of early product development. And the axiom remains: moving fast results in broken work.
Enterprises Are Fans of Moving Fast
In the world of enterprise IT, “breaking things” is rarely a desired outcome despite demands that software and applications be delivered as fast as possible. With thousands of dollars on the line, jobs at stake and professional relationships at risk, a broken release can cause irreparable damage. Enter low-code.
But if we associate moving fast with breaking things, the last thing an enterprise developer wants to do is move fast. Low-code’s key selling point, speed, is antithetical to an enterprise developer’s workflow. Naturally, when you claim to have discovered a tool that will increase your team’s throughput by 6 times, they won’t believe you. And if by some miracle, one does decide to believe you, that belief will fall by the wayside as it is replaced by the fear that moving fast breaks things.
Good, Cheap, Fast: Pick Two
Now even you may be wondering, is it possible to have both speed and quality at the same time? Yes, refer to this diagram:
Low-code platforms are not free, and far from it. The accelerated development cycles they provide come at a price, one they argue you will recuperate via reduced development costs and rapid turnaround.
But none of that matters to a developer, unless that developer is a leader. What matters to the developer is the analogy they’ve applied to fast development: it can cripple a product. And this belief goes much deeper than Mark Zuckerberg’s callow slogan.
The belief stems from irrationality.
Hard Work > Smart Work?
In Oliver Burkeman’s piece, Nobody Cares How Hard You Work, he argues that many among us fall into the “Effort Trap.” The Effort Trap is the belief that if we work harder or longer, we provide more value. And this belief extends to the evaluation of employees.
In the sharpest example, he cited Dan Ariely’s story of a locksmith. This locksmith was well received by his customers as a rookie, but not as an expert. As a beginner, he spent superfluous time fumbling with locks and even damaging property. Customers forgave him because he had “worked so hard” to help them.
But as his skills improved, the effort and time required to help his clients shrank to nothing. A job that used to take an hour, he now completed in minutes. Despite charging the same price, customers were dissatisfied with the snappy service they received. The job appeared trivial, so clearly they had overpaid.
Watch the Contributions, Not the Clock
You might agree with that sentiment, too. “If it takes him no time, why charge so much?” That’s the Effort Trap talking. If you had to choose between slow, labored, error-prone work or quick, precise, and accurate output, at the same cost, the choice is patently obvious.
And if you put two-and-two together, you’ll realize that low-code platforms like OutSystems promise to help developers crack thousands of locks each day. And if those developers are neck-deep in the Effort Trap, they won’t trust those claims. “If it takes no time, it doesn’t do much.”
The Effort Trap is pervasive across entire teams and organizations. If you put more emphasis on the number of hours employees spend at the office, the personal life they sacrifice, or the hours spent on call over the weekend, then you’re focusing on misleading performance metrics.
To pull developers out of the Effort Trap, zero-in on contributions.
Moving Fast Breaks Things Is a Myth
If your team understands that the ends are valued above the means, they will gain confidence in low-code. Working fast will come naturally, and so will finishing early. Don’t be surprised when they ask for more work to do or when they dig into that dusty backlog. Moving fast breaks things will have become a myth.
Thanks for following along with this low-code developer fear series! If I missed anything, leave a comment or let me know: firstname.lastname@example.org.