We often have the tendency to over engineer our software. We want to use the latest packages, integrate with the hip services, and adopt those shiny patterns. Jason's here to say, "you aren’t gonna need it". In this session we’ll take a look at how to practice YAGNI and what that means when writing code and making design decisions.


Comments are closed.

For once I thought this tech talk could have used a little LESS focus on code, as this was a more esoteric talk about coding approaches and the benefits of minimalism. The code examples of an evolution might have been better served by discussing more specific design patterns that emerged naturally. But some good design lessons in here nonetheless.

Chris Ostrom at 15:41 on 24 Oct 2017

Excellent talk! I thought the focus on code was just right, and illustrated well the rule of threes and how design requirements emerged while developing shift. Thanks!

Tony Stark at 15:53 on 24 Oct 2017

I would have liked to focus on the code less. I found it more interesting before we started digging into the example provided.

Great talk. The presenter pace and words used were very easy to follow and understand. I didn't dislike the code examples, I thought that they rightfully served their purpose. This sessions gave queues that I will use in my daily work.

Sean Talbot at 17:55 on 24 Oct 2017

Great to see practical examples from Shift added to your YAGNI talk :)

Alex Corbeil at 08:09 on 26 Oct 2017

Already use similar techniques that drives my engineers crazy but brings great results. Great talk.

John at 16:23 on 26 Oct 2017

Not convincing. Clear speaker, interesting topic, but I felt like he needed to present more alternatives or arguments against his approach, which struck me as pretty controversial. I am very sceptical that your average developers would not quickly end up with unmaintainable code if they took this approach. I would guess that relatively few developers have the problem of getting stuck because they spend too much time on upfront design. Most developers would benefit more from taking a highly structured approach that involves following some simple rules, so they don't have to spend too much time worrying about design but still write clean, dry, testable code from the get-go.

Tim Ledlie at 09:56 on 27 Oct 2017

Great talk. Would have been nice to summarize the common design patterns that can be used.

Elli at 10:50 on 27 Oct 2017

Great talk. Dogmatism around specific frameworks and tools has always been a pet peeve of mine, so it was great to hear a different take!