One Rule to Rule Them All • Pragmatic Dave Thomas • YOW! 2022

[@jasondchambers]

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.

[@SprytnaWay]

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

[@wrjacqmein]

My new favorite quote "Write Rails from scratch" - Dave Thomas

[@magicobject]

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.

[@kkjr6673]

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.

[@gewusst-vim9583]

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

[@oleksandrkaleniuk7813]

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.

[@SirWolf2018]

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.

[@oleksandrkaleniuk7813]

@@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.

[@SirWolf2018]

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.

[@allanwind295]

"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.

[@justwanderin847]

Not a fan of Agile. We call it, mini-waterfalls

[@saulo2264]

What's the alternative?

[@zouiclerks]

And are you a fan of?

[@anytcl]

​@@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 ​

[@Braindouchedotnet]

@@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.

[@anytcl]

​@@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

[@heyyrudyy404]

« 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