Comment by fauigerzigerk | Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

Parent Full thread

>Perhaps software developers could learn something from the newer methods that replaced the "master builder" model in construction

I don't know. I get the feeling that large construction projects suffer from many of the same issues that affect software projects.

And every time something goes wrong enough to end up in the media, the reason is invevitably that the various contractors/experts didn't coordinate properly, that no one really feels responsible, that major design flaws were overlooked early on and now there's no way to undo them without going even further over budget. (Yes, I am aware of the selection bias)

Big projects are hard and their hardness increases disproportionately with size. If a project's goals are such that there can be no "master builder", then things become a lot riskier and they go wrong more often.

So I think what we actually want is a bazaar of projects where each project is architected and overseen by a master builder.

Like with the endless state vs market debates, it's always a question of balance, not one of either or.

What you're advocating for seems like a SOA (or micro-services) approach?

I agree with your reasoning. It resonates with what for example Richard Brandson says about companies: split them up when you reach ~50 employees.

By splitting large projects into smaller sub-projects, we've now created the need for a higher level master builder to oversee how the sub-projects integrate, haven't we?

>What you're advocating for seems like a SOA (or micro-services) approach?

No, I think SOA and micro-services are technical considerations that have relatively little bearing on division of labour or organisational/project structure. You can statically link a library created by someone you don't even know, or you could have one huge dysfunctional in-house team split up a monolith into fifty different micro-services without creating any new ownership rules at all.

So I think splitting up projects in smaller subj-projects alone is not good enough if all it does is create a deeper organisational hierarchy based on exactly the same command and control principles as before. As you say, it just creates new planning issues on the next level.

We need manageable units of planning, and we need to know when things become too complex for planning and require some principle of self organisation. The difficulty is that self organising systems are not easily steered towards a single goal.

It's interesting that you quote Branson, because the most important feature of a separate company is that it is a unit of economic responsibility and ownership. It usually serves more than one customer, unlike a micro-service that is a fragment of some in-house monolith. And it sets its own goals, mostly independently.

Yes, microservices merely shift the complexity into the "it's somebody else's problem" (to integrate all the services) corner.

The book "To Engineer is Human" by Henry Pertroski describes many, many examples of this. Every software engineer should read it.

Reply on news.ycombinator.com