De Ja Vu
A few years ago, I was managing a project in a big company. One of the features that we where developing was a caching system. We needed the caching to boost performance on a multi location, multi server application.
We developed in a normal Waterfall methodology, and the architect (a really funny and talented guy) came up after a few weeks with his design.
The design was really well thought out and the cache was ready to support – multiple databases with many different kinds of databases along with other things. At the time we believed that we had to design the system with the future in mind.
The question did arise:
Do we need to support Multiple Database Instances?
The Answer was, No, Not really, but if we are going to support it later then the redesign will take us ages.
When I asked the team to read and tell me what they think about: “You Ain’t Gonna Need It“, everyone took this personally. The architect started to feel that his job has been taken away from him:
“I am getting paid to think about future problems” and the developers where also taken aback. They have all been trained to create flexible systems and not flexible processes.
I failed to convince them, and a couple of years later, the caching system became what I call “a black hole”. No one knew exactly how it works, and everyone was scared to change it, because it was soo complex. The developers now said: “We didn’t really need multiple database instance, we spent ages designing and developing this feature, and every bug we find, has to support this feature too, which just complicates matters, because no one uses it but we cannot remove it.”
Still when I talk to them about YAGNI, they all say: “But when we thought ahead and designing the <fill in whatever feature>, we saved weeks and could implement <another featrure> in days. It would have taken us weeks without it”.
I have to remind them that it took months to design, implement and test before we even needed it.
YAGNI, Low Coupling and Testability
So, what has this got to do with Oren and Roy’s posts.
Well, I am getting the same feeling from them that I got from my architect.
Oren, so you found that a “Couple of weeks after introducing the IFileWriterFactory” you found another use for it, and it saved you time.
Good for you!
But this is NOT YAGNI, the opposite. It sounds just like that <fill in whatever feature> that my team was so proud that it had managed to predict.
What about all the other features that have no use? The price of doing this everywhere can be quite expensive. Most of the time (apart from tests) – You Just Ain’t Gonna Need It.
There was a time when we had no choice, you had to either Design for Testability or not test at all. But in these times this is no longer true.
So, Does testing – driving your design, actually create the best design? I am not sure.
It does one thing for sure, It creates a low coupled (modular) design. But low coupling is NOT a silver bullet. A good design has to take and BALANCE many factors, this is a complex task. Adding Testability to these factors might unbalance your design.
Quiz: Which is easier to maintain:
using(TextWriter writer = IoC.Resolve<IFileWriterFactory>().Create(filename)) writer.Write(text);