Intentional Code - Minimalism in a World of Dogmatic Design - David Whitney - NDC London 2023
Вставка
- Опубліковано 6 чер 2023
- A brief history of Design in software, reflecting on the history of the design patterns movement, clean code, and the long shadow they have cast over software development in the 2010s and beyond.
In this session we'll talk about intentionality in software design - and how you can radically simplify the way you build applications today to make them more meaningful to the humans that maintain them.
A radical look into why *every single character matters*, and why you should probably burn your copies of Clean Code.
Check out our new channel:
NDC Clips:
@ndcclips
Check out more of our featured speakers and talks at
ndcconferences.com/
ndclondon.com/ - Наука та технологія
Metalhead build, TesseracT shirt, voice like a Manchester professor, content like a seasoned veteran. Absolute legend.
body langugage of a dancing princess :) - ok, i exaggerated
My main realization as a programmer was the fact that I'm not obligated to follow any dogmatic principles, no matter how many people are thinking the opposite. My only obligation as a developer is to bring working, structurized and maintainable piece of software to the client - the tools and approaches to use is up to me and only me.
The more experience you have, the more you appreciate this. I also followed “clean architecture” and design patterns and multiple projects solutions with many projects which aren’t needed. In the end keeping it simple and readable truly works out for the best. Easier to maintain, publish and for others to get into.
Did you actually read "Clean Architecture?" because keeping it simple is key to the philosophy. This entire lecture was advocating clean.
@@7th_CAV_Trooper I don’t get much from reading, I get much more value from seeing examples and I’ve seen tons, many of those in companies I’ve worked for, some online. The lecture was advocating clean as in simple, organized and readable. What I usually see when “clean” is mentioned is overengineered solutions that noone would understand unless someone explains it to them and organized like the example from lecture - controllers, models, mappers, etc. and not by features - identity, database, etc. Also the horrible mess of millions of projects… the complications of calling 5 layers for a simple command… the onion graph from clean architecture is technically great, but I’ve never been able to switch something easily just because there was a separation like that. Big projects can’t switch the database provider or UI just like that without touching anything else. For example, database queries will always be fastest if hand written (complicated ones with complex joins, merges) so that means adapting the code to handle that. There are always some procedures and functions to rewrite and so on... There is also the epidemic of microservices where they aren’t needed. I understand using it for Netflix, but for handling few thousands of requests, there is no point. I worked for a company where we switched a project to microservices which was used by 100 people at most at once, usually 2-3. It needs to stop… sorry for rambling, but clean in my mind is what was presented here and not what many courses, youtube videos, blog posts, etc present. It is usually presented on a small project in perfect conditions, but in companies it is very hard to follow everything, especially with deadlines, these days there are usually updates that need to be pushed out every few weeks…
@@7th_CAV_Trooper The problem with books like "clean architecture" is usually not the books themselves, but the readers that feel to need to apply everything they learned, no matter if it's needed or not. My main pita is working with people that treat all the practices as a silver bullet, cuz hey, if it didn't work there wouldn't be a book about it.
@@7th_CAV_Trooper"clean code"(TM) is also said to be simple. objectively, it is terrible, because they write something like a class with 10 methods instead of 1 procedural function.
It's one of the interesting things about DRY to me - sometimes repetition is useful for making things clearer. We use repetition in conversation all the time. It helps trigger thr pattern-recognition parts of our brains. So sometimes a small amount of repetition is worthwhile.
Lot of wisdom in that guy :)
I've gradually realized that all I do at work is simply "fighting entropy".
This talk is sorely needed
We live in the Age of the cargo cult design techniques
Wonderful to see someone advocating for the visual flow of the code itself, as an element of readability and hence supportability. I wholeheartedly agree! But it can be challenging to achieve consistently.
This is the talk I needed to be inspired to throw away all the things I've been learning about design even though my gut and simplicity craving brain was screaming at me to stop. I can stop! I Can think outside the box now! And apply the philosophy which gets me to work fast and smart: think lazy.
Very interesting, new angles of looking on many things.
Wow! The advice of giving yourself more time is as brilliant as it is simple. This is something I was intuitively trying to do (if possible), but I just realized that when heard in this talk.
Indeed, and it's working. I'm doing it all the time, whenever I'm in between of tasks or in the middle of something that involves the previously written code, I'm just staring at it and listening to my guts, especially if I don't like particular part of code.
@@true_xander the only problem is that you aren't getting paid for this.
@@RuslanKovtun why do you think so? I'm paid for making stuff working, so starting at the code is essential part of my job. If my employer would expect me to only write code for 8 hours, he'd better find a monkey, because the result would be the same but cheaper.
Great talk! Never haired anybody say it better than this guy :)
Freudian slip?
lol, I often tell my kids to "stop doing this" when they answer "I don't know why I'm doing this" - seems like a universal principle ;-)
I love this! Whitespace does matter indeed!
I often describe myself as an "indentation maniac", as I tend to never follow indentation patterns in favor of just giving a form of diagramation to my code.
Now I understand why.
Glad to see my personal thoughts ressonate with this talk.
well, yeah. If you have a reason to do something, it makes more sense to do *that* instead of dogmatically following some arbitrary rule. One line function? If it reads ok, sure, why not. Array in ASCII art? Why the fuck not, if it makes sense.
Sometimes i see code like:
returnType
functionName (
type name,
type name,
type name,
type name,
type name,
type name,
type name,
type name,
type name,
type name,
type name,
type name,
type name,
type name,
type name,
) { // etc
and i'm like what the fuck are you doing, what is this? what vile demon possesed you to need a function that takes half a stack worth of arguments.
even worse, when time comes to call it, they write the same shit
functionName(
value,
value,
value,
value,
value,
value,
value,
value,
value,
value,
value,
value
);
and the idea that needing half a page to call a single function is a bit weird doesn't even cross their minds?
When i see shit like this in APIs or libraries like, say, opengl, I shove that in a struct and pass the struct. I don't care, i will inline that shit to make it easier to read.
spaces or tabs?
😁
For the same reason I'm regularly disgusted if I find an IDE comes integrated with a "beautifier" offering a gazillion of configuration options or "styles" but NO WAY TO TELL IT:
the following lines deliberately break the rules, SO DON'T DARE TO TOUCH.
@@aslkdjfzxcv9779tabs with an indentation width equivalent to 8 spaces so that you get "an early warning" if your code becomes too complex.
resonates with me. Rare but valuable skills that few have an opportunity to nurture.
Very refreshing talk! I have felt all of this and I always try to be solution first, always nicer😊
Is it just me, or is this guy saying what we've all been thinking for years?
Yes, but he expresses it better and much more eloquently than I ever.could.
This presentation was nothing short of excellent.
Great talk. This should be taught in university and outside of it too.
@3:20 That sounds like an art exhibit I'd actually expect to see in London.
So, we are building a moderately simple API. This is what happens when you create a new entry:
Controller gets a request, and transforms it to a DTO.
The DTO then is transformed into an Entity (which doesn't have any logic, basic setters and getters, isn't even mapped to a db).
Entity is then sent to a Service, that doesn't have any logic either, but it does have an interface that only it implements.
Service sends Entity to a Repository, that doesn't have any logic either, but it does have an interface that only it implements.
The Repository sends Entity to a DAO, which does have some logic (executes SQL)! It also has an interface, that only it implements.
Why do we have so many layers of code that do nothing but send information down the line? Well, because we are not barbarians... We read a book on design!
gosh, the amount of indirection in this makes it painful. the more code I write and read, the more I appreciate simple solutions
I prefer to remove DAO layer - its purpose is unclear and it makes mess when some logic that supposed to be in dao leaks to repository and vice versa.
Also its easier to understand logic when each request has its own handler (kind of mediatr but wihout only read or modify restrictions) - individual logic is in handlers, common in services. +1 layer btw
Such devision to layers add some flexibility in huge systems (hunders\housands of endpoints). For example, logic layer (handlers + services) reuse methods from data layer. Handlers reuse services.
The difference between dto and entity is not so clear - in most cases they are same, but sometime its helps to migrate from legacy or hide some properties from clients. In some cases client view of some entities are comletly different with backend view and it makes front\back development easier.
It's a good design for a large application - there's not a lot of boilerplate here, but there's plenty of flexibility.
In microservices with few endpoints its okey to call db from controller - when you run into design problem you can rewrite entire sevice in 1 hour)
On your typical enterprise project I think 3 layers makes sense. You have your interface layer that is a translation layer between the end user and your application. You have the business layer applying business rules. Then you have your database layer as another translation layer between your application and the database. On a large enough project you will likely have some occasions where the interface layer and business layers more or less are just pass through to the database layer, in these cases it is good to keep the layers for consistency reasons, as consistent code is easier to understand and maintain. If you find this is happening a lot, then that is likely because you designed your system around your database instead of around the intended purpose of the software.
Where I think the real issue comes in is the organization of the application. I'm guessing in your case everything is organized by type of object instead of by feature. This forces all this code to be distributed widely throughout the project, and essentially forces you into this kind of situation. If instead you design your application around features and organize your code around features, you can start to put all of the relevant code into a single folder, or maybe even a single file if it is trivial enough.
I had this exact argument with a coworker. He argued that with that unncessary abstraction, you could rip out the datalayer and swap it for something else (if you wanted to). A perfect example of YAGNI if you ask me
@@dan-bz7dz you say that, but that is exactly something I just did. Anyways it is less about replacing whole layers, and more about separation of concerns. Your business logic should not be concerned with how the user interacts with the data, not with how the data is retrieved from the database. This makes it easier to write maintainable business logic as you are not muddying the waters with tangential information.
I find the anecdote about Liskov substitution principle "making it into SOLID just so it could make a word" (13:02) surprising because it's the one SOLID principle I would *not* break. I can think of plenty of reasons to break pretty much all of the others given the right circumstance, but I can't fathom a situation where breaking the type hierarchy would make the code better.
The point, I think, is more that that principle shouldn't really have any bearing on software design. It's more on the "naming variables" level of thought that's very far lower than design.
This is a great talk 👍
Great talk!
Amazing content!
Cool Dude. Amazing Talk!
Great speach
This is a very good talk with a very unneccessary stab against "clean code". The talk does not win anything from it AND the stuff he says fits seamingly together with the content of clean code.
Btw, the definition of clean code, that uncle bob likes to use the most, is: "Code that looks like it is written by somebody who cares". THIS is intentionality at its core.
"Build smaller things"
Doesn't it drive you crazy when a coworker introduces you this new pattern that "makes everything super simple" and that is just replacing writing code with writing a sort of config file for another big chunk of code that needed to be general purpose and is therefore full of overhead?
And fully untyped with 0 documentation, yup
Yeah, is a common idea/trap that everyone seems to fall into, and many have to experience and feel the pain to know its a bad a Idea.
Reminds me of a similar bad idea that I've seen come up many times: trying to make the presentation (front end, etc) generic and being provided espeficications by the backend.
Best take away here: think about the code you're writing and make it easy to read and understand the problem it's hoping to solve. It's a challenge and it's worth it.
I am relatively new to coding and working with micro services. I'm not experienced and maybe that's why the point about micro services has me missing something? My understanding is that the modularity of the services makes fixing "parts" of the application easier to fix and replace... Like being able to tell based on a symptom of your car not working that is is clearly the alternator, then replacing that with minimal down time... versus taking the whole car apart and looking at and fixing the entire electrical system. It's my understanding as a n00b that whereas you have more "parts", you gain the immense benefits that come from modularity. I'm thinking his point is "don't just do microservices because people say it's better"...rather, do it because it makes sense for your use case. Every single other thing he said in this talk, I agree with and can't argue with. The look and readability of my code, even early on like I am, is very important to me and I take pride in making it pretty lol.
The point of micro services is that they have no dependencies on other micro-services, meaning that the service a is down, the rest of the application works because it has no dependents. It solves a direct business problem (availability) and it's not meant to be a way to organize your code. For example, if the youtube had a service for comments that stopped working, you could still do everything else but look at the comments. If the goal is to split the code base in multiple modules, you can do that without micro services.
The alternator in your example is not a micro service because the whole system depends on it.
@@turculaurentiu91well said. Pulling the alternator means the whole thing is out of action. It's more equivalent to a critical method than to a microservice.
I'd like to watch a post-mortem of NewDay's credit card for Amazon UK. An objective failure of a system that Amazon eventually jettisoned. A 2020s online bank that doesn't support Apple Pay or Google Pay has some serious questions about it. Were there serious technology issues, or just significant limitations by business?
Clean code should be as simple as possible, but also as maintanable as possible
40:08 reminds me of “only a Sith deals in absolutes”
John Ousterhout?!?! I used to love a nice bit of TCL/TK... until Python "stole" TK - and Expect is still kinda handy from time to time.
Best viewpoint on DDD I ever saw. But have you ever met that programmer who insists a 2000 line function with 8 levels of indentation is what actually constitutes "readable"?
Although, with ny eyesight, watching on a phone... I'm convinced I just watched a talk by Tyr Anasazi.
Another "Unix Oldtimer" like me?
Used TCL/TK?
(Or to quote Henry Spencer: I never used 'perl' because if 'awk' didn't suffice for task I went straight to 'tcl" 😊.)
I can hear the suppressed howling with exasperation slowly turning into Holy MAC suppresses Intent yes
MVC
Oh I see... mystical oriented programming...
What was the intent?
Fucking excellent
Clean code has nothing to do with syntax, it is actually about semantics, understandability, maintainability and showing the real intent of software. Software is not literature either, it is not open to different interpretations. Deep modules and shallow modules both have their places.
What was that?
Going good until TDD, many say it is about design not test, yet I have not come across a good/comprehensive tutorial that use it as a design tool
Makes me think this is just lip service, because how can you properly design dealing only with a small portion of the system (user story), "system wide thinking" is dead and we are seeing the results
We have quality matrix for IT practitioner but no equivalent value matrix for end users, very convinient if you ask me
If you have a classic car collection you don't store them by parts, but if you have a collection of spare parts for classic cars, you absolutely do. We store shared common components for code in the same way. It may not be the best way but it is NOT analogous to a classic car collection but rather to a collection of parts.
OK, sure. For libraries, and collections of importable widely reusable code, yeah. It makes sense for those to be organized by functionality, as if it were a collection of spare parts.
But my microservice/car is not simply an arbitrary collection of reusable parts, it is a composed arrangement of specific parts which should have strong spatial locality in subassemblies based on purpose.
Agreed space vs. tab doesn't look like it has any importance in the framework he described but it has a runtime effect in interpreted languages and compile time penalty in very large programs as do variable name lengths. Also as formatting is at the crux of his premise I'll mention that I find maintaining good formatting using tabs is quicker.
I feel like there are some valuable lessons in there, but perhaps not placed in a way where they are easy to get at. Some of the bits most worthwhile of the talk came at the end, and didn't get much time. Unfortunately talks in general are one way communication, and not well suited to exploring difficult topics.
If you compare code to literature then focusing on if the book was printed single spaced or double spaced seems like a fumble.
If you compare code to literature then names should matter as much as word choice..
Literature isn't known for a plethora of structural schemes... Chapters, scenes.. Verses, lines.. I suppose not every book needs an index, glossary, and table of contents but you aren't a bad person for having one. But if you put your index in the middle of the book instead of the back where people expect to find then you have done a disservice.
I'm not supporter of burning books at all.. And I don't understand the hate for Clean Code.. Although I don't own a copy either. Most books of that nature aren't intended as reference manuals anyway.. Once you absorb the concepts and integrate the ones that work for you, you should move on and look at some new ideas, if the book was especially valuable pass it on to a friend..
Clean Code is good advice for "beginners". Like learning a language, you start with what helps avoid mistakes - or, indeed, just gets you going in the first place. But that won't make great literature or even good stories.
There may be other ways of teaching that circumvent the "stabilisers" on your bike but if you still cling to your stabilisers on your daily commute, there's something wrong. (At least that's what I take away from this talk.)
@@malteplath I think what you're referring to what I'm more used to hearing called "training wheels". Which carries with it a bit of a derogatory connotation.
I would think of it more in terms of a helmet, safety goggles, or an over mitt.
They each have their area of applicability, and you can work in that area without using them, but that doesn't make it a good idea to so beginner or not.
I gather that the "burn them all" comment was hyperbole, intended to communicate a frustration with slavish adherence to dogma in that text.
Somewhat ironically that doesn't seem to have been an effective way to communicate the message to you. Rather than focusing on the way books should be treated, it's about the negative impact that the content of this particular text has had on the industry.
33:40 "once you have seen enough code bases and enough languages, you kind of realize that most of the arbitrary stylistic qualities of code that people focus on like tabs vs spaces and brace style are basically mostly irrelevant..."
That guy obviously never understood the difference between the mathematical terms "necessary" and "sufficient".
Consistent brace and indentation style are certainly not SUFFICIENT for good code.
But boy are these NECESSARY.
"like all that stuff is total noise"...
What non-sense...
Have you ever tried to read code, where indentation is completely broken? It's a nightmare.
If he at least would mention, that there are tools to fix that automatically... but calling this "irrelevant" is just non-sense.
ngl, I like it when I see folders named controllers, services, models - makes my mediocre brain feel at home
Conventions are good in industries where people need to on-board quickly, or external auditors need to understand it quickly. Taking away the convention might make the design less complex internally then, but a design needs to be orders of magnitude less complex to be beneficial to external "lookers and changers", a whole industry, as well. I like this talk, but I'd say ... it depends 😊
Is it just me, or does everyone gets an ad every 5 minutes?
For a man with a background in literature, he spends a great deal of time subverting his own thesis. He advocates intent while undermining the importance of techniques which communicate intent. He emphasizes his particular nuance while discarding wholesale the nuance in each area he derides.
This is a classic example of useful, powerful, and uncontroversial ideas positioned (intentionally or not) to be polarizing. And for what? For me, it merely indicated that he is not a trustworthy source; he is an angsty poet to whom one must listen at most with guarded interest, but probably not at all.
Says throw out clean code, then preaches the fundamental precepts of clean code. He actually steals the mvc organizational problem from Uncle Bob. Still a great talk.
You can't steal anything from the snake oil salesman that stole his terrible ideas from other people
Everything matters. Tone, cadence, rhythm matter too. I do agree with everyting David says but his voice just puts me to sleep!
He is pushing a lot of OOP dogma.