Layers in Software: From Data to Value | Hacker News Reader

Layers in Software: From Data to Value

blog.jessitron.com

104 pointsdedalus9 comments

Summarized well by these lines:

> Back in the day, front end, back end, operations, and DBAs separated because they needed different skills. Now we accept that a software team needs all the skills. We group by responsibility instead — responsibility for business value, not for activities

> We once layered by serving data to software. Now we layer by serving value to people.

This is a nice narrative for the rise of developer products, where there used to not be a market.

Andy Grove's High Output Management(hate the name, like the book) also talks about this tension between teams that focus on the business unit and the horizontal teams that support(if I recall correctly he groups in marketing, finance, and others) the business units.

You get large advantages in having teams built around specialized functions, however at the cost of lower cohesion.

Business verticals will trade all sorts of advantages for that cohesion.

There's tension in finding the right mix, the book covers it much better than I can but it's interesting to see parallels in tech stacks as well.

> however at the cost of lower cohesion

Is that cohesion within the team, or across teams (in the company as a whole)?

"Back in the day, front end, back end, operations, and DBAs separated because they needed different skills. Now we accept that a software team needs all the skills."

If the problem domain is adequately handled by generalists that's not a problem. But in situations requiring specialized skills it means needing to rely more on specialty contractors who keep your system from crashing when you go past the complexity threshold. As a specialist contractor it's very much in my interest to promote teams with "all the skills" because it means I won't be wanting for work.

IMO the argument isn't that you have 5 generalists, but rather that you might have 1 FE engineer, 2 software engineers a DBA and a Devops engineer (or at least 5 Software engineers that are more or less 'specialists' in those domains)

This allows you to have a self-contained micro-team that can approach each value-add opportunity from the perspective of the overall solution, without any of the bureaucracy of communicating with someone outside of the team.

Software is more than CRUD applications for business automation, but even for those, I'm not sure how accurate the characterisation here is, particularly regarding external dependencies. SaaS/cloud/this-week's-buzzword has done well for a few very successful businesses, particularly the handful of giants providing the infrastructure it runs on, but outsourcing everything you can think of is hardly universal.

Fluffy words. The developer version of the agilistas discourse.

> Interfaces between teams updated with every application change.

Dev products do not solve issues of bad architecture. It will be same struggle but in more strong form.

Also this comes to mind. Most of successful IT companies do not use external services for core components and prefer inhouse solutions.

Reply on news.ycombinator.com