The following three terms are often used in Agile. I appreciate that they have value, but I want to reiterate that they are heuristics, not panaceas.
DRY
Don’t Repeat Yourself. A lot of good intentions here, however, domain modeling is not that easy. Just because code looks the same, does not mean that implementations won’t change, especially across context boundaries.
If you spend time DRYing up your code early, you don’t get to clearly observe divergence (and convergence).
Repeat yourself until you’re confident (and perhaps dial down your confidence). It’s better to be late to the DRY party. Aim at being consistent, following clear patterns and precise domain oriented language. This will make it easier to discover emerging domain contexts and behaviors. Eventually you can DRY up your code, confident that you understand what it is you’re working with.
YAGNI
You Ain’t Gunna Need it!
What specifically are you not going to need? To me, this term can be thrown at any biased argument, pro or con.
Apply YAGNI liberally, just ask the other question ‘Am I going to need this?’.
Unless everyone is willing to eat a lot of tech debt, you are going to need clean code, separation of concerns, cohesion, loose coupling, lightweight architecture and consistency.
The assumption made when throwing yet more business logic into a heavy data model (think traditional ActiveRecord) is that you may not need to keep the functionality or it will change. Thus, taking the time to separate the code is not “something you will need”.
I implore you, consider it from a different angle. If you end up not needing the functionality, it’s a lot easier to remove (or modify) when it’s loosely coupled, so perhaps that time is always well spent?
Do the Simplest Possible Thing
It’s a great suggestion, don’t overcomplicate a situation until you absolutely must. Don’t implement for a future that is always uncertain. However, doing something that is simple is not the same as doing something that is ‘easy’. Avoid the ‘easy’ trap.
My mother used to say that I’m not lazy, I am the ‘Lazy Man’s workload’. “What’s that?”, I asked.
The lazy man’s workload is the work that a lazy man has already gotten out of the way. You avoided it, and will have to do it when it’s less convenient.
When tasked with cooking dinner, it could well be easier to not tidy the kitchen before or after. At least, for the sake of the task, this is true. However, if I then have to clean the gunk off last night’s dinner plates tomorrow, perhaps it’s not so easy.
‘Easy’ avoids effort, however this does not mean the effort will not need to be faced. If the future workload increases because of accumulated, unfulfilled effort, this is technical debt. In the interest of short feedback cycles and reducing cognitive overhead, it may be worth picking something ‘simpler’ than the easiest approach.
