Longing for the good old days?

"These days it takes so long to make a simple change", a colleague of mine sighed. "CI takes forever. Then there's a linting error we have to fix. Or perhaps a failing test, or a new security vulnerability. And finally, deployment to production takes longer than it used to. I miss the old days."

It's true we have a lot of steps in our development process that we didn't use to have. These steps take up some of our time.

Continuous integration

For example, we didn't always have Continuous Integration as part of our process. Ten years ago, while writing tests was encouraged, running all tests was optional.

Later, we had a Jenkins server, which ran tests for us. But it was possible to merge code if these tests failed. Also, configuring Jenkins for a project was optional, and some work was involved.

Today, it's impossible to merge code if CI fails. Usually, that's a win.

Code style

In the old days, codestyle could vary per project, or even per person. A one line change could change an entire file, depending on how a person's editor was configured.

Using Black in all projects changed this: All code is formatted in the same style, making it easier to read. I wonder how we ever did without.

Of course, this will mean CI will fail if you put a comma in the wrong place. This may look stupid, but when you think about the benefits, it's not.

Test coverage

These days, most projects (especially the newer ones) have automated tests for all code we write. This means that tests will fail whenever a change breaks an existing feature. This is a good thing.

Sometimes a test fails not because an existing feature is broken by the change, but because the test is not clever enough. In this case, the test needs to be adapted. When 9 out of 10 failures are in this category, it may feel like the tests aren't helping, but they are.

Dockerization

Older Plone progammers will remember "buildout hell". Whenever you installed a project for the first time, there were extra libraries to install: For PDF creation, for (un)zipping files.

There was a lot of "brew install"-ing. There was also a lot of Googling, StackOverflowing and symlinking.

And when buildout did run succesfully, it took quite some time, as illustrated by this remix (first version by someone at Netsight, Bristol, UK) of an older XKCD comic: (source)

When we moved to Django, virtualenvs (or pyenv for some) replaced buildout. This was a lot quicker than buildout, but operating system requirements were still a problem.

Recently we have moved a lot of our development setups to Docker. This means installation is less prone to errors. In particular, operating system requirements are installed in the same way for all developers: In Docker, which is a big weight off our back.

It also means it takes a little longer to set the project up for the first time, as all dependencies will be installed in Docker.

Assessment

Looking back on these good old days, my impression is:

• We hardly wrote tests
• We had no Continuous Integration to run these tests
• We didn't enforce code formatting. So every other Pull Request was a mess of indentation changes.
• Discovering security vulnerabilities was optional. Upgrading to fix these vulnerabilities even more so.
• Installing a new development environment for a project ("running buildout") was a dependency hell. There were always libraries to install, or symlinks to be created.
• Changing one line of code in a complex codebase meant a chance that our customer would call the next day to tell us something unrelated had broken.
• To be able to sleep despite all this, we had to drink a lot of beer.

Would i go back to these days? Absolutely not.

Do i miss them? Yes, sometimes I do.