It’s a golden age of convenience and ease! The speed that we can get something usable up, working and deployed these days is incredible. The sheer amount of good engineering infrastructure we can take for granted is astounding – and that’s good.
In Deb Chachra‘s How Infrastructure Works she has a tricky definition of infrastructure that really works. Roughly it’s that “infrastructure what you can take for granted”. It’s the stuff you don’t have to think about. In my neighborhood, that’s a lot! I don’t think about water, light, heat, electricity, or food supply. At work, I don’t really think much about compute availability or disk availability – though I do have to design systems that use these mindfully at scale.
In software, there’s other kinds of infrastructure. Do you have to manually allocate memory? Do you have to destroy objects and free up allocated memory when you are done with it or does a garbage collector handle that for you? Do you have to optimize your control flow and loops or does an optimizer do an incredibly smart job of that for you? The more that there is good software infrastructure, the more you can spend time on the biggest difference maker for you – handling the business domain problems that you want to solve.
Old Man Story Time:
For my first job in NYC, I was given a C# code test. This was difficult for me, as I had no copy of VisualStudio.net available to me. Also, I didn’t know C# and figured it can’t be harder than C. I had to look up online manuals of C#, write the code in Notepad, and use csc.exe to test if it worked. A lot of what the test demonstrated was that I could write a for loop and that I was bull headed enough to push through obstacles and find out how to get something done. Now I write fewer for loops.
The last repository push I made I didn’t bother locally cloning – I was able to use the web based editor in GitLab to branch, make a change with auto-suggests, then commit, push and create a merge request. Unbelievably easy and cool.
But Jim Nielsen‘s Zero to Unmaintainable raises a good point:
There is such a focus on how quickly you can get going, but so little focus on how you maintain what you just created.
The developers I work with are so bright and smart and full of ideas. And they can get smarter, more reactive, better designed systems than I can think of up and running so quickly it’s astounding. But I see them frustrated, because they are held up by different things than I was. I used to get frustrated by the failures of the technology or the ability to even get simple things connected. They have best practices built into the new tools. But they are now frustrated by the organizational demands associated with new tooling.
Who will support this new application? How will we keep it updated? How will we secure it? When the APIs we interact with change, is this application well enough documented that someone else can fix the problem or do we need to take you off a project to fix it?
Part of my job is to help identify these issues early and turn them into infrastructure so that they can concentrate on the business problem and solutions to them – rather than these concerns. Instead of frustrated developers working out non-functional requirements, it’s better when we turn them into things they can take for granted.
This means working out commonalities across solutions we build for clients. Deployment’s a big one to get right once and then not talk about much. Same for version control. Same for dependency management and security scanning. Same for support after go-live. Same for maintenance. Same for self-service for clients.
The response to people being super fast to solve problem and come up with ideas isn’t to slow them down – it’s to solve the next bottlenecks.
These opinions are, of course, my own and published by me, not my employer.
