evolutionary-design
design
https://www.youtube.com/watch?v=SbGiSH_8UGk
Learn More →
Programming is the easy part COMPARED to the other parts
Most of the time, when I work with teams and we sit down together in front of a programming problem, after a couple of hours we find out that the real problem, the real reason that we are having this conversation, goes beyond the issues of programming, it's not technical…
There's a lot of lack of confidence… like
…nonsense…
One of the secrets to programming well is becoming confident with Evolutionary Design.
Evolutionary Design means willingness to allow the design to evolve: the design is evolving while you are guiding the shapes of the code.
Ok, but how do you do that?
can all be reduced to two basic ideas:
All principles we use in designing software are "linear combinations" of remove duplications + improve names.
While writing code, you note duplications (of code, of procedures, of …). Duplications can cause bugs (you change 9 places out of 10 of duplicated logic => you've just introduced a bug…), so you remove the duplication, creating a new "container" in your system.
This new "container" may be
Removing a duplication you're actually reducing the amount of things you need to change.
Now, when you create a new structure, you have to give this "thing" a name.
We programmers are not very good at naming things.
The first name given to this new "thing" is not very good… but explaining what that thing is to another person can help you find a better name, from nonsense to intention revealing, improving it and making a little better every day.
Arlo Belshee has a very detailed process for naming things https://www.digdeeproots.com/articles/on/naming-process/
(see also https://blog.thecodewhisperer.com/permalink/a-model-for-improving-names)
When you name things better (honestly, precisely), patterns in the names suggest patterns in the design.
E.g. you start to notice that the name of a given technology domain concept ("persistent", "customer", "transaction", …) is scattered in many places throughout the code.
This is what we call Cohesion.
Following this rule, what happens is that responsibilities in the code starts to move and gather in a sensible place:
This in turn makes it easier to change code, because there's a higher chance that changes are all localized in one "place" instead of creating a "domino effect" where we change here, than we have to change there, and there and there …, where the changes ripple throughout the codebase.
The change is also easier because when changing code you don't have the risk of changing unrelated things at the same time, because the unrelated stuff has been moved in another place, far from here: you are more confident that you only change the parts that need to change.
See also Kent Beck's talk about Coupling and Cohesion: https://hackmd.io/2fXGQXhZQWutE7C-ZhSw_w?view#Cohesion
While you keep improving Cohesion by moving similar thing closed together and different things farther apart, you are going to be able to treat each new "container of similar things" as one thing in the way it interacts with the code nearby: you won't need to know all the details of everything that is happening inside that "container".
This is what Abstraction is like.
Abstraction means hiding details: looking at the code, I can treat it a single thing.
While you keep introducing new abstractions, you can look at your code and see the key parts that you need to know in order to use that codebase, the parts the outside world actually cares about, with all the noise and distraction of details hidden behind the abstractions.
Having no more distractions, you can now see bigger patterns, higher level patterns.
You see higher level forms of DUPLICATIONS!
Remove duplications => add new structures to the system => give names to those structures => slowly find better names => code moves closed together that should be closed together, and further apart that should be farther apart => easier to introduce new abstractions => easier to ignore 90% of code and see higher-level patterns => notice new forms of duplications at a higher level of the system => … until you get to the entry point of the system and there's nothing left to do.
Evolutionary Design allows us to deliver features sooner, and that is a key factor for stakeholders.
But we devs should practice Evolutionary Design because it make things easier for programmers, as it allows us to build a system with confidence even without knowing all those needs to be done in advance or having a clear design in mind, improving the design of code a little bit every day, so that introducing a new feature will not that hard.
That's why is important to practice evolutionary design!
Evolutionary Design helps in being more confident to add features to the system over time.
TDD is a way of practicing evolutionary design, not the only way possible though.
Evolutionary Design helps you learn the principles of modular design.
From modular to functional programming? Fine!
Objects are just cohesive collections of partially-applied functions, the constructor is just partially-applying parameters in a function.
Being a master of programming won't solve all of our problems: not all problems are related to code or design, many problems are outside the tech side.
Time is not your problem!
That's the essence of real Agile (maximizing the amount of work not done).
When somebody ask to do something…
<
2 minutes? => do it now>
2 minutes? => add it to your planKeep track of the all things that you agree to do, that "plan" will be huge, full of stuff… Stop and realize that you should be honest and star doing less.
To improve interaction with other people: Satir's interaction model, to debug bad conversations with people.
Satir interaction model has four parts.
The last parts:
We typically try to change the other person's response (stop yelling to me, stop saying that thing, …), and that won't work.
That's because how we respond, the path from interpretation to response, is automatic and entwined in our human being.
It's
So, you should not try to change the way they're acting (they're response), because that's hard (being automatic, involuntary and rational)
So, focus on interpretations instead.
One technique: 3 interpretations:
when someone behave in a way that you don't like, try to think to at least 3 different ways they could interpreting what's going on that would lead them to behave that way.
To recover the conversation.
I'm going to change the way I act, change what I say to let you interpret me the way I mean to be.