I've been watching like a 100 talks alone this year (2023) and I end up saying that this now 7 years old talk is the best talk I have ever seen on software development.
The examples are priceless. They will help me steer more design sessions in to the practical over the possible, and come up with contextual examples that will improve prioritization and reduce cost of achieving business goals. The part about the value of data for engineering what is needed is also great. When lucky, an architect can create a data model based on the happy path, and then get a start by loading legacy data and running those same tests. Alas, we are rarely that lucky. Thank you, Greg Young.
Passion, challenges and pleasure are best kept alive by making sure we work in greenfield like programming. CQRS provides that. Sourcing events for legacy provides that. The comment by "John Doe" shows their lack of experience with CQRS.
I realise that over engineering is a huge problem but, where i work, we massively under engineer everything so i have a stronger desire to put a stop to that... It's funny... you so very rarely see anything with just-about-right engineering.
the problem with these self certified experts is that each one of them promotes their ideas in the most possible arrogant way bashing every other technique, thought or process that they don't like. Bob Martin says there should be architecture and every line of code should be tested. Jim Copler says TDD is a bullshit and we should not try to waste time making architecture. Greg Young says don't handle issues, the best way to solve a problem is not to solve it. ironically he is the person who promotes Event Sourcing, the most complex architecture ever. who should i listen to? who is correct? whose idea is sane? help me please!
That's where you have to just try it all yourself and see what works for you. All these developers are probably great in their own way, but all have their own experience that shapes their opinion. You just have to develop your own opinion through your experience, and the talks that speak to you most will start to make more sense and stand out.
On the one hand, having all these viewpoints can be really overwhelming, especially for someone just starting out. On the other hand, having all these viewpoints is important, because different problems may be *best* solved in different ways. To use a construction metaphor, you *can* drive a nail in with a screwdriver or a crescent wrench - or a lot of things really - but a hammer is often considered optimal. Even with that conclusion, though, you have to decide if "optimal" makes sense for the circumstances. Now, as for this specific talk, Greg Young's argument is not that you should never solve problems. It's that you should not solve problems if they are not valuable to solve. Take an example from this talk. It takes you 2 months to handle 99% of cases. Is it really worth spending 10 more months to solve the 1% of exceptions? *If we're talking about one exception per day, probably not. *If we're talking about thousands of exceptions per day, probably so. Note I said "probably" in both cases. That's because the answer may also be influenced by your specific domain. Thus, the emphasis on cost-benefit analysis.
I wrote that 2 years ago. I won an architectural kata, did cloud native architecture and another one I should be designing soon. When i look back what i did is.. I stopped listening to them all. I stopped wasting my time listening to these experts, did my own study practiced, experimented. improvised. Here is the lesson: don't waste time or time wastes you!
I wonder. Does nobody build software which is used by multiple customers? Iam working as developer for >20 years now and more than 99% of all software I have built was used by multiple (many) customers. Specially for the mass market it is not very practicable to say: Well this invoice can not be printed do it manually ;-)
Ok but what about *your* business as developer? a. Do only 2 weeks of billable work and then start finding a new customer, which is boring unbillable work. b. Do 9 months of billable work. Oh and in b) you are also actually doing something interesting, feeling accomplishment and pride for fully solving the problem. So it's not only better for your business but more satisfying.
He is speaking absolutely from a business owner perspective, as if "solving problems in a purely business efficient way" would directly increase my yield as a developer. What about passion, challenges, pleasure for fuck sake, during those 8-10 hours of daily work? What about headaches after 3 hours of debugging that "efficient but messy code"? Multiply that by a couple of years. What about scaling the teams? Try do step down from the stage, get back to reality and explain to a junior what your "efficient but dirty" code does. If one ignores any "employee's personal needs", and treat devs as robots/typing machines, focused on maximizing business efficiency - then yes, the theory makes perfect sense. Hire robots. And by the way, stop promoting the let it fail argument, its time to be mature and recognize that CQRS+ES model is very problematic at ensuring data integrity, put the fairy dust aside. The question is not: 1. "Why devs are passioned about tech, and over'engineer?". The question to be asked before that is: 2. "Will cutting corners, and producing profit-oriented-only code, give employees any ROI ? where the I part is all the frustration, anxiety, headaches, degradation, extra time". Solve the problem behind question nr. 2. and you won't have problem nr 1. otherwise people will continue to be creative, and maximize the individual needs slider.
![Why Event Sourced Systems Fail [eng] / Greg Young](http://i.ytimg.com/vi/FKFu78ZEIi8/mqdefault.jpg)
I've been watching like a 100 talks alone this year (2023) and I end up saying that this now 7 years old talk is the best talk I have ever seen on software development.
There is only one talk I think is "better": The art of destroying software, also by Greg Young.
The examples are priceless. They will help me steer more design sessions in to the practical over the possible, and come up with contextual examples that will improve prioritization and reduce cost of achieving business goals. The part about the value of data for engineering what is needed is also great. When lucky, an architect can create a data model based on the happy path, and then get a start by loading legacy data and running those same tests. Alas, we are rarely that lucky. Thank you, Greg Young.
Thanks, very eyes-opening
Great talk about software development realities
Haha. "Use humans as services" - when I was about to start my thesis I shocked my then boss by saying this. (-:
Thank you great talk.
His invoice example of going one case at a time is test driven development in a nutshell.
The projector setup was definitely not over-engineered (or over-engenered) 😉
Great talk. Greg is an amazing talker. What are you using uhn Greg? Cocaine? lol
Just Asperger’s
Passion, challenges and pleasure are best kept alive by making sure we work in greenfield like programming. CQRS provides that. Sourcing events for legacy provides that. The comment by "John Doe" shows their lack of experience with CQRS.
I realise that over engineering is a huge problem but, where i work, we massively under engineer everything so i have a stronger desire to put a stop to that...
It's funny... you so very rarely see anything with just-about-right engineering.
the problem with these self certified experts is that each one of them promotes their ideas in the most possible arrogant way bashing every other technique, thought or process that they don't like.
Bob Martin says there should be architecture and every line of code should be tested.
Jim Copler says TDD is a bullshit and we should not try to waste time making architecture.
Greg Young says don't handle issues, the best way to solve a problem is not to solve it. ironically he is the person who promotes Event Sourcing, the most complex architecture ever.
who should i listen to?
who is correct?
whose idea is sane?
help me please!
That's where you have to just try it all yourself and see what works for you. All these developers are probably great in their own way, but all have their own experience that shapes their opinion. You just have to develop your own opinion through your experience, and the talks that speak to you most will start to make more sense and stand out.
But agreed - it is a mindfield of different opinions and perspectives.
On the one hand, having all these viewpoints can be really overwhelming, especially for someone just starting out. On the other hand, having all these viewpoints is important, because different problems may be *best* solved in different ways.
To use a construction metaphor, you *can* drive a nail in with a screwdriver or a crescent wrench - or a lot of things really - but a hammer is often considered optimal. Even with that conclusion, though, you have to decide if "optimal" makes sense for the circumstances.
Now, as for this specific talk, Greg Young's argument is not that you should never solve problems. It's that you should not solve problems if they are not valuable to solve. Take an example from this talk. It takes you 2 months to handle 99% of cases. Is it really worth spending 10 more months to solve the 1% of exceptions?
*If we're talking about one exception per day, probably not.
*If we're talking about thousands of exceptions per day, probably so.
Note I said "probably" in both cases. That's because the answer may also be influenced by your specific domain. Thus, the emphasis on cost-benefit analysis.
Listen to them all. If you think they have antagonistic ideas, listen to them again!
I wrote that 2 years ago. I won an architectural kata, did cloud native architecture and another one I should be designing soon. When i look back what i did is.. I stopped listening to them all. I stopped wasting my time listening to these experts, did my own study practiced, experimented. improvised. Here is the lesson: don't waste time or time wastes you!
I wonder. Does nobody build software which is used by multiple customers?
Iam working as developer for >20 years now and more than 99% of all software I have built was used by multiple (many) customers.
Specially for the mass market it is not very practicable to say: Well this invoice can not be printed do it manually ;-)
In the invoice example ... ur assuming the 1% u can’t process are rejected. Maybe they are not rejected just incorrectly processed.
Thats why he talks about humans auditing I think :\
Ok but what about *your* business as developer?
a. Do only 2 weeks of billable work and then start finding a new customer, which is boring unbillable work.
b. Do 9 months of billable work.
Oh and in b) you are also actually doing something interesting, feeling accomplishment and pride for fully solving the problem. So it's not only better for your business but more satisfying.
this is more relevant to projects than products
This is an excellent example that supports the argument that most unit testing is waste
He is speaking absolutely from a business owner perspective, as if "solving problems in a purely business efficient way" would directly increase my yield as a developer.
What about passion, challenges, pleasure for fuck sake, during those 8-10 hours of daily work?
What about headaches after 3 hours of debugging that "efficient but messy code"? Multiply that by a couple of years. What about scaling the teams? Try do step down from the stage, get back to reality and explain to a junior what your "efficient but dirty" code does.
If one ignores any "employee's personal needs", and treat devs as robots/typing machines, focused on maximizing business efficiency - then yes, the theory makes perfect sense. Hire robots.
And by the way, stop promoting the let it fail argument, its time to be mature and recognize that CQRS+ES model is very problematic at ensuring data integrity, put the fairy dust aside.
The question is not:
1. "Why devs are passioned about tech, and over'engineer?".
The question to be asked before that is:
2. "Will cutting corners, and producing profit-oriented-only code, give employees any ROI ? where the I part is all the frustration, anxiety, headaches, degradation, extra time".
Solve the problem behind question nr. 2. and you won't have problem nr 1. otherwise people will continue to be creative, and maximize the individual needs slider.
Much better to solve problems that nobody has than to solve problems that people care about. If this is the key to employee retention ¯\_(ツ)_/¯
Anonymously posted BS.
To be fair