In my humble opinion, this is the most valuable type of writing when it comes to software development. Let's hope there will be more of similarly insightful posts. Thank you.
Good question. For the majority of my career I was involved in projects where design was the last thing anyone would think of. It was pretty much all about "make it work" (and then stop there). Which, I guess, explains the unparalleled popularity of the Big Ball of Mud software architecture. Everywhere we go nowadays we mostly see the equivalent of shanty towns when it comes to legacy software design (with few notable and praiseworthy exceptions to the rule).
It wasn't until I discovered and eagerly embraced TDD (and then later also embraced TCR) that I became acutely aware of the central role design plays in software. I first learned "First One, Then Many" from James Grenning who taught us the usefulness of the ZOMBIES formula (a nice implementation of the Permaculture design principle of Succession).
There are two things that I'd like to bring up when we're discussing software design:
1. YAGNI (You Aren't Gonna Need It)
2. The Finality Premise (software products are no different from physical products)
With YAGNI, we've been taught to abstain from adding any functionality that is not immediately needed (First One).
The Finality Premise is a constant thorn in my side. Wherever I go I notice that teams envision and treat software systems the same way they would treat physical objects -- once the blueprint of an object gets firmed up and signed off, all that's left to be done is to proceed with connecting the dots and painting by numbers to implement that blueprint. It's pretty much equivalent to brick laying.
I am forever struggling (unsuccessfully) to point out that software is not like that. Not even close. Alas, it seems to be a losing proposition.
Someone of your intellectual capacity should step in and bust the Finality Premise in software. I've tried to do it and I've failed (many times).
Apologies for the rant, but you poked me asking about a story from my career.
I don't experience it as discipline in "you should floss" sort of way. Once I'm in the flow of it, well, any code I write that doesn't match my tests simply disappears. Poof. No discipline required.
The two ways to keep code around are 1) not writing tests (which I'm not about to do) and 2) working in tiny steps.
Before I learned about TCR from Kent, I was kinda doing it manually. I would make a micro-change, run the tests (manually), and if any test fails, I'd just do git reset --hard (also manually). I actually got that hint from Ron Jeffries, who very eloquently described the process somewhere (I lost the link).
With TCR, you just fully automate that tedium. However, everything comes with a price, and so that practice can cause some heartache because not only your code disappears, your test also disappears!
What about a succession for “multitenancy”? Following with te example, the user initially wants to create the contracts for a single organization (“tenant”) but at some point will ask for contracts that are contained in a specific organization. Would you apply succession here?
Always. I don't know if you remember Slack when it required a separate login for each workspace. Fixing that required deep architectural work.
Imagine an alternate history in which an early Slack engineer made a different choice & one login would be fine. It would have been a small change at that time.
Now imagine an alternate history in which an early Slack engineer took extra time to implement multiple workspaces per login & Slack missed a key sale & went belly up.
I work hard to keep code flexible at the tactical level, then I use that flexibility to enable strategic improvisation.
Oct 12, 2023·edited Oct 12, 2023Liked by Kent Beck
Thank you for your answer, I fully agree with it. We recently moved a platform service to be multi-tenant. I tried to demonstrate that was possible to do an evolving design based on small refactors. The team felt more confortable with creating a new version. My feeling is that, with a good refactor strategy, the inclusion of multi-tenancy had been easier. Looking forward for your book. I'm sure that it will provide a lot of help to take better design decisions. I like very much the concept of Succession and the idea of having a taxonomy of them.
As an amateur software engineer in their second job, I value this post so much. I keep running into these situations and never had a proper framework to think about it or to justify my decision choices with. Thank you for this. Looking forward to more!
In my humble opinion, this is the most valuable type of writing when it comes to software development. Let's hope there will be more of similarly insightful posts. Thank you.
Does it remind you of a story from your career?
Good question. For the majority of my career I was involved in projects where design was the last thing anyone would think of. It was pretty much all about "make it work" (and then stop there). Which, I guess, explains the unparalleled popularity of the Big Ball of Mud software architecture. Everywhere we go nowadays we mostly see the equivalent of shanty towns when it comes to legacy software design (with few notable and praiseworthy exceptions to the rule).
It wasn't until I discovered and eagerly embraced TDD (and then later also embraced TCR) that I became acutely aware of the central role design plays in software. I first learned "First One, Then Many" from James Grenning who taught us the usefulness of the ZOMBIES formula (a nice implementation of the Permaculture design principle of Succession).
There are two things that I'd like to bring up when we're discussing software design:
1. YAGNI (You Aren't Gonna Need It)
2. The Finality Premise (software products are no different from physical products)
With YAGNI, we've been taught to abstain from adding any functionality that is not immediately needed (First One).
The Finality Premise is a constant thorn in my side. Wherever I go I notice that teams envision and treat software systems the same way they would treat physical objects -- once the blueprint of an object gets firmed up and signed off, all that's left to be done is to proceed with connecting the dots and painting by numbers to implement that blueprint. It's pretty much equivalent to brick laying.
I am forever struggling (unsuccessfully) to point out that software is not like that. Not even close. Alas, it seems to be a losing proposition.
Someone of your intellectual capacity should step in and bust the Finality Premise in software. I've tried to do it and I've failed (many times).
Apologies for the rant, but you poked me asking about a story from my career.
I hadn't heard of TCR before... Sounds interesting but requires even more discipline than TDD on its own, I imagine?
I don't experience it as discipline in "you should floss" sort of way. Once I'm in the flow of it, well, any code I write that doesn't match my tests simply disappears. Poof. No discipline required.
The two ways to keep code around are 1) not writing tests (which I'm not about to do) and 2) working in tiny steps.
Before I learned about TCR from Kent, I was kinda doing it manually. I would make a micro-change, run the tests (manually), and if any test fails, I'd just do git reset --hard (also manually). I actually got that hint from Ron Jeffries, who very eloquently described the process somewhere (I lost the link).
With TCR, you just fully automate that tedium. However, everything comes with a price, and so that practice can cause some heartache because not only your code disappears, your test also disappears!
What about a succession for “multitenancy”? Following with te example, the user initially wants to create the contracts for a single organization (“tenant”) but at some point will ask for contracts that are contained in a specific organization. Would you apply succession here?
Always. I don't know if you remember Slack when it required a separate login for each workspace. Fixing that required deep architectural work.
Imagine an alternate history in which an early Slack engineer made a different choice & one login would be fine. It would have been a small change at that time.
Now imagine an alternate history in which an early Slack engineer took extra time to implement multiple workspaces per login & Slack missed a key sale & went belly up.
I work hard to keep code flexible at the tactical level, then I use that flexibility to enable strategic improvisation.
Thank you for your answer, I fully agree with it. We recently moved a platform service to be multi-tenant. I tried to demonstrate that was possible to do an evolving design based on small refactors. The team felt more confortable with creating a new version. My feeling is that, with a good refactor strategy, the inclusion of multi-tenancy had been easier. Looking forward for your book. I'm sure that it will provide a lot of help to take better design decisions. I like very much the concept of Succession and the idea of having a taxonomy of them.
Leaping is always preferable if you can ignore the risk and cost of failure.
Unfortunately, it wasn't the case. XD
As an amateur software engineer in their second job, I value this post so much. I keep running into these situations and never had a proper framework to think about it or to justify my decision choices with. Thank you for this. Looking forward to more!
Useful approach. Feels a lot like database migrations.
Danke