reading

software architecture reading list workshop teams

Fairbanks: Just Enough Architecture

https://www.georgefairbanks.com/assets/pdf/Haiku-tutorial-2011-06-24-final.pdf

^^ this is A++, but ignore the OOP-y references for now.

Don't buy Fairbairns book, I can lend you mine, just ask

The Mythical Man Month

i personally didn't like it but everyone else did, you'll find it by googling it's super famous

Evolutionary Design

Continuous Design
https://www.industriallogic.com/blog/evolutionary-design/
Fitness Functions

A fitness function is a particular type of objective function that is used to summarise, as a single figure of merit, how close a given design solution is to achieving the set aims. Fitness functions are used in software architecture and evolutionary algorithms (EA), such as genetic programming and genetic algorithms to guide simulations towards optimal design solutions.[1]

This sounds like bullshit but ok, maybe i didnt understand it. I've seen a lot of attempts to reduce product design to mathy scientific mumbo jumbo, none ever made sense to me and none stuck around for too long either.

I think some people start looking for a problem on which they can use their solution, often thought beforehand.

Like "I have a hammer and only a hammer, so can you find me some nails?"

It reminds me of this guy: https://www.youtube.com/watch?v=2YPy5F0VJ38

if this stuff worked, we would have automated product design decades ago.

I don't get it is my answer but if you wanna read it go ahead.

Worse is Better/New Jersey style

Richard. P. Gabriel the originating essay, 1989

Set of philosophies that treat the YAGNI and KISS principles,
as must haves requirements troughout the entire lifecycle.

There are arguments against it, obviously, which should also be enumerated here.

this is about not complicating "stuff" too much.

Example: why are you using object-orientation in a small utility tool that generates some files? hack up some functions together and be done with it.

ok long story short, this essay is very fundamental to what I was saying about your job being to manage a complexity budget. I love the concept, personally, but there isn't a right or wrong. It's 2 different schools of thought. Pick one you agree with.

I agree with simplicity being paramount in every aspect. Sure. The issues with complexity are 100% valid. Its also 100% true that we create our own problems.

But these arguments fail for me when the discussion is about product. simplicity is often the result of extensive iteration sometimes to the point of obsession. Simplicity and time spent are often opposed to each other.

Its easy to make something complicated (very easy) but hard to make something simple.

Without a doubt I agree with the sentiment that we're doing WAY too much, but my main complaint is about process, not product. If you disagree say so in the next workshop and explain why.

this is perfectly valid: "i think we dont have enough process for XYZ" reason. its better to be wrong rather than not voice an opinion, esp. in the workshops. A lot of the stuff i say in the workshops are half-baked thoughts of my own.
dont assume i know what im talking about all the time. i dont.

just make sure its an opinion , dont waste time debating stuff you agree with just for the sake of it

Grug Brain

Carson Gross A* content on pragmaticism, amazing article throughout.

follows on the Worse is Better/New Jersey style described above

Don't let the Architecture Astronauts Scare You

Joel Spolsky, 2001

Articles

Locality of Behavior

basically making a case against DRY.

This is a very high value point. Easy to understand and super helpful. I agree with it 100%.

ok, ever sat down to review someones source code and you're like jumping from one file to another for each and every minor crap? this is what they do inadvertedly - and because it's baptized as DRY - it slips through the review and eventually the project becomes really tiresome to look at. An inexperienced reviewer has no counterargument anyway. The entire structure "feels" off, overly complicated but it's hard to pinpoint exactly what it is.

DRY has tradeoffs that nobody talks about and it's actually this one. In tests, we err towards this concept very very heavily.

DRY is abused because it's a very simple concept with extremely well-defined boundaries. It's basically: "you see this? don't repeat it anywhere else".

KISS on the other hand is abstract - what does simple mean?

Simple might mean dropping Redis and saving data into the shareable URL.
Simple might mean sticking to monolith architecture instead of going SOA.
Simple might mean abandoning your project entirely and hiring a courier to transfer letters between the different departments, on a scooter. <-- this isn't nearly as funny as it looks like. In some cases it's actually genius

So, it's easy to say: ok if i never, ever repeat this piece of information = i don't suck

Often, it means you've been tricked by the thought police. It's unavoidable that you'll carry this belief for years because DRY argument are treated as religious texts. I've rarely read something that explicitly says "duplicate, it's fine". It's usually hidden behind phrases "be practical" or something similar.

take it from me: "duplicate, it's fine, provided you listed a reason for it".

this is ok: "hmm this is gonna have to be duplicated but its ok because its too much work not to"
this is not ok: "hmm we cant continue X or Y because its gonna cause us to duplicate data".

There isn't a policeman going around dev teams and arresting anyone for violating DRY.

Case in point: DevIQ has DRY listed TWICE!! with an article about it that sounds like it came from Jesus itself (Jesus worked at IBM before switching careeers to a carpenter):

https://deviq.com/principles/principles-overview

Again, the only religious text you need is: "everything is a tradeoff".

A good software engineer will balance LOB/DRY/SOC in a way that feels "good enough" yet never perfect.

This concept is similar but distinct from:

A) Intentional data denormalization
B) Excessive abstraction

Some blogs I've read have started calling this "denormalization" which is total horseshit, it's just code duplication that's imposed to them by the fact they moved to microservices and can;t easily apply DRY principles anymore, because everything is scattered.

Denormalization is a valid strategy for performance (and others) and also perfectly valid if stated as a tradeoff. Why wouldn't it be? Yes Im duplicating because its not worth it not to. It's valid as a tradeoff, just don't rebaptize it as something saintly becuase thats a slippery slope apart from really stupid.

BTW I'm confusing you a bit - Its actually very wrong to say youre denormalizing source code. There's no such concept but it's starting to catch up by people who just dont know what they're on about. I've done the same above but it's an oversight. To be clear denormalization comes from Edgar Codd's 3NF - Third Normal Form or something like that?) and its about data, DRY is about source code. While you can say i'm DRY-ing up the data (sure I get what you're saying), the opposite sounds really stupid, you can't denormalize source code because it can't be normalized - it sounds as "???" as

ordering a "drink but please make sure it's mixed up..."
"like what mixed up with someone elses?".

... It means something totally different.

Back to "strategic" code duplication (here, use this phrase instead :) )

Last notes on this: I can't put it in words but there are times that you just know you're doing every thing by the book, yet it feels wrong. you know intuitively that this is NOT it. If taken apart, the parts are all.. OK. But it just feels wrong. I have no opinion yet on this but try NOT TO get carried away with horseshit like Best Practices and trust your gut more.

This is on-point:

credits to Lea Verou.

To sum this up, you always have to "think for yourself". Everytime you hear someone senior yap about technical terms, wow this and wow that, you have to stop and think "ok you say big fancy words and big fancy concepts, but how is that helping MY situation?".

The fact of the matter is that only you have the full context, the other person doesn't care one bit about what you're doing, they're just yapping about stuff that they know about. Since you can't ask them to explicitly shut up, ask them to sit down so you can explain your constraints more and see if their concepts make sense. This is not going to happen and you can move on with whatever it is you're doing.

There's no wrong or right - these are absolute terms that don't make sense in the real world. There is optimal and suboptimal.

Last point:

A good indicator that you're about to see a trainwreck unfold right before your eyes is when someone new (senior) utters the phrase: "Hmm lets rewrite this in X", with X being something the person also happens to specialize in. There are cases where it makes sense to do so but they are as rare as a unicorn.

Next week workshop: