One Rule to Rule Them All • Pragmatic Dave Thomas • YOW! 2022
Вставка
- Опубліковано 5 чер 2024
- This presentation was recorded at YOW! 2022. #GOTOcon #YOW
yowcon.com
Dave Thomas - Author of The Pragmatic Programmer @pragdave
RESOURCES
/ pragdave
github.com/pragdave
pragdave.me
/ dave-thomas-53aa1057
ABSTRACT
As developers, we live under a constant barrage of helpful advice, often in the form of rules with cute names. We're told how to design, how to code, how to deploy, how to monitor: there are systems and rules for everything. How can we keep up? How can we know what's good advice, and what's bad?
Over time I've come to realize that just about every good piece of advice is actually a special case of something both more general and simpler. So, let me introduce you to the "one rule to rule them all." [...]
TIMECODES
00:00 Intro
00:57 • Agile is Dead • Pragma...
01:40 Agile software development
03:47 Classic waterfall
05:26 Theorem proving
06:24 "Correct code"
09:01 Dave's postulate No. 1
10:28 Change
13:21 Easy to change
14:40 How?
20:57 Dave's postulate No. 2
26:35 Building intuition
30:10 Experience
34:22 Handwrite on paper
37:36 Make it easier to change
38:33 Make it fun
38:38 Outro
39:00 Q&A
Read the full abstract here:
yowcon.com/sydney-2022/sessio...
RECOMMENDED BOOKS
Dave Thomas & Andy Hunt • The Pragmatic Programmer • bookshop.org/a/9452/978013595...
Dave Thomas & Andy Hunt • The Pragmatic Programmer • amzn.to/3N3i0GP
Dave Thomas • Programming Elixir • amzn.to/3Dl6fY7
Dave Thomas & Sam Ruby • Agile Web Development with Rails 7 • amzn.to/3TuWuxj
W. Timothy Gallwey • The Inner Game of Tennis • amzn.to/3pjol9M
/ gotocon
/ goto-
/ gotoconferences
#Agility #AgileIsDead #TypeSystems #Intuition #Programming #PragmaticProgrammer #SoftwareEngineering #SoftwareDevelopment #DaveThomas #PragmaticDave
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf... - Наука та технологія
My new favorite quote
"Write Rails from scratch" - Dave Thomas
Great talk as ever. I would just add one more thing to the one rule so it reads "Make it easy to change with confidence". The with confidence is important because it covers automated testing and security.
Automated tests and TDD are a good example of supporting the “with confidence” suffix. You could argue that a dogmatic approach to tests and TDD can actually make it more difficult to change - but, at least a pragmatic approach to TDD is required for the confidence piece of the equation.
Another good example is security. Security controls do not make it easier to change, just like having to take your shoes off does not make it easier to fly. However, security controls and practices certainly fit into the “with confidence” suffix.
Great talk and as a personal bonus some of my favorite people all bundled together. Dave Thomas (my favorite presenter), Leonard Cohen (quote at the end), and Peter Drucker (not quoted directly, but the same ideas on estimating and documenting work to gain intuition).
We don't use magic numbers because they might change, we use them because it's not always obvious what the number means. Eg ints in a switch.
Bit of both, really. E.g., if you have an approximation of pi that is good enough for your platform, you may want to change it when porting. But it is also really useful to have it named in your code.
Yes but why is it important that it's obvious. For better readability. But why should someone read it. To understand it. What's the reason for understanding it. Most properly someone want to change it (or understand it to find a bug or wrong behaviour which in the end result would also cause a change)
So better readability -> easier to change ;)
Zero dependencies is the guiding principle of Words and Buttons Online. Not only third parties, not even inner dependencies. 5 years in production, over 50 interactive pages, and, since there is no dependency hell, each page is less than 64 KB along with JS and CSS. Ridiculously easy to maintain, and fun to work on. It started as an experiment, now I don't want to do things in any other way.
I don't get why this would work. Such a code base would be very very WET with no code reusability, no modularity, lots of repetition.... It might work for your project but that must be a huge exception. People love to think in extremes, but that is exactly what's wrong. It's not the dependencies that are wrong, it's too many dependencies that are wrong. Avoid both ends of the scale, find the right balance for what works for your project.
@@SirWolf2018 I don't get it either. I adopted this kind of design as an experiment to see when exactly will the whole thing become unmaintainable, and how exactly will is start to crumble. Well, not there yet.
Just the other day I decided to use the color from the entities featuring in the code snippets, and reuse this color for their mentions in the text itself. Half an hour and 30 lines of code later - the feature was done. Can't imagine doing the same in a traditional code base without weeks of risk analysis.
I agree that the optimum should be somewhere in between extremes. My experiment shows that this optimum may appear skewed towards no dependencies way more than it's generally believed.
"requirements used to change at the rate of about 20 percent per annum and it's feeling to me that that's dropping down to about every 20 every maybe two months at the moment". Are they any real source for said claim? What does Heisenberg's uncertainty principle, which applies to quantum mechanics, have to do with software projects? Even if it did why what is position and momentum of software? Why do you need to know those with absolute precision to ship business value? "Code that is hard to change will never be correct"? Huh? Those are two different things that you need to make an argument are linked. That requirements change is rather implicit... we know a code base change uniformly, right? Just before you said no non-trivial code was correct. No qualms with the message that it's important to make code easy to change.
There's not much new in this presentation. Robert C. Martin told us in 2012: "The primary value of software is that it is soft." But the secondary value is still there, that it is does what the customer asked for. And a customer won't be happy with a buggy software, so we should not downplay its importance. These 2 values balance each other out perfectly because if you make software too easy to change, you also make it too easy to introduce the wrong kind of changes, i.e., bugs. Code with zero dependencies leads to too much repetition, and the code smell of fragility. This presentation thinks in extremes when in fact extremes don't work. It's the right balance between sides that works.
Not a fan of Agile. We call it, mini-waterfalls
What's the alternative?
And are you a fan of?
@@saulo2264 nothing, literally nothing
he was doing mini water falls , called it agile and didnt like it
literally this is what he did , he was not being agile
agility is a great quality, and the agile manifesto is great , people tend to forget
that agility is a set of values and principles, not tools and method
people do things wrong, and then blame the thing
@@anytcl to be fair, the thing was adopted because it was supposed to solve the problems.
But more broadly, agile has a problem where success is attributed to the agility and the failures are individualized.
@@Braindouchedotnet
agility is about reacting to change because
1. you will never get it right the first time , or
2. everything change, always
agile methods achieved normalizing the following
1. distributed source control
2. CI/CD
3. TDD
how
1. you needed to code fearlessly, DVCS made easy to branch, and allows more autonomy
2. you need to deliver often and deliver frequently
3. together with the previous point, done should mean done, testing needed to be automated and thorough, the testing culture is mostly the offspring of agile methods
my point is, people when they think agile, they probably think scrum, or stand up meeting, or poker planning
but they forget that we now have better tools and better programming languages because developers wanted to be agile
try to read any methodology book, before the agile area, it was a disaster .. it was bad really bad
people take for granted, how deeply rooted the tools they use today are rooted in agile methods
agile methods are head and shoulders above anything that preceded them
« Compositionality allows a small change in requirements to translate into a small change in code.
Compositionality is the single most important factor in determining the cost of code maintenance. » John A De Goes
« I teach in functional design that orthogonality is an essential component of 'good' compositionality, one that aids the modularity requires to minimize maintenance costs. » John A De Goes