Premature optimization is the root of all evil
This past week a valuable conversation came up with our DevOps team at Andela that I’d like to share here. For context, they were building out a method to automate our development environment using Ansible which is a fantastic tool and markets itself as entirely appropriate for this situation - so of course, they were a bit surprised when I kept questioning it’s purpose.
The ansible build scripts are a great MVP for this problem. It’s clear that you thought through a lot of the issues and chose tools that would be able to grow over time, handle a wide variety of use cases and allow for code reuse.
The reason I’m pushing on the decisions and asking lots of questions is because I know you all aspire to be great, truly world-class developers and I’d like to help you get there. Here are some things I would expect from a great developer on this project
Get something ‘working’ as quickly as possible
Software is a very unique type of engineering. It has more complexity than any other engineering field because that complexity is controlled not by the problem, but by the solutions we create. Luckily, software also has the fastest feedback loop of any type of engineering. We get to find out if our solutions work really, really quickly. Because of that complexity and uncertainty, we should strive towards the simplest solution possible. This means a solution that is easy to teach and easy to amend – and successful software is always amended. The next step is to flush out all the ‘real’ problems quickly and not worry about the ‘potential’ problems. The best way to do that is to create something quick and dirty that works, so that we can uncover any ‘real’ problems.
It feels like the dev environment consists of a VM, a couple of dependencies that can be all installed from one package manager and some repo downloads. From that, the simple, dirty solution that I can envision is a bash/python script that runs down the list and installs everything. Once that is working and is being used by developers, we’d be able to see what problems arose and fix them. If the problem was that the script was becoming too difficult to alter, I’d look into modularizing it. If the script needed rollback functionality because the developers that used it needed to rollback a lot, than I’d look into adding that functionality. If parts of the script needed to be reused for other new projects, than splitting up into reusable roles would make sense. All these added features could be done with confidence because we would already have a script that we knew worked and satisfied our customer’s needs - our customer’s being other developers.
There could be a moment when switching from a script to an ansible system would make a lot of sense because our script was in such heavy use. The key is that you want to feel that pain instead of predicting that pain because that’s how you know you’re solving a real problem and not just one that you think exists.
All this to say I am really impressed by your work on this. You’ve created a solution that solves a real need for the company, which is the most important thing we’ll do as a team. We’ll learn from this project, from each other, and from our users so that next time we can be better, maybe even great developers.