10
kiki
1y

Since we’re adding new backronyms every day, I propose SIMPLE.

S - Spaghetti: write tapestry of code like a chef.

I - Interlinked: if the project has modules, they should all depend on each other (we are strongest when we can depend on one another).

M - Micromanaged: if the product owner doesn’t expect reports in the daily stand-up, do they even care?

P - Perplex: diversity for the codebase.

L - Lazy: Bill Gates once said “I choose a lazy person to do a hard job, because a lazy person will find an easy way to do it”, for example, without testing, collaborating with team members, or ensuring the feature works with anything else in the codebase.

E - Opinionated: because I believe E should stand for opinionated and everyone else will have to work around this with adapters. But E should mean Opinionated because Uncle Bab said so.

Comments
  • 2
    Not mine

    the "E" thing is by far the funniest
  • 1
    SAFe to work XD
  • 1
    I heard the antonym of DRY code the other day (Don't Repeat Yourself):

    WET code:

    We Enjoy Typing or
    Write Everything Twice.

    Goes nice with the description of working with legacy feeling like wading through damp, stagnant swamps.
    "Your code is damp"
  • 1
    @MammaNeedHummus I don’t believe in DRY. Their philosophy is that you should never write the same code twice, opting for 100% reusability instead. In reality, this means double inheritance and a lot of overhead. The code becomes sticky and cognitively complex. Everything becomes entangled.

    I just copy and paste my controllers instead. The real business often requires tiny changes in specific controllers, so I can change things granularly without breaking other controllers. They’re isolated, so if five years down the line someone needs to debug a controller, they know for a fact that everything is contained in a single file.
  • 0
    @kiki I don't think 100% DRY is ever possible just like you'll never get 100% test coverage or I'll ever reach my weight goal 😜.
    It's an asymptotic goal that has to be looked at pragmaticlly given the context of each change.

    80-90% DRY isn't bad, especially at the business logic level.
    You don't have to always use inheritance btw, you can use composition (Strategy pattern over Template pattern).
    Refactoring Guru website is a fab free resource for patterns like this to revert the issues you're seeing
  • 1
    ^ the Pragmatic Programmer book has a great section on DRY in the wild
Add Comment