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
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 - 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
false cognates - conflation; ppl use the same term, unaware that they mean diff things; e.g. e'ybody has a diff meaning for "coding for passion" but use the same word; leads to data contradictions, stepping on toes, confusing unproductive discussions, meetings, and collaboration
problems arise when you don't take the nuances seriously when your team's say things like - "it's just a name, right?" or "same difference"; when a dev, sme, team, or org chooses stay unaware of or overlook context
what makes the problem worse is that some orgs culturally are resistant to the mindset and work processes that facilitate refactoring and continuous improvement
so although realizing the subtle differences, and the need to refactor, is a great thing and an opportunity to improve system design, ironically it's sometimes seen as a headache
but when you make the nuances in language/concepts known, your teams can make conscious refactorings to either combine; or to separate; and in turn avoid the false cognate, concept duplication hazards among/between dev teams
Domain Driven Design (DDD) made plain broke down to the bone gristle. cus i need that science to level up my code, but miss me with all the stuffy acronyms and jargon. 🧵
domain
- the actual problem
- what we're trying to solve with the code for the user
- the set of problems that the users ask the developers to solve
- the subject matter
domain driven
- problem focused
- to stay focused on the actual problem
For me, when the need for a new language, library, framework, shiny thing, etc pops up - i find that i usually take the same general steps
and the 7-bullet list i jotted down in my notes became this thread:
1. pick a language, any language. or framework, library etc.
no tech is perfect. don't sweat it the choice too much. they all have pros and cons - but do try to pick one that has good community adoption so you can get help when you run into blockers
"Always implement things when you actually need them,
never when you just foresee that you need them." - Ron Jeffries
i feel attacked 🙄
(over-abstraction is one of my guilty pleasures) 😅
like, sometimes i'll take that advice to "code to the interface" to the extreme, just cus i can, and i'll make everything an interface. what you can do with polymorphism and dependency injection is fun ...
but man is it an over-abstraction time suck when trying to just focus on "keeping it simple" KISS minimum viable product. gotta draw the line somewhere and make concrete classes and move forward ...