"Everyone in the team should know the vision. Including the technical people." Sure, says everybody.
"Everyone in the team should know how the implementation. Including the non-technical people." What?!
Yep.
Let me take you on a ride.
1/
"Everyone in the team should know how the implementation. Including the non-technical people." What?!
Yep.
Let me take you on a ride.
1/
Typically, it all starts with a vision.
2/
2/
The interface kind of reflects it.
3/
3/
But the implementation ... well, let's just say that the original idea is to be seen somewhere, but you have to squint really hard.
"Why is that a problem? Is it not the norm?"
4/
"Why is that a problem? Is it not the norm?"
4/
Unfortunately, it is the norm. But it should not be.
Think of this: When the implementation changes how do you know it still reflects the vision? If the implementation does not reflect the vision, you really don't. But you should.
5/
Think of this: When the implementation changes how do you know it still reflects the vision? If the implementation does not reflect the vision, you really don't. But you should.
5/
So, what can we do?
Change the system to match the vision. Maintain a ubiquitous language throughout the system. The whole domain-driven design dance.
Only this perspective sees the implementation as translating the vision into technical details. A one-way street.
6/
Change the system to match the vision. Maintain a ubiquitous language throughout the system. The whole domain-driven design dance.
Only this perspective sees the implementation as translating the vision into technical details. A one-way street.
6/
Yes, we can find ways to simplify the implementation. Yes, we can align it more with the existing vision. Investing in the domain design does pay off.
At the same time, it can be such a missed opportunity.
Bare with me.
7/
At the same time, it can be such a missed opportunity.
Bare with me.
7/
We often hear that technical aspects should be left to technical people. Outsiders should not have anything to say. They should delegate and trust.
Indeed, when the two worlds (tech and non-tech) are engaged in a transactional relationship, that can work.
8/
Indeed, when the two worlds (tech and non-tech) are engaged in a transactional relationship, that can work.
8/
A transactional relationship can work just fine when you know upfront you are dealing with a commodity.
For most other things, you want a deeper alignment. Along these lines 👇
9/
For most other things, you want a deeper alignment. Along these lines 👇
https://twitter.com/jmwind/status/1493569361621176323
9/
For quite a while, software went by as a utility. Today however, it's hard for us to ignore how software is more like a medium. In the McLuhanian sense. This medium reflects our view of some part of the world, physical or otherwise.
10/
https://twitter.com/girba/status/1469755205541634055?s=20&t=eA55wQJP2bUnRZ34ShgHSg
10/
The medium is defined by the implementation not the vision. That's why alignment is so desirable.
But alignment never goes one way. We need to allow the implementation to affect the vision, too. When that happens we make room for opportunities that otherwise remain hidden.
11/
But alignment never goes one way. We need to allow the implementation to affect the vision, too. When that happens we make room for opportunities that otherwise remain hidden.
11/
But there is a complication.
I said that a system might look like this 👇. This implies that we can actually get an intelligible overview of the system.
12/
I said that a system might look like this 👇. This implies that we can actually get an intelligible overview of the system.
12/
In reality, the system most often appears opaque, especially to non-technical people.
"Of course it's opaque. It's code!"
If we want alignment, the inside of the system must become explainable.
"How?"
13/
"Of course it's opaque. It's code!"
If we want alignment, the inside of the system must become explainable.
"How?"
13/
Have you ever been in a situation when you thought that something was easy to add or change only to find out much later it was not? That happened because your mental model did not correspond to the reality of the system.
14/
14/
The thing is that the mental model will almost always be incomplete or wrong. And here is the other thing: it applies to technical people, too. The size of systems and the rate of changes inevitably lead to this.
15/
15/
As the existing mental model is not necessarily reliable, we should first want to get an overview of the system before doing anything. It turns out that we do spend most of the development energy doing just that.
16/
https://twitter.com/girba/status/1352734434613727232?s=20&t=u67AWXsEJecw2zKbgNAsrw
16/
We can optimize the way we figure the current system out many times compared to the current status quo without much investment. We can make the inside of our systems explainable. We just have to make it a priority.
17/
17/
Granted, any increase in alignment will improve the situation and can even get you further than most teams today.
But you can go much further. You just have to want to.
18/
But you can go much further. You just have to want to.
https://twitter.com/girba/status/1495165627773902848
18/
#MoldableDevelopment is a systematic method to make systems explainable.
We created #GToolkit to explore in practice the extent to which we can explain the inside of systems. More than a decade later, we still did not find the end of the road.
gtoolkit.com
19/
We created #GToolkit to explore in practice the extent to which we can explain the inside of systems. More than a decade later, we still did not find the end of the road.
gtoolkit.com
19/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
