10 years of accumulated rants against division of labor in software: http://akkartik.name/post/division-of-labor

That was a great read and very stimulating. I am really into team rotations to avoid the tendency to specialise

Some of these quotes seem to be quite in line with what Casey Muratori get’s at in this lecture. Basically describes how code becomes slow through reuse and lack of understanding. For me I’m not sure if I agree, and I mean that literally. There are some of the quotes that resonate, but I’m not sure the common thread. Personally, I am not at all a fan of strict interfaces. I think modifiers like public and private are actually counter productive in a language. What I find much more useful are social and conventional ways of signaling what is and isn’t supported/expected. So I guess what I am often against is Strong and Artificial divisions. But I wouldn’t classify that as division of labor. Nor am I really sure how that ties up with abstraction, which seems to also be a focus. I guess what I’m looking for is why is division of labor undesirable to you? Obviously there might be lots reasons, but I guess I’m looking for the meta reason. Are there things that you value that you can’t personally get through the division of labor? Is it an argument that division of labor doesn’t work in the long run? Is it that there is a social problem? Regardless, interesting to think about. Definitely have not thought about these things in that frame.

I think there's a bunch of reasons that all point in the same direction. But to focus on just one: we keep having vulnerabilities and data breaches because the owners of complementary services made subtly different assumptions. Since my words are not working, how about someone else's? https://flak.tedunangst.com/post/features-are-faults-redux This seems sufficient reason all on its own to be mistrustful of service boundaries.

No apology needed. Definitely helps clarify some things. Your last point is really what I was a bit confused about as well. I do think npm is an example of division of labor. But so is intel and I don’t think I want to try to do their job myself :) I guess I’m just not sure I’m sold on the perspective because it seems to be about something pragmatic rather than principled, and I’m not sure I can agree on pragmatic grounds. There are all sorts of times where I want services. For example, there are coworkers I have no interest in directly working with. Working with them through the service boundary saves me my sanity. There are also things that I would rather depend on others on. Yes, service boundaries can induce problems with security. But division of labor also helps security tremendously. With modern js frameworks (ie, react) XSS issues are so incredibly rare. Something that was definitely not true in the past. But I think I’d even push a bit further. Many bugs that happen at service boundaries are because of one groups unwillingness to fully embrace a division of labor. Why is system A calling into system B? Well, because they want to be the central authority. They want to control things themselves and only expose them the way they want. Many times system A doesn’t actually rely on system B properly speaking, They just want to be the integrator. So I guess what I want to push back on is that it is the division of labor that is the issue. I think you’ve definitely recognized a problem. But is there a more precise or specific way of looking at it. If some divisions of labor are good, what makes them good?

I think that's like asking, "what makes some chess positions good?" The state space is just too vast. I can't tell you all possible good configurations. Instead, I've told you one property a lot of bad configurations have. And it seems valuable to point out because it's a property shared by almost all software today. This, right here, is the precise direction in which we need to stop digging. We should each create a budget in the number of distinct services we depend on. I don't know how to fit in that budget, that's open research. But we can also all go off and independently try to answer that question for each of our specific contexts. You don't have to wait for me to find you the perfect answer. And if you can't figure out how to deliver the service you want to deliver with fewer dependencies, don't ship. Wait. Think harder. Find something else to deliver. I feel fairly uncompromising about this. I don't really care what you as the application writer would rather do. I'm not trying to prevail on your preferences here. I'm making a moral argument. Now we know this is wrong. If we continue creating apps that depend on lots of dependencies and convincing millions of people to install them, we programmers are actively making the world worse. There is no defense for perpetuating a social arrangement this insecure. If we all try really hard and just can't come up with a way to use computers within this budget, then (I say this after going through the five stages of grief) perhaps we should stop building/using computers. If you don't want to do Intel's job, and Intel can't do their job, then we must learn to do without Intel.

I like this framing much more. I don’t think the argument really works on pragmatic grounds, so making it on moral grounds I think is much better. I will say, I don’t really think I’m there. I don’t really have a problem with relying on 10000+ people for computing systems. We rely on way more people for all the things we do day to day. We will historically always end up relying and vast numbers of people. I don’t think I could alone, or with a small group make a more secure computing platform without a division of labor. I just don’t see how that is possible. And since I think that ought implies can, I find it hard to think I have a moral obligation to do so. I think it is a fascinating perspective though and always enjoy these sorts of stark contrasts. I do think though we could do a good amount of work on figuring out what makes some divisions of labor good. I think we see that in society in general and I think we can find it here. Of course, no everyone will agree with our view of good, but that is just life. Here are some quick thoughts on what criteria like that might look like. First, I think that the division needs to be made deliberately. Accidental or unknown divisions of labor can’t be made rationally. Even if the circumstances turn out alright, I don’t think we can consider them good. Secondly, the division of labor must be chosen because it benefits the end-user of the software. Choosing to divide labor merely for convenience of the programming is not a valid reason. Third the persons/people the labor is divided with must be trustworthy and there must be oversight over the work of the division. Fourthly, a division of labor must only be made as a last resort when all other means have been exhausted. Not going to pretend these are the right principles. But I think something like them must be what makes the difference between a good and bad division. If not, it would seemingly be arbitrary and we’d be left without any guidance.

I think we understand each other!

We rely on way more people for all the things we do day to day. We will historically always end up relying and vast numbers of people.

I think software is fundamentally different from physical stuff. Societies have relied on fewer people so we know it's possible. I don't even think it implies a reduction in standard of living or quality of life when you can have vast quantities of automation managed by a small number of people. But I'm starting to repeat myself, so I'll stop there. Like I said, we understand each other.

• the division needs to be made deliberately

• the division of labor must be chosen because it benefits the end-user of the software

• the persons/people the labor is divided with must be trustworthy and there must be oversight

• a division of labor must only be made as a last resort when all other means have been exhausted

Awesome start! I obviously agree with the fourth point but with much higher standards 🙂 The other bullets I proffer the following criticism to: when I say "division of labor" I'm talking about a certain social organization that's more than just the combination of the words. Based on https://en.wikipedia.org/wiki/Division_of_labour and so on I weakly believe (I'm not a Marxist scholar) division of labor is by definition decentralized and emergent. There's no central entity being deliberate about decisions or deciding what benefits end-users. (Which is why I prefer the framing of end-user programming and dislike the word 'end-user'. Teaching people to locally help themselves and stop being users seems to go better with the grain of history.) Finally, oversight over programmers is a huge unsolved, likely intractable problem. I know because I'm a programmer 🙂 and I run rings around my "supervisors." I try to make ethical decisions but I'm also constantly making trade-offs that benefit me over the org, the org over the company, the company over its customers. It's very hard to believe some self-interest isn't creeping in. We need to think more decentralized. What does a cellular automaton where people make localized specialization decisions look like? How can we judge if a model is emergently yielding good or bad division of labor? If we could answer these questions we could run some experiments.