Uncle Bob Martin

I'd suggest going through all Uncle Bob Martin[1]s talks on clean code.

He has a great article (2014), old, on why you may not want to build that framework at all[2] too:

> Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. [...]
> And yet despite the huge commitment you’ve made to the framework, the framework has made no reciprocal commitment to you at all. That framework is free to evolve in any direction that pleases its author.

Another great source are the books, and/or youtube channel by Dave Farley[3]

What set me on a journey is -decades ago- the pain I, as a developer felt when developing web-applications for my clients. But worse: the pain they felt for getting delivered crap. "Why am I delivering crap" was the question that set me to research frameworks, languages, design patterns and architecture. Drupal, Rails, Django, ASP: I've worked with it, and delivered crap with it.

In general, I found that a framework matters. e.g. the simple act of reading ActiveRecord Critisism on wikipedia[4] got me thingking:

> also due to the strong coupling of database interaction and application logic,

This was true for project D, G and Y! This was why we failed to iterate at any speed at all. Because I can relate it immediate to Real And Actual Problems, Failed Projects, Slipped Deadlines, Burned out colleagues, and so on, all of wich I encountered during my…

I can't speak to the "need balls" comment, however he has multiple posts where he discusses types:

> You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?” Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python.

https://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html

He has another that is a bit less assertive and more just "types aren't for me": https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html

However I think it's worth pointing out, as a teacher, Uncle Bob seems to not have experience in many languages with high quality type systems and doesn't seem to understand types. He says "I prefer the flexibility of dynamic typing, and the ability to enforce types if, and when, I need such enforcement." As a Clojure person he's probably talking about what Clojure has which does not enforce types at all but really is just a runtime assert system.

The following is vaguely in support of types but it's mostly incoherent. Where is "The Dark Path" he refers to? He seems to have a very narrow view of types, no concept of "correct by construction" with an expressive type system. His go-to example in this piece is that enforcing a function is called with an "int" instead of "double" and then talks about how…

For those who haven't followed the story:

2007 - the Clojure programming language is announced by Rich Hickey and gains quite a bit of traction over the next 5 or 6 years. It never becomes a "top 5" language, but it could still today be arguably considered a mainstream language. It's been endorsed as "the best general purpose programming language out there" by "Uncle" Bob Martin[1] (author of Clean Code) and Gene Kim[2] (auther of The Phoenix Project, the seminal DevOps book). The fact that Rich spent two years working on it without pay and without the commercial backing many other languages enjoy is a real testament to his commitment and his vision. A Clojure-related emacs package[3] quotes Rich when it starts a REPL: "Design is about pulling things apart."

2012 - the Datomic database is announced by Rich Hickey's company. The database is praised for its ingenuity and its "time travel" features. It was designed to be deployed anywhere in the beginning, but, over time, it became difficult to deploy outside of AWS environments and even the AWS deployment path was quite cumbersome--the Datomic marketing page used to feature a maze-like diagram of all the AWS-specific features needed to make the thing work (it would be nice to find a link to that picture); I'd think most companies would have trouble digesting that and integrating it into their technology "stack".

2020 - Nubank (a Brazilian fintech backed by at least one US venture firm and a large production user of…

> Linux actually does have the flavour of problem the Clean Code is modelling here, and it does indeed solve it the way Clean Code recommends

Getting a bit desperate here, eh? On one hand, having tables of function pointers does not introduce any code constraints, you can switch to switches or anything else at a moment's notice; class hierarchies are much more rigid (some random Torvalds quote, "all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app"). On the other hand, Clean Code is fundamentally tied to OOP and classes. Here, straight from the horse's mouth [1]:

"This expectation of polymorphism is the essence of OO programming. It is the reductionist definition; and it is inextricable from OO. OO without polymorphism is not OO.
C and Pascal programmers (and to some extend even Fortran, and Cobol programmers) have always created systems of encapsulated functions and data structures. It does not require an OOPL to create and use such encapsulated structures. Encapsulation, and even simple inheritance, is obvious and natural in such languages. (More natural in C and Pascal than the others.)
So the thing that truly differentiates OO programs from non-OO programs is polymorphism.
You might complain about this by saying that polymorphism can be achieved by using switch statements or long if/else chains within f. This is true, so I must add one more constraint to OO.
The mechanism of polymorphism must not create a…

Will you grant that sometimes, they aren't?

It depends. Let's take a SaaS engineering department, for example.

If your customer base is tripling year over year based in the need of the market, you can end up with feature requests that would take decades even with an engineering team ten times the size. Those are often from sales on the backs of failed deals because the product didn't yet meet the client need.

If the goal is to keep the lights on and meet current customer need, you need a fraction of the total engineering team. However, we're on the message board of a venture capital site, so we can take an assumption of hypergrowth, as is the goal of a startup.

So, then, I'd argue that in growth scenarios, these people are required. That doesn't mean that they are being used the most efficiently, of course. I think this would be a main point of our disagreement.

That sometimes, the tail wags the dog and the staff and its culture determine the architecture rather than the reverse?

I agree. And some of that is the ZIRF culture as well. And I think we agree with the rest as well. However, I think I am sensing a separate point where I don't know if we agree or disagree.

Our field has not created the tools to scale from 10 to 100 or 100 to 250 well. The best tools that have been created to date have taken microservices as part of the orthodoxy. I don't think this is the only way to do it - Robert Martin has a good article here from a decade ago:…

I like the Uncle Bob explanation: the number of developers has a doubling rate of ~5 years due to the constant entry of new developers [1]. Over time, the number of inexperienced developers far outweighs the experienced ones. Inexperienced developers naturally gravitate toward complexity because they don't know any better.

Couple that with a social drift toward hyper-specialization. That sort of hierarchy naturally creates minds that don't think at the systems level. This is the general theme of Buckminster Fuller's Operating Manual For Spaceship Earth: the shift toward hyper-specialization (or narrow focus) has long-term disastrous consequences.

When you couple inexperience with narrow focus, you get messes.

Part of this is to blame on the industry-standard thinking that because someone works for Company X, they're a competent, logical engineer (and should be granted authority/responsibility over essential products/projects). This is the downfall of "code tests" and "whiteboard coding." They don't evaluate for systems level thinking and so a developer with poor creativity and logic skills slips through the cracks because they're great at eeking performance out of a function which impresses the lollipop guild.

[1] https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html