Rethinking the dev process at Dot Slash

If it does not scale, it needs to change.

For a company with 12 years behind the scenes development history, the prospect of suddenly making everything transparent is very daunting. Where do we even begin? All source code is hosted on premise. Projects are hidden under thick layers of old business logic and years of dusty code. Right now, business only knows one trick: Extend the existing system.

Although this strategy of extend and maintain is proving very productive, it really only works well for long-time devs. Any new developer has to at least have god-like intelligence to avoid breaking stuff. We are at a point where even small bugfixes can become case studies

Moving over is easy right? Just download docker and start building? Not exactly… you can easily end up with a brand new mess. I will leave actual architecture for a future article. Right now I want to focus on the general direction we are taking. Put simply, the plan has 2 parts:

Keep the new system open and accessible so that anyone can contribute

Instead of dedicating a team to only work on the new projects, everyone in the company can take part in development. Anyone who wants to at least. This will force us to make onboarding easier and ensure that development does not fall back into a closed loop. While we are at it, we are going to share some of what we build by open sourcing the reusable parts.

Build the project in such an order that we can benefit immediately

The last thing we want is a long running project that no one knows if it will work or not. If we can build something that goes into production in a few weeks, even if it has just a small scope, it will be much easier to see if we are on the right track. The idea is to release smaller increments more often.

I tried to keep it short, since most of the important stuff is yet to come. Feel free to follow along on the journey.