The Art of Harvesting AbstractionFiled Under Architecture
Often I watch senior developers so hell-bent on preventing DRY through code abstractions, that they fall victim to the YAGNI principle. By being proactive you are opening yourself to wasting time creating abstractions that may never be needed or worse adding unwanted noise to your code.
Refactoring to abstractions should be a reactive response to DRY, not a proactive prevention plan. Being reactive to problems is a very “agile” approach, but even practitioners of agile processes sometimes get caught with their pants down running BUFD centric practices. To combat this problem, I created a term to help others overcome premature abstractions – Abstraction Harvesting.
Software is like a garden, you can’t 100% force or predict what is going to grow; however, you can react to current situations to better steer results in a favorable direction. The only rule of software abstraction harvesting is that you must have target software to abstract. What is the purpose of creating abstractions, if you don’t yet have the problem-solving concrete implementations? This is the equivalent of running the tractor over the field before the first sprout is even visible.
Before software can be reusable it first has to be usable. -Ralph Johnson
If we look closely at both DRY and YAGNI we find an almost sequential relationship. Without a DRY situation, we can not have YAGNI, but it is apparent that you can have a YAGNI situation without DRY. This is the equivelent of putting the cart before the horse. The concept of “Abstraction Harvesting” helps put the order back in place so you can prevent both DRY and YAGNI.
Have you been guilty of premature abstractions? If so, I want to hear the horror stories…