Blog Insights Want to iterate faster? Choose boring solutions
Published on: August 18, 2020
4 min read

Want to iterate faster? Choose boring solutions

We’ve released 106 times in 106 months, proof that boring solutions do work when it comes to software development. Here are some of our favorites.


bor·​ing | bȯr-iŋ

Definition of boring: causing weariness and restlessness through lack of interest : causing boredom : tiresome –– Merriam-Webster

At GitLab we’re boring and we’re proud of it. "Use the simplest and most boring solutions for a problem, and remember that 'boring' should not be conflated with 'bad' or technical debt," our handbook says. "The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology just to make your work more fun; using established, popular tech will ensure a more stable and more familiar experience for you and other contributors."

Although this may seem like counterintuitive behavior at a fast moving software startup, boring solutions are actually grounded in both science and history. Boyd’s Law of Iteration proves that faster iteration is superior to the quality of iteration. We feel like our history of releasing 106 times in 106 months also proves this point. We’ve managed to iterate so quickly month after month because we’ve chosen the boring solution.

If this isn’t enough to convince your team to choose the boring solution more often, we’ve rounded up a slew of boring choices we’ve made to help you make the case (and maybe speed up your software delivery).

Issue labels

An early boring solution was the choice to use issue labels to power lists on issue boards. Instead of creating a new system, the boring solution was to use what we had to make a small iteration and get entirely new functionality. (Candidly - this design decision has become a huge pain point, but it’s still a great example of a boring solution) –– William Chia, senior product marketing manager, cloud native & GitOps

Skip the new UI

We created documentation around using curl against API endpoints instead of creating a new user interface. –– Nicholas Klick, backend engineering manager, Configure

We chose to use a JSON Web Token to authenticate with Vault vs. building out a new UI or CLI. –– Jackie Meshell, senior product manager, Release:Release Management

Embrace a small change

We recently added awareness if a security scanner isn’t enabled from the project-level security dashboard. Previously there was no way to know this without going to the Configuration page. While it’s a small change, we’ve received good feedback so far, and hopefully encourages customers to take more advantage of our Gold/ Ultimate offering (and keep their applications safer!) –– Becka Lippert, product designer, Secure

Boring = less confusing

We spent some time and research deciding among multi-select dropdowns, single-select dropdowns, and plain dropdowns. It was a simple but effective process and prompted team member Austin Regnery, product designer, Manage:Compliance, to comment, “Before joining GitLab I remember reading this issue and being really impressed by both the boring solution and data-driven decision making.

Boring can also make work easier

We made it easier to read the title of an issue without having to scroll back to the top of the page. We initially proposed only the title would stick, but then we did a quick solution validation and found out the MVC was to include the issue status. We paired the first iteration back from a solution that would include other objects (like MRs, epics, etc.) and chose to scope it down just to issues. We also pushed back on making other elements sticky (like the tab nav) in the first iteration. –– Mike Long, product design manager, Plan & Manage

If boring doesn’t work, abandon it

In GitLab’s early days, we used Gitolite and the SSH key list. They were boring solutions. They were not elegant but allowed us to focus on adding value. When it no longer worked, we changed it. –– Sid Sijbrandij, CEO

Who needs fancy?

And if there’s any doubt that we won’t reach for something shiny when something simple will do, we’ll leave you with these two anecdotes.

We use SQL for the CI job queue. –– Stan Hu, engineering fellow

And, when we made the decision to move from Azure to GCP, we used the most boring solution ever – a checklist (no, really, a checklist) to help us make the process seamless. We made 140 changes to that checklist, all told, but after that careful process, we were able to migrate from Azure to GCP with no serious issues.

Read more about faster software delivery:

Pro tips for a faster CI/CD pipeline

Keep your Kubernetes runners moving

Get faster and more flexible pipelines

Cover image by Frank Vessia on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert