Project setup and developer pain
February 21, 2022
I've been keeping an eye on in-browser code editors and Integrated Development Environments (IDEs). Quite possibly one of the biggest pain points for developer onboarding is getting a project set up... I've seen many many experienced developers take days (sometimes weeks) to get an application up and running on their system.
There are a few approaches to solving this problem:
- Put in the time and effort to streamline initial setup. For example, one could write a detailed set of set up instructions, then slowly start to convert the setup steps into a series of small programs. Eventually, these these programs can be expanded to do the entire setup in a single run. (I think there's a discussion here around tooling for the setup as well: OS Package Managers (apt, yum, etc.) versus Language Package Managers (composer, npm, etc), shell scripts and batch files versus Domain Specific Languages (for the domain of application setups... I'm thinking of installers, perhaps PowerShell for Windows, maybe Brew for MacOS or MacPorts)... There are other tooling debates in this area I'm sure. The problem with this approach is that it takes time, the tooling is typically unfamiliar to the devs and can often involve a healthy does of system administration. The setup process is a one-time thing, and so teams often eat the cost of setup... They go through it once (maybe once per new dev machine) and never look back.
- Try to constrain themselves to an ecosystem What I'm thinking of here is, for example, using Ruby on Rails and avoiding problems and tooling that are not already out-of-the-box solved by the ecosystem. The goal here seems to be less about avoiding setup and more about keeping setup to the bare minimum, that is: You set up the rails enviornment once, and once it's set up you stay within it.
- Leave it to the dev to figure out. I think this often approaches the "detailed set of instructions" I mentioned above, but doesn't quite get there: The documents are out of date and don't address the latest releases of tools, or there are many "works on my machine"-type directions. (I've literally seen instructions that are completely reversed by subsequent instructions.) These teams seem extremely pain-tolerant, and will live with days or weeks of dev setup.
Why does all of this even matter?
I think the first-order effects get usually get dealt with. By first-order I mean: Management doesn't want devs wasting time doing non-billable work, or that technical problems arise when integrating work of developer A with work of developer B, who've somehow managed to have slightly different setups. The "leave it to the dev" culture signals that there's no need for efficiency here, and the one-time cost of setup can be absorbed. So my theory is that there are two groups of people for whom this is a real pain point:
- Freelancers and small consulting shops. These companies land squrely in the "time is money" camp, and having devs "waste" time on setup can mean the difference between a project that generates profits and one that does not. (I'm curious about the spectrum here... There will always be hand-to-mouth type operations, that run too close to the bone and are one project-gone-wrong away from going out of business. But certainly there must be a large group of operations that produce healthy revenue. Does that healthy revenue reduce/remove the pain of project setup?)
- Large companies who optimize for developer productivity. My guess is that they care about productivity as a recruiting/retention tool (keep devs happy) and as a way to lower expenses. My guess is that these compaies are mostly market winners, meaning that they can now turn their attention from growth-at-all-costs to optimizing their operations.