Opening Keynote: Greg Young - Stop Over-Engenering 

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 projector setup was definitely not over-engineered (or over-engenered) 😉

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.

Thank you great talk.

Haha. "Use humans as services" - when I was about to start my thesis I shocked my then boss by saying this. (-:

In the invoice example ... ur assuming the 1% u can’t process are rejected. Maybe they are not rejected just incorrectly processed.

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 ;-)

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.

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.

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

To be fair

Thanks, very eyes-opening

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!

Great talk. Greg is an amazing talker. What are you using uhn Greg? Cocaine? lol

Great talk about software development realities

His invoice example of going one case at a time is test driven development in a nutshell.

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.

This is an excellent example that supports the argument that most unit testing is waste