On the nature of computing science (1984)

Complexity sells in terms of dopamine. "Look at this incredibly complicated thing I made, that I understand and you don't! Aren't I brilliant!" "You must be - I can't understand it at all."

People get emotional rewards from themselves from making something work that is at the limit of the complexity that they can handle. They often also get emotional rewards from others for making things that others can't understand. (They shouldn't, but they often do.)

I hate moat building. I understand why it exists, but I don’t have to be happy about it.

Absolutely! Curriculum driven development is a thing!

Time is one of the dimensions, but I often see (bad) designers to stick with the first idea they have (and if they are not very good, the first idea is likely very bad), then as the idea shows the weaknesses, instead of understanding what is going on, they invent more broken "fixes" complicating even more the original idea. So there is a multiplicative effect of this going on and on. This is why the 10x programmer is not a myth: it would be if we were talking about "I can do 10 times what you do" and that would be impossible if you compare a top programmer with an average one. What happens is instead that a 10x programmer just avoids design mistakes one after the other, so they find themselves doing less and less useless work that in turn complicates things more and so forth. Being a 10x coder is about design, not coding.

>> but are not given time to do good design

Most professionals have to wrestle with time constraints. Push hard enough and at some point the carpenter/doctor/civil engineer/whatever firmly says “no”.

What’s the difference in software that unbounded tech debt is permissible?

Clients regularly tell carpenters to “just do X” against the professional’s better judgement. The carpenter isn’t going to call the collapsing Jerry rigged staircase tech debt, instead they tell the client “no, I won’t do it”.

Our profession generally lacks sufficient apprenticeship. We could learn a thing or two from student doctors doing their rounds.

> People are very capable of good design but are not given time to do good design.

So they're only good in theory given infinite time, but not in the real world where someone's waiting to be able to use what they're working on?

My little observations is that if the business allows crap, then nothing will change that and you quickly end up in the oh so classic swamp job where mud is added slowly until a crisis hits, people grind enough to keep a customer and you get back to mud pushing. Even technically skilled managers end up playing this game and allow all kinds of mediocrity to take roots and then it becomes the group culture for a while.

> People are very capable of good design

When did people learn good design?

Now you have people like Casey Muratori who are selling simplicity, because with higher simplicity you can use a higher percentage of your machine's theoretical performance. Only in contexts where that's something people want - specifically gamedev.

The mindset is that simple is easy and easy isn't worth much, if any, money.

Any tips on getting better at design?

Unless you've asked for a limit increase _multiple_ times, I can guarantee you haven't reached the limit of step functions.

The default limits are _very_ conservative in large regions

(Admittedly, by the time you've asked for those limit increases you should probably reconsider what you're doing, you're bleeding $$$ at this point)

I think there complexity literally brings more money for the hyperscaler.

Serverless monolith ftw

It makes figuring out that the boundaries of responsibility in your app/org are poorly defined harder to address.

The biggest place I ever worked, I came to believe that their chaos worked because it was self organizing. They’d split a large project into parts, and the groups that didn’t work well would find the boundaries of their mandate constantly eroded by their more capable neighbors upstream and downstream from them. Eventually all the gaps would fill in, which is why the company worked. But it meant many orgs and applications did work that would have made more sense to be done at a different step in the process, if not for incompetence/bandwidth. Things would happen here or there not because of some waterfall design but because of where the task was in the development flow and who had more bandwidth at the time.

They kept a lot of old guys around not because they were effective but because they were historians. They knew where the bodies were buried, and who was the right person to ask (not just which team but who was helpful on that team). We had a greybeard who basically did nothing but was nice to be around and any time you had a problem he knew who to introduce you to.

    > Theoretically, microservices allow for each team to deploy independently

You can still do that with a monolithic codebase. A Google team published a related paper: https://dl.acm.org/doi/10.1145/3593856.3595909

    > When writing a distributed application, conventional wisdom says to split your application into separate services that can be rolled out independently. This approach is well-intentioned, but a microservices-based architecture like this often backfires, introducing challenges that counteract the benefits the architecture tries to achieve. Fundamentally, this is because microservices conflate logical boundaries (how code is written) with physical boundaries (how code is deployed).

What usually happens is the the same team ends up owning 5 microservices that all have weird interdependencies with leaky abstractions, shared code, and unwritten interface contracts between them.

I always view it as a very good sign when senior leadership is aware of Conway’s Law.

Easy decision to make if it's not your money your spending, I guess.

Composable single-purpose modules that communicate over a standard interface can be more easily achieved without involving a network and the complexity that comes with it.

The level of reductionism of that comment is honestly quite amusing given the topic. Maybe we can use it as an unintended warning of not going too far in the pursuit of simplicity.

Separation of concerns is the false promise of all these so-called "architecture patterns." Their advocates make you believe that their architecture will magically enable separation of concerns. They offer blunt knives to make rough slices, and these slices always fail at isolating relational concerns, inviting entirely new layers of complexity.

You had a relational database, designed to store and query a relationship between a user and their orders. Now, you have a user management service and an order service, each wrapping its own database. You had a query language. Now, you have two REST APIs. Instead of just dealing with relational problems, you now face external relation problems spread across your entire system. Suddenly, you introduce an event bus, opening the gates to chaos. All this resulting madness was originally sold to you with the words, "the services talk to each other."

Who ever claimed that REST services compose well? Because they can "talk to each other"? Really? Only completely disconnected architects could come up with such an idea. REST services don’t compose well at all. There aren’t even any formal composition rules. Instead, composing two REST services requires a ton of error-prone programming work. A REST service is the worst abstraction possible because it’s never abstract—it’s just an API to something extremely concrete. It doesn’t compose with anything.

Microservices aren’t micro. They’re hundreds of large factories, each containing just one small machine. Inputs need to be packaged and delivered between different factories in different locations, adding complexity every step of the way. This is what happens when enterprise architects "rediscover" programming—but from such a disconnected level that the smallest unit of composition becomes a REST API. Rather than solving problems, they create a far larger problem space in which they can "be useful," like debating whether a new microservice should be created for a given problem, and so on.

The same critique applies to "hexagonal architecture." In the end, with all of these patterns, you don’t get separation of concerns. The smallest unit of the architecture was supposed to be the isolation level where your typical problems could be addressed. But your problems are always distributed across many such units, making them harder to solve, not easier. It’s a scam. The truth is, separation of concerns is hard, and there’s no magical, one-size-fits-all tool to achieve it. It requires significant abstraction work on a specific, concrete problem to slice it into pieces that actually compose well in a useful and maintainable way.

This quote is often attributed to Mark Twain and Benjamin Franklin as well. In one form or another, it actually goes back to Cicero, who I believe is the earliest writer of this idea.

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." -Alan Kay

My beef with Kubernetes is how hard it is to run and how complex its configuration is. The thing it does is good but something much cleaner seems possible.

That syntax has a semantics -- or, if you prefer, that all useful algorithms have operations which require devices

Computer science is not constructive mathematics -- it is not mathematics at all, since `f(x)` means the spatio-temproral state `x` is operated upon by the IO/device action `f`