Laziness Oriented Programming — Good or bad?

It all started when I was trying to help a colleague to have her team’s system tests use a docker container for the database instance, it seemed easy but changing from a brew service to a docker container revealed hidden design and implementation decisions that made me start itching.

I remarked after a few hours that the system tests flow they had (which she did not design or build) was built by the principles of Laziness Oriented Programming.

I was pleased with my funny remark so I mentioned it to a few more people and was pleased by the giggles. But then I said: It’s not a bad idea, our entire profession is built by that, but sometimes it goes the wrong way.

In this post I will try to discuss why I think this profession is oriented by Laziness, what we should embrace and what we should not, no matter how easy or harmless it may seem.

Photo by Paul Hanaoka on Unsplash

Are we lazy?

Of course we are, technology gives users the option to get more and better services with less effort.

If I need to renew a prescription I no longer go to my family doctor’s office to get the piece of paper. I call or leave a message and I get the prescription in an app, which leaves my doctor more time to treat other patients.

Okay, technology is good, but as software professionals are we lazy? I say we are.

I am old enough to remember the days of manual tests which took weeks if not months to cover all the use-cases. Now, automation tests are in use, we created a whole new profession for that.

Pull requests are now expected to include tests, or at least have a good explanation why they don’t.

But let’s dig deeper, have you ever developed a mechanism because you were lazy? I have.

I worked on a backend system that needed to submit ML algorithms, per the user inputs. The only problem was that there were 6 algorithms and each algorithm had different inputs with a different development lifecycle, the frontend developer and I were expected to modify the web application and the backend every time an algorithm engineer changed a default or added an input field.

We decided we’re going to build a framework, the algorithms engineer is going to write a JSON according to the instructions we provided and commit+push it to our repository. The web application will render according to the JSON file, and the algorithm will be submitted accordingly.

It seems complicated, but it took each one of us roughly a week, including unit tests, and a nice feature that uses SpEL to inject data from the databases to the UI. We recognized an opportunity to build a framework that would allow us to do less work, and we also wrote something really cool.

What now?

The idea is to look for the patterns and repetitions, and see how you can serve a solution that can fit all the requirements. Look for comfort and ease of use.

Photo by krakenimages on Unsplash

Don’t open the champagne, laziness opens opportunities to great ideas but you should be careful-

• Not every problem needs a generic solution
• This is not a license to ignore tests or security

Not every problem needs a generic solution

Generic solutions are great, because they will cut learning the details of each implementation.

However, if you have a solution you’re considering using, you need to make sure:

• It serves your needs
• The overhead is worth the efforts it saves

If you need to develop a solution, you need to be much more careful-

• Carefully evaluate the effort
• Make sure it saves enough effort
• If competing solutions exist, have a good reason to write a new one (“mine is better”, is not a reason)

Don’t ignore the need for tests and security

We are often pressured to just commit+push the code without automated tests. I can understand the pressure to the deliver, especially since making good automated tests in CI is difficult-

You need to deploy and run your code on a machine you don’t have access to, and with many dependencies you don’t control. Who wants to get into that? But the alternative was me almost breaking production after I forgot to run the tests locally on a really small PR, luckily someone caught this before deployment.

Basically, when ignoring automation tests we trust luck or pray for some. While I believe there’s always an element of luck because not everything is worth automating, I suggest we strive to automation.

Even worst I often bump into passwords, ssh keys and production data committed into repositories. Praying nobody malicious gets access to it.

The reason is that it’s tedious to synthesize or mock data and keys. I urge you to remove all sensitive data from your repositories, use secrets, mocks, synthesize or cleanse your data.

This is a skill I encourage you to continue developing, learn-

• Writing mocks
• Using secrets
• Secure programming

You probably know this, but since I am often faced with frequent arguments I will now share how I attempt to address them-

• Nobody uses this key — You can’t be sure of that
• We will test this manually — Sometimes true, but if you’re working on a feature you know can’t be fully covered manually, communicate that
• We will test this later — Can we discuss when?
• I need to test a section that uses a key — use a mock, you probably don’t need to test that a 3rd party encryption library works, but that the outcomes are used as expected
• The codebase is secure enough — security breaches will happen, can you be sure nobody can gain access to your code?

I cannot claim I always convince my colleagues, and nobody wants to be the person who’s yelling that everything’s wrong. But if you feel strongly about it, don’t be afraid to voice your opinion.

Photo by Tingey Injury Law Firm on Unsplash

Laziness Oriented Programming — Good or bad?

We work in a profession that aims to solve problems, sometimes the public doesn’t even know these problems exist. To achieve that we need to be imaginative, and I suggest a bit lazy.

Laziness Oriented Programming should encourage us to write software that will deliver faster with less effort, but it should not push us to risky behavior.

I’ll close with the three great virtues of a programmer by Larry Wall, the original author of the Perl programming language:

1. Laziness
2. Impatience
3. Hubris

Personal note

I encourage you to write to me in the response section what you think about Laziness Oriented Programming, and some risky behaviors it can push us to.