3 ms·

I’m becoming more sympathetic over time to the notion that this everyone-must-do-everything movement is basically a failure. There’s too much. Be good with: tw

I’m becoming more sympathetic over time to the notion that this everyone-must-do-everything movement is basically a failure. There’s too much. Be good with: two or three PM and issue tracker tools, a graphics or UI mockup program or three, various analytics tools and libraries, a payment system or three, several build and packaging systems, a couple reverse proxies, SSL provisioning, several ways to schedule jobs, a few message or event buses, a couple cloud management UIs (command line and browser!) and also WTF all the brand-names in there do, several major database systems with a few different query languages and paradigms, three or more programming languages for weekly use, various communication tools, your own command line environment, the typical environment on your deployment targets and there may be more than one of those, infra as code languages/tools, at least one CI system at any given time, git, the quirks and bullshit of dozens of major libraries across multiple languages, testing frameworks and practices, networking, and on and on. It’s plainly too much and functionally no-one’s doing all that well, which explains some of what we see from software in the wild. We could probably use about three specialist developers and a secretary for every do-everything developer like that.

sethammons 7y ago
It is easy to swing too much towards self serve teams. The separation that works well for us is the team owns the code, the emissions of artifacts like logs and metrics. Alerts and such go to the team. However, there is a team that maintains the build system. A team that deals with maintaining the monitoring systems, a team that deals with network, hardware, proxies, etc. For us, the one we are learning to balance is the data layer. We've traditionally had a DBA team doing most of that. But the team building the service knows their data better. We are shifting to a DBA as a consultant resource model and seeing how that goes.
rednerrus 7y ago
You're describing what Devops and SREs do.
- karatestomp 7y ago
  Yes, at places that have them and where those roles are well-integrated and their teams reasonably well run, which is... not everywhere, by a long shot.
pm90 7y ago
Do you think the complexity may be a result of the diverse ecosystem of technologies we find ourselves in today? Never before have we seen so many ways of doing so many different things. Every problem has an OSS solution, companies deploy variations of those tools internally. The problem will only get more pronounced in the future... there seems no escaping unless you restrict the adoption and usage of new technologies.
DrScientist 7y ago
Of course you need some tech stack discipline and the dev team needs to operate as a team not a bunch of individuals - the team has to be able to support the system if a single developer wants to go on holiday. A mess of a tech stack is more of a problem for developers making future changes than it is for production ( if you have fully automated the deployment, monitoring and service recovery ). ie the problem of a mess of a tech stack isn't due to being developer led per se, it's a problem of a lack of team working and organisation - which can happen in any team or situation.

sethammons 7y ago

It is easy to swing too much towards self serve teams. The separation that works well for us is the team owns the code, the emissions of artifacts like logs and metrics. Alerts and such go to the team. However, there is a team that maintains the build system. A team that deals with maintaining the monitoring systems, a team that deals with network, hardware, proxies, etc. For us, the one we are learning to balance is the data layer. We've traditionally had a DBA team doing most of that. But the team building the service knows their data better. We are shifting to a DBA as a consultant resource model and seeing how that goes.

rednerrus 7y ago

You're describing what Devops and SREs do.

karatestomp 7y ago
Yes, at places that have them and where those roles are well-integrated and their teams reasonably well run, which is... not everywhere, by a long shot.

pm90 7y ago

Do you think the complexity may be a result of the diverse ecosystem of technologies we find ourselves in today? Never before have we seen so many ways of doing so many different things. Every problem has an OSS solution, companies deploy variations of those tools internally. The problem will only get more pronounced in the future... there seems no escaping unless you restrict the adoption and usage of new technologies.

DrScientist 7y ago

Of course you need some tech stack discipline and the dev team needs to operate as a team not a bunch of individuals - the team has to be able to support the system if a single developer wants to go on holiday. A mess of a tech stack is more of a problem for developers making future changes than it is for production ( if you have fully automated the deployment, monitoring and service recovery ). ie the problem of a mess of a tech stack isn't due to being developer led per se, it's a problem of a lack of team working and organisation - which can happen in any team or situation.