My Thoughts on DevOps, Platform Engineering, and FullStack Developer
In the software development world, once in a while a new ideology or process or technology will be introduced. And, the whole developer community goes crazy on that shiny new stuff. A decade ago it was Agile/Scrum, then DevOps, then SRE and now Platform Engineering.
Somehow, I got curious about what is all the fuss about Platform engineering and read a bit about it, and I felt “Oh, people realized that DevOps is a good idea but impractical, and they are correcting it now”.
Though these ideologies/processes like Agile, DevOps, etc are created with good intentions, somehow they are misunderstood and applied wrongly and end up with not so good results.
For example, take Agile. It was supposed to be about interactions over processes, Customer collaboration etc. But the unfortunate ground reality about Agile/Scrum is all the rituals like daily-standup, backlog grooming, sprint-planning, sprint-review, retros and other gazillion meetings.
Same with DevOps. Every single DevOps book and conference talk starts with DevOps is all about culture shift, not about Jenkins, CI/CD and Kubernetes. And yet we have DevOps Engineer job openings in every organization.
FullStack Developer is another interesting thing. Now most of the people mention that they are fullstack developers, which is great. Even before this term became famous, people used to do fullstack development.
When I started my career in 2006, I used to do both front-end and back-end except CSS. There was a web designer who creates the skeleton with all the nice looking CSS, and we took the templates and build both back-end and front-end.
But back then, things were very different. To be a “fullstack developer” you just need to know one backend programming language, HTML, JavaScript, CSS and jQuery. We are good to go.
But now things are very different. JavaScript world is exploded with a billion new features, libraries, SPA frameworks, NodeJS, npm/yarn/pnpm, ReactJS and it’s 278 close cousins, NextJS and NuxtJS etc etc.
I didn’t feel learning some of these new things that difficult, because I didn’t have to learn them all at once. I learned one by one over the years, so it wasn’t that difficult.
But imagine if someone who is just starting their career and wants to be a FullStack Developer. The number of things they need to be familiar with is very scary.
Again, the theoretical idea of “FullStack Developer” is “who can build a feature end-to-end with desire to learn on a need-basis.” In theory, it is great, but in reality you have “jack of all, master of none” and your application code reflects the same.
Maybe this is ok for many organizations and for certain parts of the applications. I mean, maybe it’s ok if your UI created by backend developer is not pixel perfect. But, for some applications, maybe implementing UI with high-performance is very critical because most of their users use the application from mobile devices. In my experience, I have seen only a handful of people are actually good at both front-end and back-end development.
Now people seem to realize that “DevOps” is putting too much burden of both building the application and managing the infrastructure on the development team. Platform Engineering is to solve that problem where a team of people who are good at Infrastructure Management will build the infrastructure and Development team focus on building the application.
I believe letting people do what they do best in a collaborative manner is better than having “jack of all, master of none” fullstack developers building a mediocre application.
Just imagining, in a true Agile team:
- Have a Platform Engineering team who provide the necessary infrastructure for development teams
- Have backend developers who are really good at backend development
- Have frontend developers who are really good at frontend development
- Have a DevOps developer who coordinates with the PE team to do what is necessary to put the application in production
It’s just that you need to have (backend + frontend + DevOps developer) to be part of the same team. They need to work collaboratively instead of in isolation.
Isn’t that what Agile 1st principle is: Individuals and interactions over processes and tools.
Maybe in the near future, we may realize having developers with specialization working collaboratively is better than having developers who know something about everything but nothing in-depth. Who knows :-)
Related content
- Sharing Thoughts and Knowledge via Twitter vs Blogging
- Why I think Go is more verbose than Java
- Rethinking About My Social Media Usage
- Tips to work at traditional enterprise organizations as consultant/contractor (and save your ass)
- My Thoughts on CleanCode, Simplicity, Automation and Empathy