Notes from building internal developer platform — Part 2: Giving developers super power
So, we’ve mentioned platform engineering, albeit briefly. And truth be told, it’s a wide domain and building it would be very contextual for every organization, though the goal could be a uniform one: improving developer productivity. So, how can you ensure that a platform can fully benefits developers who are its main users? In order to answer that, let’s step back and see developers’ workflow.
I propose a simple model to represent developer activity. This consists of 5 repeatable tasks that developers do on a daily basis
- Discovery: gathering information required to start writing code
- Build: translating requirements into code
- Test: testing the recently written code to ensure that it fits the requirement
- Integrate: build and deploy the code, to make it integrated with the wider system
- Verify: testing the recently integrated code, to ensure the functionality correctness
These 5 steps represents different domains and clearly depict how vast is the area touched by developers. And you could already probably started imagining that when we talk about “you build it, you own it” all these 5 areas should be touched by developers.
Now, here comes the tricky part. I’d argue that the key working area for a developer, and the main reason that a developer is hired by an organization is to do point number 2, and to some extent 3. The rest of the model is probably hard to be recognized by person with no experience in writing code, thus making it hard to reason about, even though these are valid points. But we can use this notion to reason about why we build developer platform.
Let’s get back to the original goal of improving developer productivity. Now, since we’ve acknowledged that the full value of a developer is realized in step 2 and 3, I’d argue that these are the main productive time of a developer. Thus, if you want to improve developer productivity, starting by reducing the time spent by developers to do step 1, 4, and 5, can be a great starting point. And yes, that’s where our platform can play fundamental part.
Acknowledging that each of these 5 points is huge domain on its own we can start the journey of building our platform by tackling one problem first, before expanding it to different direction. For example, let’s tackle point 4 of the model above: integrate. Problem wise, this could lead to 2 different problems:
- Writing YAML is prone to error, and it makes deployment process a long one, since I as a developer needs to constantly check and lint the file
- I have to constantly check the deployment status by switching between different views and when I found an error, I had to read the log thoroughly and often the solution is not straightforward. It’s hard to make deployment a fast process
As you can see, 2 different problem statements that could result in many kind of solutions. For example:
- Instant generation of deployment file based on parameters set by developers
- UI to trigger deployment with no file required to be written
- Easy to digest deployment status in UI, complete with next step guide
These are probable solutions to different problem statements. And you can see that the platform could end up in many different places, depending on our direction.
As you can see, we start to formulate platform as an abstraction of the infrastructure. Our aim, as the platform builder, is clear: to represent part of the infrastructure and make it friendlier for developers, so they can fully own the operation part of their code. But you may also notice that even after we outlined the domain where platform can play its part, the depth of the domain requires us to think carefully where we want to direct the development of the platform itself.
Product management to the rescue. More on that, on part 3 of the series. But if you missed part 1 of the series, do check it out.
