rasiim kyan Profile picture
Aug 2, 2020 8 tweets 2 min read Read on X
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

#ddDesign #ooDesign #softwareDesign

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with rasiim kyan

rasiim kyan Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @refactorfiend

Oct 18, 2020
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
Read 122 tweets
Oct 17, 2020
switching from management roles to individual contributor roles and still making the same if not more bread is a slept on power move
moral of the story if/when the toxicity and burnout gets to be to much - make lateral moves
with the quickness #manifesto
Read 6 tweets
Sep 30, 2020
How do y'all like to ramp up on new tech?

🧵
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
Read 13 tweets
Sep 30, 2020
re: adding code comments with respect to the single responsibility principle

As a #selfDocumentingCode fanatic, I do appreciate that some kinds of comments go a long way:

1/3
One comment/ blurb (1-3 lines):

- at the top of a class about the single responsibility of the class

- in the project readme/wiki about the single responsibility of the application

2/3
Some benefits:

- helps keep the class/application at the appropriate size

- helps make the class/application be easier to understand/work-with

3/3
Read 4 tweets
Sep 30, 2020
phrases never (before tonight) heard in a #PresidentialDebate

"shut up man"
"do you understand what this clown is doing"
"shush for a minute"
"lemme shut you down for a second"
"he's a fool"
"nobody cares"

I feel some more coming on
"you're the worst president evarr"
Read 4 tweets
Sep 28, 2020
"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 ...
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(