The way of programming that he uses is mostly based on the book, Elegant Objects by Yegor Bugayenko, on the book it actually contains concrete examples of what the speaker means and technically addresses much of the points that are just skipped here, yes this is a sale pitch for his service, but he provides actual references to the books his work is based on.
After now reaching the point of what he considers bad signifiers I see how he got there. And as enthusiastic as he is about all this I don't believe a word. I mean I believes everything himself, but he (and his team) basically have gone back to spaghetti code under the disguise of object orientation.
Yep, we definitely have a problem with conflicts of interest on the part of software management consultants. They've discovered that the more doctrinaire and cult-like they structure their methods, the more consulting contracts they get. Shameful.
He's replacing conditional complexity with class construction complexity. Would love to know what the garbage collection of applications is like. Also, I imagine he does not use POJOs for data.
I agree with everything except two points: 1. I have single implementations of an interface because I want, for example, a single database; but I don't want other classes to depend on the concrete database implementation - dependencies should be abstractions. 2. Classes ending with -er or -or: I'd love to, but what do I call CryptoSerializer or EmailSender?
1. You would use database abstraction frameworks anyways. So youll almost never have a concrete DB implementation in your own codebase but rather included as a library along with your code. 2. His concept is to code very differently and not having classes like you mentioned at all. he didnt tell what he would have otherwise because he never gave examples, but I guess after you have spent a fortune at that academy of his you will know ;-) the talk was basically a promotion for his consulting franchise.
+Marcel Popescu My "e-mail sender" is usually an SmtpPostOffice that implements PostOffice with sendMessage(destination, content) or something similar. I have swapped a JMS implementation for an e-mail implementation and they're both PostOffice implementations and it just works. No need for -er. I can't comment on CryptoSerializer. I expect that it really consists of a SerializationFormat and a CryptoCanvas (a think that writes encrypted data to a stream), and if starting from scratch, I'd design it in two composable pieces. new CryptoCanvas(new BinarySerializationFormat(), new FileWriter("...")). I like "Canvas" over "Writer", but I admit that I originally chose it somewhat artificially to avoid "-er". I never bothered looking for an alternative to "Reader", because of how common "Reader" and "Writer" are in Java.
+jbrains762 Hmm... thanks; the PostOffice example makes a lot of sense to me. Because I tend to use interfaces / classes with a single public method (SRP taken to extremes), I generally think "what the class does" instead of "what it is" and therefore name it as a do-er. Hence EmailSender instead of PostOffice. One of the CryptoSerializers I wrote has three dependencies: a BinaryFormatter, a DESCryptoServiceProvider - both terminating in -er :) - and a CryptoStream. (I'm using C#, not Java.) Honestly, while I can understand having a problem with classes like Manager or Utility, I think rejecting -er and -or in general is too much.
+Marcel Popescu yeah, thats genious! not. if its that what youre after then just add "Service" at the end of each class. eg "MailSenderService", "CryptoSerializerService". I guess changing names isnt just about calling the things a different name but rather having a totally different concept behind your OO coding.
The general idea is to design classes differently. Instead of having EmailSender to send an email, you can have Email class with send() method. Another example would be having Article class with save() method instead of ArticleManager.saveArticle(article), because save/send functionality belongs to Article/Email. It makes more sense and keeps code more organised, tidy and maintainable. -er and -or classes tend to get out of control through code lifetime.
+Maher Baba My current project has average class length of 13 LLOC (logical lines). This without trying to keep classes small, just following general design principles such as low coupling, high cohesion and management of dependencies. github.com/wmde/FundraisingFrontend
7 minutes in, what I'm hearing is that OOP is so clunky and un-Agile that the only way to make it seem applicable to complex programs that will have to change a lot in the future is turn the "object" construct into a complete joke by putting every single instruction in a separate method "belonging to" a separate object. At that point you might as well just cut out all the useless lines of code and revert to functional programming, which is what you should've been using in the first place; which is the right solution a lot of the time when the problem domain is not by its own logic structured into any kind of "class hierarchy", and when it doesn't make anything better to try to force it to become such a thing.
That was my thought one line of real work ("logic") per file? You're ditching the language and making your own out of 1400 "instructions" at the complexity level of machine-code. Good luck understanding how the thing works.
Like the process of keeping it simple. Would like to try this Kata over time of 15min code blocks and keeping simple and starting with anything change if gets messy.
I don't understand if needing 17 testers to keep up with 6 programmers is something that you should pride upon. It could indicate anything from the testers not being skilled enough to developers not being test infected enough. Why not just use the programming talent to automate tests , and reduce the testers. Also you did talk about code first and writing unit tests all the way along. So needing 17 testers really does not make any sense at all . Seems departmentalized to me instead of being collaborative ... how is that agile in the first place ?
Did you even watch the lecture? It wasn't his choice to have 17 testers. Nationwide had their own QA and compliance process, he didn't design it. The point is that they were releasing features at a rate that the testers couldn't keep up with. Not because there were so many bugs: there were hardly any, and the ones that were found were easily fixed within hours. Just because insurance is bloated and their QA and compliance process is broken.
1:11 I'll be plain, I don't like this chart. 6x "better" or "more value" (doesn't even say) doesn't work out, it doesn't reflect what's being shown here at face value, which is about 9 developers with 4 times the workload at 3 times the rate doing it somehow in 2/3 the time compared to about 34 developers, plus they have to stop and handle two releases in the middle, they're switching gears all the time because "agile"... Seems like the secret assumption is that this is a reasonable way to manage.
Agile extremism of the bad sort. The manifesto clearly says that "while we value the things on the right, we value the things on the left more" which is just the common sense notion that while it's more important to have working software than comprehensive documentation that does NOT mean that documentation is worthless and can be skipped. I've seen plenty of so-called self-documenting code without accompanying documentation and the problem has commonly been that of like trying to get into an old discussion without understanding any of the historical or business context. I can look at the code and see that it does but the code won't tell me what it should do and why. I don't care if the project has been constructed bottom up or top down as long as I can start from reading the mission statement of the thing and work my way down from the abstract to the details. This sounds like a recipe for fire and forget projects. And I seem to have missed the answer to the question posed by the title of the talk.
The ideal I try to adopt is to recognize that the business domain cannot be coded completely; there are human processes and such outside the software. Consequently comments can be useful to help the human reader understand that aspect of the problem.
He didn't say he had no documentation, he said that when it came time to do the transition, they didn't need any extra time to write new documentation, or anything else at all. Because everything was in place already for the handoff.
For me the blackjack example looks about 100% like how i would write it. but i still dont see the point about 1400 classes. splitting code into many classes makes room for confusion. plus you open the door for reusing the classes in different places (after all thats what OO is about right?) and that can make everything become a spaghetti monster... until i see a reasonable example with 1000 classes that is organized in a way that can be simply understood i highly doubt Freds methods.
+DerZufall AFAIK, OOB is not about re-usability of classes, although it is commonly preached in such way. Its about small objects that communicate with each other. Small objects scream out their intention to the reader of the object within seconds. For that to happen, each object need to focus on a single thing. 1400 classes probable because as they were writing code, they were also refactoring code into methods, and as the methods grew too big, they refactored into classes. So they were writing code and designing at the same time. Its a programming style that grew from programming in smalltalk, it not fred's method.
I've been doing this for 40+ years and would consider myself a master programmer. I call BS. 1.1 lines of code per function is almost triple the lines of code and it's utterly ridiculous. And 1500 classes isn't something to brag about on the face of it, never mind the idea that a class with more than one instance variable is "bad". I will wager large sums of money that he writes huge, bloated systems.
@@fennecbesixdouze1794 : As I already said, I call BS on that and the rest of his claims. The only way that could be true is if the code which precedes that reduction is a complete pile of steaming crap.
@@l-cornelius-dolHe didn't say that thing about "more then 1 instance variable". He said he knows co-workers who have this rule, but his own rule of thumb is more than 4-5 variables which seems reasonable to me. But yeah, I agree that 1.5k classes is actually a lot and 1.1 lines per function seems hilarious. Most likely his code has no cohesion at all and the logic is scattered around all over the place 😂😂😂 And yeah, I guess those guys always seem to forget that polymorphism is really bad for performance. If statements are an appropriate solution to get rid of those pesky virtual function pointers, etc. 🤪
There are testers and there are testers.... too lumped together.... SDETs? someone who follows scripts given to them? you don't thenk there are 10x testers? there are.
4 hours for a change? Bullshit. Where's code review? Where are communication problems with the Indians? Where's actually understanding the requirements? Where's debugging a crazy problem with a framework? When he got to the meat of his presentation, this was a joke. Knowing a pattern like Iterator or Builder, isn't a magic solution that will make you a better programmer. These are only some basics from 3rd year of CS. Sadly, this is what is missing in India, so his training could have actually helped his classes.
Remember, he is an Agile certifications seller probably or at least consultant. He must find new ways of _Your fault, not my fault, you are not good enough for Agile._
He is not actually giving advice. He is blaming coders, because Agile is not in good shape. Haven't heard of _"Agile is perfect, don't blame Agile, you are not worthy enough."_ This is a whole new level of it
Lol, that was one of his comments that did resonate with me. I don't use case statements because I usually end up needing to support more complex cases. But I hope I'm not as dogmatic when others choose to use them. I think once I did refactor to case statements when doing some XML parsing, because that was the correct thing to do.
@@EricRohlfs There's nothing remotely dogmatic about it. It's just a code smell. You look at the constructs as hints that there might be something wrong with your design. With TDD red-green-refactor, you litter your code with as many "bad" constructs as you need to get the test green as fast as possible, and then you refactor. Not every case statement will disappear, but it's a good rule of thumb to just be aware that when you see them, they are "suspicious" and might hide a bad design behind them. If you turn that into dogmatism then you've lost the plot.
You, speaker, spoke with poor diction. Definitely should look into speech therapy. Your claims are not motivated, any support is unconvincing anecdote. You are fair about the fact that this is only OO-programming relevant and that designing software according to the functional paradigm may obviate much of your best practice claims. The title of this talk bears little relation to the actual content, however incoherent it sadly is. You talk about ‘guys’ all the time. You should be aware of this as a public speaker, and use gender neutral ways of expressing your thoughts. Also, please don't scratch your head all the time you're hearing out members of the audience. Do not bluntly state ‘I couldn't understand a word this guy just said.’ just to point out the sound issue to some obviously non-native English speaker in the audience. And why not point the sound issue out immediately?
what a bullshit! good style or not, nobody put a thought on performance which is typical for these days. maybe the customer got a cheap product, but maybe the softwares performance is cheap aswell... think about it
+Matthew Conger-Eldeen I think everyone agrees with that; the question is, how do you learn good design? The answer: try lots of things yourself. Never, ever trust the word of another engineer, not unless you know them personally and often not even then. No one is more superstitious than a software engineer, and a lot of consultant types prey on that.
I’m a big fan of a lot of what this talk recommends, however it’s a shame the talk is completely aimed at men. Let’s try to be more inclusive than this.
I know that this is basically an advertisement for his training, but a concrete example would have been nice.
Yes. Did he write a book at least (well probably he is making his money on it)
It is hardcore commercial. Take every sound byte with a ton of salt.
The way of programming that he uses is mostly based on the book, Elegant Objects by Yegor Bugayenko, on the book it actually contains concrete examples of what the speaker means and technically addresses much of the points that are just skipped here, yes this is a sale pitch for his service, but he provides actual references to the books his work is based on.
This is all well and good until some poor soul comes along to maintain it and sees 1000 classes and cries
After now reaching the point of what he considers bad signifiers I see how he got there. And as enthusiastic as he is about all this I don't believe a word. I mean I believes everything himself, but he (and his team) basically have gone back to spaghetti code under the disguise of object orientation.
Yep, we definitely have a problem with conflicts of interest on the part of software management consultants. They've discovered that the more doctrinaire and cult-like they structure their methods, the more consulting contracts they get. Shameful.
He's replacing conditional complexity with class construction complexity. Would love to know what the garbage collection of applications is like. Also, I imagine he does not use POJOs for data.
I agree with everything except two points:
1. I have single implementations of an interface because I want, for example, a single database; but I don't want other classes to depend on the concrete database implementation - dependencies should be abstractions.
2. Classes ending with -er or -or: I'd love to, but what do I call CryptoSerializer or EmailSender?
1. You would use database abstraction frameworks anyways. So youll almost never have a concrete DB implementation in your own codebase but rather included as a library along with your code.
2. His concept is to code very differently and not having classes like you mentioned at all. he didnt tell what he would have otherwise because he never gave examples, but I guess after you have spent a fortune at that academy of his you will know ;-)
the talk was basically a promotion for his consulting franchise.
+Marcel Popescu My "e-mail sender" is usually an SmtpPostOffice that implements PostOffice with sendMessage(destination, content) or something similar. I have swapped a JMS implementation for an e-mail implementation and they're both PostOffice implementations and it just works. No need for -er.
I can't comment on CryptoSerializer. I expect that it really consists of a SerializationFormat and a CryptoCanvas (a think that writes encrypted data to a stream), and if starting from scratch, I'd design it in two composable pieces. new CryptoCanvas(new BinarySerializationFormat(), new FileWriter("...")). I like "Canvas" over "Writer", but I admit that I originally chose it somewhat artificially to avoid "-er". I never bothered looking for an alternative to "Reader", because of how common "Reader" and "Writer" are in Java.
+jbrains762 Hmm... thanks; the PostOffice example makes a lot of sense to me. Because I tend to use interfaces / classes with a single public method (SRP taken to extremes), I generally think "what the class does" instead of "what it is" and therefore name it as a do-er. Hence EmailSender instead of PostOffice.
One of the CryptoSerializers I wrote has three dependencies: a BinaryFormatter, a DESCryptoServiceProvider - both terminating in -er :) - and a CryptoStream. (I'm using C#, not Java.)
Honestly, while I can understand having a problem with classes like Manager or Utility, I think rejecting -er and -or in general is too much.
+Marcel Popescu yeah, thats genious! not. if its that what youre after then just add "Service" at the end of each class. eg "MailSenderService", "CryptoSerializerService". I guess changing names isnt just about calling the things a different name but rather having a totally different concept behind your OO coding.
The general idea is to design classes differently. Instead of having EmailSender to send an email, you can have Email class with send() method. Another example would be having Article class with save() method instead of ArticleManager.saveArticle(article), because save/send functionality belongs to Article/Email. It makes more sense and keeps code more organised, tidy and maintainable. -er and -or classes tend to get out of control through code lifetime.
would like to see names of those 1400 classes, i bet as long as my arabic friend name
Mark Stoddard exactly what i wanted say, sorry my english is not very advance, my friend not here to help me but i hope you understand
+Christopher Cabanne thank you but there is not the project he talking about in this speech
+Maher Baba My current project has average class length of 13 LLOC (logical lines). This without trying to keep classes small, just following general design principles such as low coupling, high cohesion and management of dependencies. github.com/wmde/FundraisingFrontend
6006133 very interesting, thank you for this example i am looking into it
Disliked: please provide concrete code examples demonstrating why your style is better. Show me, don't just tell me how great your class is.
LOL. Totally missed the concept of the conference.
Hint: not everything is an IDE, not everything is code.
A better delivery of these radical ideas can be found in many of Sandi Metz' talks.
7 minutes in, what I'm hearing is that OOP is so clunky and un-Agile that the only way to make it seem applicable to complex programs that will have to change a lot in the future is turn the "object" construct into a complete joke by putting every single instruction in a separate method "belonging to" a separate object. At that point you might as well just cut out all the useless lines of code and revert to functional programming, which is what you should've been using in the first place; which is the right solution a lot of the time when the problem domain is not by its own logic structured into any kind of "class hierarchy", and when it doesn't make anything better to try to force it to become such a thing.
That was my thought one line of real work ("logic") per file? You're ditching the language and making your own out of 1400 "instructions" at the complexity level of machine-code. Good luck understanding how the thing works.
Great until you mentioned that you created the Mail Online site.
This is the longest infomercial I've ever seen.
Like the process of keeping it simple. Would like to try this Kata over time of 15min code blocks and keeping simple and starting with anything change if gets messy.
I don't understand if needing 17 testers to keep up with 6 programmers is something that you should pride upon. It could indicate anything from the testers not being skilled enough to developers not being test infected enough. Why not just use the programming talent to automate tests , and reduce the testers. Also you did talk about code first and writing unit tests all the way along. So needing 17 testers really does not make any sense at all . Seems departmentalized to me instead of being collaborative ... how is that agile in the first place ?
Did you even watch the lecture? It wasn't his choice to have 17 testers. Nationwide had their own QA and compliance process, he didn't design it. The point is that they were releasing features at a rate that the testers couldn't keep up with. Not because there were so many bugs: there were hardly any, and the ones that were found were easily fixed within hours. Just because insurance is bloated and their QA and compliance process is broken.
1:11 I'll be plain, I don't like this chart. 6x "better" or "more value" (doesn't even say) doesn't work out, it doesn't reflect what's being shown here at face value, which is about 9 developers with 4 times the workload at 3 times the rate doing it somehow in 2/3 the time compared to about 34 developers, plus they have to stop and handle two releases in the middle, they're switching gears all the time because "agile"... Seems like the secret assumption is that this is a reasonable way to manage.
Too much fluff... Too many assumptions ! Is it marketing?
Agile extremism of the bad sort. The manifesto clearly says that "while we value the things on the right, we value the things on the left more" which is just the common sense notion that while it's more important to have working software than comprehensive documentation that does NOT mean that documentation is worthless and can be skipped. I've seen plenty of so-called self-documenting code without accompanying documentation and the problem has commonly been that of like trying to get into an old discussion without understanding any of the historical or business context. I can look at the code and see that it does but the code won't tell me what it should do and why. I don't care if the project has been constructed bottom up or top down as long as I can start from reading the mission statement of the thing and work my way down from the abstract to the details. This sounds like a recipe for fire and forget projects. And I seem to have missed the answer to the question posed by the title of the talk.
The ideal I try to adopt is to recognize that the business domain cannot be coded completely; there are human processes and such outside the software. Consequently comments can be useful to help the human reader understand that aspect of the problem.
He didn't say he had no documentation, he said that when it came time to do the transition, they didn't need any extra time to write new documentation, or anything else at all. Because everything was in place already for the handoff.
checkout github.com/fredgeorge has some example code along with the blackjack example he spoke of
For me the blackjack example looks about 100% like how i would write it. but i still dont see the point about 1400 classes. splitting code into many classes makes room for confusion. plus you open the door for reusing the classes in different places (after all thats what OO is about right?) and that can make everything become a spaghetti monster... until i see a reasonable example with 1000 classes that is organized in a way that can be simply understood i highly doubt Freds methods.
+DerZufall I agree actually.
+DerZufall AFAIK, OOB is not about re-usability of classes, although it is commonly preached in such way. Its about small objects that communicate with each other. Small objects scream out their intention to the reader of the object within seconds. For that to happen, each object need to focus on a single thing. 1400 classes probable because as they were writing code, they were also refactoring code into methods, and as the methods grew too big, they refactored into classes. So they were writing code and designing at the same time. Its a programming style that grew from programming in smalltalk, it not fred's method.
I've been doing this for 40+ years and would consider myself a master programmer. I call BS. 1.1 lines of code per function is almost triple the lines of code and it's utterly ridiculous. And 1500 classes isn't something to brag about on the face of it, never mind the idea that a class with more than one instance variable is "bad". I will wager large sums of money that he writes huge, bloated systems.
He estimated an 85% reduction in code size.
@@fennecbesixdouze1794 : As I already said, I call BS on that and the rest of his claims. The only way that could be true is if the code which precedes that reduction is a complete pile of steaming crap.
@@l-cornelius-dolHe didn't say that thing about "more then 1 instance variable". He said he knows co-workers who have this rule, but his own rule of thumb is more than 4-5 variables which seems reasonable to me.
But yeah, I agree that 1.5k classes is actually a lot and 1.1 lines per function seems hilarious. Most likely his code has no cohesion at all and the logic is scattered around all over the place 😂😂😂
And yeah, I guess those guys always seem to forget that polymorphism is really bad for performance. If statements are an appropriate solution to get rid of those pesky virtual function pointers, etc. 🤪
Lol 1,000,000 lines of code because your methods are only 2-4 lines long. Many Many Many lines just doing nothing
Lines were not the focus. Changing and moving fast was the focus.
"Functional programming does not have encapsulation". Me: That doesn't really makes sense
He literally said immediately after that that he doesn't do functional and doesn't know much about it.
All he knows is not Agile's fault nor his fault as Agile consultant. Is _someone's_ else fault, so makes sense in his mind.
There are testers and there are testers.... too lumped together.... SDETs? someone who follows scripts given to them? you don't thenk there are 10x testers? there are.
4 hours for a change? Bullshit. Where's code review? Where are communication problems with the Indians? Where's actually understanding the requirements? Where's debugging a crazy problem with a framework?
When he got to the meat of his presentation, this was a joke. Knowing a pattern like Iterator or Builder, isn't a magic solution that will make you a better programmer. These are only some basics from 3rd year of CS. Sadly, this is what is missing in India, so his training could have actually helped his classes.
Remember, he is an Agile certifications seller probably or at least consultant. He must find new ways of _Your fault, not my fault, you are not good enough for Agile._
Yeah, infomercial.
This is the worst advice that has ever been given.
He is not actually giving advice. He is blaming coders, because Agile is not in good shape.
Haven't heard of _"Agile is perfect, don't blame Agile, you are not worthy enough."_ This is a whole new level of it
case, if and else? Get a grip.
Lol, that was one of his comments that did resonate with me. I don't use case statements because I usually end up needing to support more complex cases. But I hope I'm not as dogmatic when others choose to use them. I think once I did refactor to case statements when doing some XML parsing, because that was the correct thing to do.
@@EricRohlfs There's nothing remotely dogmatic about it. It's just a code smell. You look at the constructs as hints that there might be something wrong with your design. With TDD red-green-refactor, you litter your code with as many "bad" constructs as you need to get the test green as fast as possible, and then you refactor. Not every case statement will disappear, but it's a good rule of thumb to just be aware that when you see them, they are "suspicious" and might hide a bad design behind them. If you turn that into dogmatism then you've lost the plot.
You, speaker, spoke with poor diction. Definitely should look into speech therapy.
Your claims are not motivated, any support is unconvincing anecdote. You are fair about the fact that this is only OO-programming relevant and that designing software according to the functional paradigm may obviate much of your best practice claims. The title of this talk bears little relation to the actual content, however incoherent it sadly is.
You talk about ‘guys’ all the time. You should be aware of this as a public speaker, and use gender neutral ways of expressing your thoughts.
Also, please don't scratch your head all the time you're hearing out members of the audience. Do not bluntly state ‘I couldn't understand a word this guy just said.’ just to point out the sound issue to some obviously non-native English speaker in the audience. And why not point the sound issue out immediately?
what a bullshit! good style or not, nobody put a thought on performance which is typical for these days. maybe the customer got a cheap product, but maybe the softwares performance is cheap aswell... think about it
Many times good software design allows for good performance. Look at the talks by the LMAX people. They even say this directly.
+Matthew Conger-Eldeen I think everyone agrees with that; the question is, how do you learn good design? The answer: try lots of things yourself. Never, ever trust the word of another engineer, not unless you know them personally and often not even then. No one is more superstitious than a software engineer, and a lot of consultant types prey on that.
+Matthew Conger-Eldeen Do you have a reference, link, video?
Guy with all the answers... blah...
I’m a big fan of a lot of what this talk recommends, however it’s a shame the talk is completely aimed at men. Let’s try to be more inclusive than this.
How it this aimed at men? Just because he says "guys" multiple times? I have other problems, like the lack of examples ...
@@ghaering It's a 40 minute talk that's aimed at leadership.