[calineczka]

> an aggregate of much more sequestered small parts, each treated as a separate full product

What does it mean exactly? I feel you are trying to share a nice idea but I can't comprehend it. What are those small parts? Classes? Modules? Services? What does it mean to treat them as a separate full product within an organization?

[asdfman123]

One simple way of hermetically sealing organizational complexity: microservices.

Many people don't seem to understand when to use microservices. They're not for small teams.

I believe the real benefit of them is that you can have a team at say, Amazon, who works on their product prediction engine. They have well defined input data, and they have well defined data consumers need as an output. Beyond that, they just have to coordinate within their own team to build what they need to.

They don't have to meet with stakeholders across the organization and get into debates with ten other guys in other departments about adding a database field. They have their own database, of their own design, and they do with it what they want. If they need more data they query some other microservice.

[carlmr]

Not OP, but to me this is the Unix philosophy of having many small tools that work well and interact well.

Even if your modules are very separated, if you can't individually use and play around with them they become a part of a big blob of software. Services may be products, but only if they're idependently usable.

If you have a small product that's useful in and of itself (e.g. git) you can much more easily make it work well and then integrate with other good tools and replace those if necessary (e.g. if you have problems with Bitbucket/Jira/Confluence, you can switch them out for other solutions, e.g. Gitea).

But if you have a huge clomplex product then at some point it becomes organizationally impossible to move away from it.

[nradov]

The Unix philosophy is all well and good, but it's very limiting. There are major types of valuable software products that simply can't be built out of small tools or services.

[HeroOfAges]

While there are certainly many ways to build complex software, I haven't found composing a complex system from many simple and independent parts limiting.

[ChrisMarshallNY]

Exactly. It's just one way of doing things, and I definitely admit that some very good things have come from much more complex systems.

However, bug control is absolutely vital with these systems, and you definitely need some kind of quality-assurance system, or you will be hatin' life.

[anon73044]

Care to site some examples?

[Leherenn]

Anything performance related I'd say, e.g. stuff like games.

There are some overheads involved, and you lose optimisation possibilities.

[ChrisMarshallNY]

Exactly.

[ChrisMarshallNY]

TL;DR: Lots of small modules (they could be drivers or classes), with narrow, well-defined, highly agnostic intersections.

Most of my coding work has been done as a lone programmer. Even when I was working as a member of a large team, I was fairly isolated, and my work was done within a team of 3 or fewer (including Yours Troolie).

I have also been doing device interface development for most of my career, so I am quite familiar with drivers and OS modules.

When I say "sequestered," I am generally talking about a functional domain, as opposed to a specific software pattern.

Drivers are a perfect example. They tend to be quite autonomous, require incredible quality, and have highly constrained and well-specified interfaces. These interfaces are usually extremely robust, change-resistant and well-understood.

They are also usually extremely limited; restricting what can go through them.

The CGI spec is sort of an example. It's a truly "opaque" interface, completely agnostic to the tech on either side.

There are no CGI libraries required to write stuff that supports it, there's no requirement for languages, other than the linking/stack requirements for the server, etc.

It's also a big fat pain to work with, and I don't miss writing CGI stuff at all.

It is possible to write a big project his way, but it is pretty agonizing. I've done it. Most programmers would blanch at the idea. Many managers and beancounters would, as well. It does not jive well with "Move fast and break things."

But there are some really big projects that work extremely well, that don't do this. It's just my experience in writing stuff.

When you write device control stuff, you have the luxury of a fairly restricted scope, but you also have the danger of Bad Things Happening, if you screw up (I've written film scanner drivers that have reformatted customer disks, for instance -FUN).

YMMV

[winrid]

Based on my understanding a common name would probably be Slimlane, or Blade...