Please respond with moments of dilemma around software design. Please be specific (I’ll post one of my own as an example). The dilemma can be a “what?”, like, “How do I design this system?” It can be a “who?”, like, “We need to change the design but who does it because we’re all busy?” It can be a “when?”, like, “We need to change the design so it’s easier to change behavior but we have to make all these behavioral changes first.”
Modules are good for clean code and reuse. They also introduce overhead. Too many modules too early might make development slower or we might get the modularity wrong. Assuming we discover what we are making as we make it, how early do we start trying to modularize?
"Earlier" capitalizes on getting reuse later that we can't imagine now. It also might incur redesign costs as we get smarter.
"Later" keeps development simpler for now as we discover. It also could keep us from optimal levels of "clean".
This question has been perennial and fractal to me. It comes up when working on a single OO class, react components, systems, and systems of systems.
We want to get to stricter module boundaries from our current Ruby/Rails udon bowl. Do we draw hard boundaries right away or softly pull things apart a little at a time? Does it matter that our app and our team are growing at the same time?
When do we extract this chunk into a reusable thing? Now, when I have a good idea what it would look like and am interested in trying? or later, when it becomes clear that we need something reusable but we've already copied and pasted and fiddled slightly 12 times?
do we maintain an ineffective convention for the sake of consistency, or de we introduce a different way of doing things which might be better but end up with multiple approaches? or do we change all the instances at once, which might take significant effort with no value for our clients?
My colleagues and me I tend to try put frameworks where we think they belong. At the boundaries of the system. In java speak, framework annotations in business logic appear smelly to me. They give me shivers as it ties design to the framework. It is not uncommon though to find such things. For example the Axon framework for CQRS, DDD and Event Sourcing, encourages people to litter aggregates with framework specific annotations. It must give some benefits as well.
I am not sure if this one fits in the sort of dilemmas, your looking form but....
As an independent developer / trainer / coach I have been in several situations where dependencies and concerns where all over the place. When working with teams towards managing dependencies (often towards a hexagonal approach to design, putting business logic at the heart to the components/application), people get utterly confused at times. As an example I was working with a java development team, where some members had serious trouble with the emerging Hexagonal structure. As if they where looking for their familiar Controller - Service - Jpa Repository structure. Even though that very structure has given them some serious coupling issues.
The Java community is full of teams that are used to some structure, just like the Rails community is (albeit a somewhat different structure)
Now heres the sort of dilemmas and doubts I sometimes have. Are this (for them) new application architecture ideas, helpful in this? May it help the team from the frying pan into the fire. What happens when anyone in the team leaves? Have we, as a team embedded a design approach that survives changes in the team? Will new people enter the team saying "you're doing it all wrong?" And then what happens?
My most frequent moment of dilemma around software design is when teams start discussing Definition of Done (DoD). To me, DoD just feels so utterly wrong, and yet many seem to feel that it's a Holy Grail in software. But as we all know, it's a real rabbit hole. There is no bottom to hit when you slip into discussing DoD. How do we wean people off the pesky finality premise?
We’re building a new frontend in isolation from another team that maintains the API. Design patterns are well-established in the API. Do we accept that contract, and if we want changes, when and how do we ask for them? If the contract breaks, how do we document that and request a remedy?
One of the classic Responsibility Virus problems: we need to decentralize design decision-making, but the technical stewards don't trust the hoi polloi to make "good-enough" design decisions, so they hoard those decisions, which starves everyone of opportunities to learn and grow.
Do the Stewards give the Hoi Polloi a chance to fail in The Real Code Base, or do they set up a Sandbox in which they can play and bump their heads and learn and grow?
(And this ignores whether the whole environment needs to be this parental. One step at a time.)
There is a dilemma I've been having and pendulating from side to side for years when doing software design. Shall I make it work first then listen to my code to make it the way it wants to be? Or shall I do a direct mapping to the business domain? I found that TDD, most of the code smells, and design principles like high cohesion loose coupling focus on my first way. It is also my default way of coding. When refactoring and I need inspiration, I will look at the business domain, but not eagerly.
Direct mapping to the business domain could be silly when solving challenging algorithm problems; mapping doesn't automatically generate the solution. But it makes a lot of sense for most of the application software we are writing and maintaining as a group. I know @Kent you focus a lot on communicative code (I remember seeing somewhere that you spend more than 70% of your time thinking about names when programming). Will you go as far as having an (almost) direct mapping to the business domain in your design?
My team recently started adapting some of Shape Up to suit our needs. We're working in 6-week cycles and have well-defined work to deliver within that period.
Out of habit, I planned our work to maximize work in progress (minimize blockers), but this resulted in me hopping back and forth working on multiple unrelated, incomplete features that couldn't be tested by QA. Half-way through the cycle, QA raised concerns about having enough time to test and provide feedback.
Now I'm trying to find the right balance of:
- deploying early and frequently enough for QA,
- maximizing work in progress, and
- ensuring we don't delay the tougher, more time-intensive challenges until the end.
do we add this feature with the least effort, likely making the system more convoluted, or do we put more effort to straighten things up? how can we tell apart the right moments to extract easy value now vs those to invest in potential value?
Should we document our overall architecture and all the architectural choices? If yes how? Where? In the same repository of the project? What about an architecture that spans multiple repositories?
Monolith vs. Modules
Modules are good for clean code and reuse. They also introduce overhead. Too many modules too early might make development slower or we might get the modularity wrong. Assuming we discover what we are making as we make it, how early do we start trying to modularize?
"Earlier" capitalizes on getting reuse later that we can't imagine now. It also might incur redesign costs as we get smarter.
"Later" keeps development simpler for now as we discover. It also could keep us from optimal levels of "clean".
This question has been perennial and fractal to me. It comes up when working on a single OO class, react components, systems, and systems of systems.
We want to get to stricter module boundaries from our current Ruby/Rails udon bowl. Do we draw hard boundaries right away or softly pull things apart a little at a time? Does it matter that our app and our team are growing at the same time?
When do we extract this chunk into a reusable thing? Now, when I have a good idea what it would look like and am interested in trying? or later, when it becomes clear that we need something reusable but we've already copied and pasted and fiddled slightly 12 times?
do we maintain an ineffective convention for the sake of consistency, or de we introduce a different way of doing things which might be better but end up with multiple approaches? or do we change all the instances at once, which might take significant effort with no value for our clients?
My colleagues and me I tend to try put frameworks where we think they belong. At the boundaries of the system. In java speak, framework annotations in business logic appear smelly to me. They give me shivers as it ties design to the framework. It is not uncommon though to find such things. For example the Axon framework for CQRS, DDD and Event Sourcing, encourages people to litter aggregates with framework specific annotations. It must give some benefits as well.
I am not sure if this one fits in the sort of dilemmas, your looking form but....
As an independent developer / trainer / coach I have been in several situations where dependencies and concerns where all over the place. When working with teams towards managing dependencies (often towards a hexagonal approach to design, putting business logic at the heart to the components/application), people get utterly confused at times. As an example I was working with a java development team, where some members had serious trouble with the emerging Hexagonal structure. As if they where looking for their familiar Controller - Service - Jpa Repository structure. Even though that very structure has given them some serious coupling issues.
The Java community is full of teams that are used to some structure, just like the Rails community is (albeit a somewhat different structure)
Now heres the sort of dilemmas and doubts I sometimes have. Are this (for them) new application architecture ideas, helpful in this? May it help the team from the frying pan into the fire. What happens when anyone in the team leaves? Have we, as a team embedded a design approach that survives changes in the team? Will new people enter the team saying "you're doing it all wrong?" And then what happens?
Sort of a cultural/design impact dilemma guess.
My most frequent moment of dilemma around software design is when teams start discussing Definition of Done (DoD). To me, DoD just feels so utterly wrong, and yet many seem to feel that it's a Holy Grail in software. But as we all know, it's a real rabbit hole. There is no bottom to hit when you slip into discussing DoD. How do we wean people off the pesky finality premise?
We’re building a new frontend in isolation from another team that maintains the API. Design patterns are well-established in the API. Do we accept that contract, and if we want changes, when and how do we ask for them? If the contract breaks, how do we document that and request a remedy?
One of the classic Responsibility Virus problems: we need to decentralize design decision-making, but the technical stewards don't trust the hoi polloi to make "good-enough" design decisions, so they hoard those decisions, which starves everyone of opportunities to learn and grow.
Do the Stewards give the Hoi Polloi a chance to fail in The Real Code Base, or do they set up a Sandbox in which they can play and bump their heads and learn and grow?
(And this ignores whether the whole environment needs to be this parental. One step at a time.)
There is a dilemma I've been having and pendulating from side to side for years when doing software design. Shall I make it work first then listen to my code to make it the way it wants to be? Or shall I do a direct mapping to the business domain? I found that TDD, most of the code smells, and design principles like high cohesion loose coupling focus on my first way. It is also my default way of coding. When refactoring and I need inspiration, I will look at the business domain, but not eagerly.
Direct mapping to the business domain could be silly when solving challenging algorithm problems; mapping doesn't automatically generate the solution. But it makes a lot of sense for most of the application software we are writing and maintaining as a group. I know @Kent you focus a lot on communicative code (I remember seeing somewhere that you spend more than 70% of your time thinking about names when programming). Will you go as far as having an (almost) direct mapping to the business domain in your design?
My team recently started adapting some of Shape Up to suit our needs. We're working in 6-week cycles and have well-defined work to deliver within that period.
Out of habit, I planned our work to maximize work in progress (minimize blockers), but this resulted in me hopping back and forth working on multiple unrelated, incomplete features that couldn't be tested by QA. Half-way through the cycle, QA raised concerns about having enough time to test and provide feedback.
Now I'm trying to find the right balance of:
- deploying early and frequently enough for QA,
- maximizing work in progress, and
- ensuring we don't delay the tougher, more time-intensive challenges until the end.
do we add this feature with the least effort, likely making the system more convoluted, or do we put more effort to straighten things up? how can we tell apart the right moments to extract easy value now vs those to invest in potential value?
How do I organize my code? I like folder per feature but I can see that most projects use folder per functionality...
Another hard one is what FE framework do we choose?
Should we document our overall architecture and all the architectural choices? If yes how? Where? In the same repository of the project? What about an architecture that spans multiple repositories?