Discover and read the best of Twitter Threads about #SoftwareDesign
Most recents (11)
I thought quite a bit about this extension of Conway's Law, which is taking the flexibility of the system under change into account. Here are some unsorted and maybe random thoughts from my experience of doing an inverse Conway maneuver on a larger scale at Flix. #SoftwareDesign
Some context: in 2018 we were taking extreme measures to get a grip on our monolithic software system that had been growing dramatically over 6 years, going from 8 to ~170 devs and multiple million LOC. And yes, an inverse Conway maneuver (ICM) is an extreme social intervention.
A lot of planning and preparation went into the execution: strategic system boundary design, stream alignment and platform capabilities around internal and customer facing products. The product owners (in the true sense of the word) prepared meaningful vision and mission docs.
object oriented programming is where you design each element in your code, based on rules around making well-formed classes and objects; we say domain driven design, based on "modeling the domain", is oop done right:
basically that means - solving the right problem
basically that means - solving the right problem
domain driven design produces higher quality software; it's about #domainModeling
which is basically #understandingTheProblem that the users want solved
which is basically #understandingTheProblem that the users want solved
3/3 cus who wants to go to work to hack away at some code that's not even solving the right problem
#objectOrientedProgramming #domainDrivenDesign #domainModeling #softwareDesign #codeNewbies
#objectOrientedProgramming #domainDrivenDesign #domainModeling #softwareDesign #codeNewbies
The progression from coding to designing architectures is the practice of refactoring the structure and behavior of elements, at increasingly higher levels of scale.
#softwareDesign #softwareArchitecture
#softwareDesign #softwareArchitecture
... where system elements can be
field/ var/ param -> method/ function/ procedure -> class -> aggregate/ composite/ collection -> module/ package -> application/ service -> sub-system -> system -> system of systems
#codenewbie #systemDesign
field/ var/ param -> method/ function/ procedure -> class -> aggregate/ composite/ collection -> module/ package -> application/ service -> sub-system -> system -> system of systems
#codenewbie #systemDesign
... where at each level of scale, the goal of refactoring is to win the trade-offs between time, cost, quality
#architects #management #visionary #leadership
#architects #management #visionary #leadership
the culture is more important than
the org chart is more important than
the subject matter expertise is more important than
the code and design is more important than
teh tech stack/language/framework/etc
...
the org chart is more important than
the subject matter expertise is more important than
the code and design is more important than
teh tech stack/language/framework/etc
...
in other words:
the cultural architecture is more important than
the org architecture is more important than
the conceptual architecture is more important than
the technical application architecture is more important than
the technical infrastructure architecture
the cultural architecture is more important than
the org architecture is more important than
the conceptual architecture is more important than
the technical application architecture is more important than
the technical infrastructure architecture
so you think you can architect
#conwaysLaw #asAboveSoBelow #ddDesign #ooDesign #softwareDesign #softwareArchitecture #domainDriven #techAgnostic
#conwaysLaw #asAboveSoBelow #ddDesign #ooDesign #softwareDesign #softwareArchitecture #domainDriven #techAgnostic
on an agile team, whenever someone uses the word "story" and "requirement" to mean the same thing, an angel loses her wings
how do you point out the benefits of using one over the other?
"story" frames with problem, with the person at the center
"requirement" focus on the product, teh soul-less tech
"story" frames with problem, with the person at the center
"requirement" focus on the product, teh soul-less tech
it's better to talk about the user, the user scenario, the actual problem, (the domain), than it is to base your work on clever algorithms and hyped up, buzzwordy shiny tech
tell me about the concepts and the contexts before you try to sell me on the tech
#softwareDevelopment #softwareDesign
#softwareDevelopment #softwareDesign
when describing a system, we devs and archs, usually focus on the tech stack; sometimes we'll touch on the short term technical milestones; we'll rave and ramble on about kafka, graphql, kubernetes, react, django or whatever;
and that stuff's all cool, but i care more about ...
and that stuff's all cool, but i care more about ...
the one liners you'd give non tech stakeholders that answer?:
a) what does the system do?
b) what/who is the core downstream sub/system, user?
c) upstream
unpopular pov? but, it's just more fun to conceptualize those things first
#domainDriven #ooDesign #ddDesign
a) what does the system do?
b) what/who is the core downstream sub/system, user?
c) upstream
unpopular pov? but, it's just more fun to conceptualize those things first
#domainDriven #ooDesign #ddDesign
overlooked but obvious signs that your dev team might be struggling with implicit differences in povs with another team (implicit model context diffs)?
- coded interfaces don't match up
- unexpected functionality/bugs pop up
- confusing unproductive discussions and meetings
- coded interfaces don't match up
- unexpected functionality/bugs pop up
- confusing unproductive discussions and meetings
when you un/intentionally try to intersect two sets of povs/concepts that are subtly different from each other, you get:
- duplicate concepts
- false cognates
- duplicate concepts
- false cognates
duplicate concepts - i.e. two classes in two different places, that represent the same concept; you get all the problems of WET code; have to worry about making changes in two places; and having to keep em in sync; but because the diff; non DRY
i used to think programming was all math and algorithms. but once i started to think about design and architecture more like like graphic design, poetry and sculpture it made it much less intimidating and much more fun to approach any design challenge
#ddDesign #softwareDesign
#ddDesign #softwareDesign
this is why i am a domain driven design fan. i forget who said it but it's true. DDD is OOD done right. i think it's is the kind of paradigm that allows a more artistic view due to the abstraction, modularization, and other principles inherent in OOD. but i digress ...
... but anyways yea where are my kindred "software development as art, craft, poetry, sculpture, portraiture, design" ppls? shiiyt it's hard enough to find other back end devs on here so i aint holding my breath 🤷🏾♂️😅 .. still ill be over here hyped off of design... get at me ✌️🏾
think loose coupling and high cohesion of concepts before that of classes
#softwareDesign #standaloneClasses #dddRefresher
#softwareDesign #standaloneClasses #dddRefresher
you want #looseCoupling. standalone classes are a good thing. generally, the more of them you have in your design, the better it is in the sense it'll be easier it is to understand.
in designing your class, try to minimize the dependencies you have to other classes to zero if possible; keep these as primitives wherever it makes sense:
- field types
- method param types
- method return types
- types of local variables in methods
--- any other kinds?
- field types
- method param types
- method return types
- types of local variables in methods
--- any other kinds?
sometimes the kind of refactoring that clears the way for easier extension, is not a refactoring toward this or that design pattern, but a refactoring to support a deeper conceptual understanding of a functional use case/ user scenario
#conceptualContours #ddDesign
#conceptualContours #ddDesign
oh you refactor refactor 😅
study and understand a user scenario or business process; then model and design their concepts
think of principles like high cohesion and low coupling, but in terms of concepts first, then classes and code mechanisms
#ddDesign #softwareDesign
think of principles like high cohesion and low coupling, but in terms of concepts first, then classes and code mechanisms
#ddDesign #softwareDesign
we love complexity so much that we had to make up a "principle" called #KISS that we use to reign ourselves in when we run into problems. why?
- is it that we wanna look smart so we over-engineer shit?
- is it that we dont know the problem well enough to KISS?
- prolly both 🤔
- is it that we wanna look smart so we over-engineer shit?
- is it that we dont know the problem well enough to KISS?
- prolly both 🤔
how to be better at KISS?
1) sit down, be humble (Kendrick voice), otherwise at least remember that simplicity is the best flex
2) ask mad questions about the problem ur tryna solve til you understand it so well u cant explain it to a 5 yr old
#codeNewbie #programming
1) sit down, be humble (Kendrick voice), otherwise at least remember that simplicity is the best flex
2) ask mad questions about the problem ur tryna solve til you understand it so well u cant explain it to a 5 yr old
#codeNewbie #programming
