Over the last few weeks, one of the classic software development issues — To YAGNI, or not to YAGNI, as Hamlet would not have said it — has been re-opened through a series of blog posts such as Ron’s great article . Now it’s time for UV to weight in!
Let’s step back and review the basics, first. What’s YAGNI? Old-time software dev slang from the dawn of the agile era (what we used to call “XP” or “extreme programming” when I was a young little newbie without a receding hairline) that meant: “you’re not going to need it.”
The concept is simple at its heart: clients are often, correctly, concerned not just about their current needs, but they want to anticipate their future needs, and build with those in mind. YAGNI argues that you put focus on your current needs first and foremost. Get shit done rather than worry about the future.
Of course, there are a ton of nuances to it as well. It’s often used as a simple catchphrase today, but it was originally just one piece of the XP puzzle that works well with the rest of XP. You can push back so long as you’re doing your unit tests, refactoring, and everything a good developer should be doing.
Doesn’t it make sense? You should only build what’s needed, and not waste time on dashboards and details that will never be used and aren’t needed. It’s a tautology like 1 = 1, right?
Or is it?
Here’s one possible way to think about software development. (Don’t worry, this will tie back into YAGNI in a moment: bear with me!) Picture this image in your mind. You’re surfing the web, on your laptop or desktop computer. Maybe your internet connection is slow (insert the AOL “you’ve got mail” sound pinging here, in your minds!). You load a page, a bit slowly. It loads a big image that is fuzzy at first — you can see the outlines, but can’t really make it out. After a second it becomes a bit clearer, and you can get a bit more understanding of what it is: “Oh, someone posing for a selfie, but I can’t quite see where or what.” And then after another moment, suddenly, it becomes crystal clear.
(Note that this is the opposite of impressionist art: you see it and it’s amazing, and then you walk a bit closer to it and it gets fuzzy, and then you walk right up to it that it’s so blurry you can’t even tell that it’s supposed to be art!)
What’s great about this image loading metaphor is that it shows clearly (or blurrily, in the literal sense) that the process of looping through something and with each loop, it becomes clearer and more well-defined — and closer and closer to the target that you, dear reader, have in mind.
This is a bit how UV approaches client-driven software development. We plan out what the client wants, and we build it. And during the process of building it, and our closer interaction of working together, we and the client always learn more about what else they want and how better to do. So, upon a second pass, the picture is filled in with more details and granularity. And then the third pass often entails all the little perfections, and solving minor imperfections, which make sense to do at the end of the cycle. (Oh, Pallas Athene, how I shall pray to thee that the caching issues we’re making even better now go as smoothly as one of Zeus’ hunting sprees!)
Let’s compare this with YAGNI. YAGNI is too-often implemented with a “we’ll deal with it later” approach. Don’t worry about scaling, the YAGNI teams often say: if the software gets popular, we’ll rewrite it to scale then. (Yes, that’s a reasonable trade-off a team may purposefully make.) But with the photo coming into focus while it loads, the key point is: the photo image is already on the server. There’s already a clear picture of what the image is. It’s not a free-for-all, let’s slap something together quickly and then put out fires. It’s a predefined vision of the various iterations and phases needed, and then approaching them one by one, while keeping the Agile insight (iteration 3.1.4 may change between the time it is planned and built) in mind throughout the process.
Of course, this approach is effectively the same as the sophisticated approach towards YAGNI itself. So perhaps the UV take could be reframed as:
We’re YAGNI fans, but in a sophisticated & planning-centric approach to it. Take the best of YAGNI, without the worst.
And that comes to the heart of one of UV’s values. At UV, we are extreme in a few core beliefs and principles of ours but, those aside, we tend to be moderate and flexible. And as a result, we have a moderate take on the YAGNI question.
On the one hand, we work closely with all clients to design precisely what they want and what they tell us they need.
On the other hand, as part of our onboarding process, we work closely with each client to decide, hand in hand with them, which features they really need or not.
And often, due to the basic laws of, well, “time” (Thank you, Chronos, for not having eaten us yet!), there’s usually a time-cost trade-off and at the heart of the onboarding is figuring out what the right balance is for each client.
What balance are you looking for? Just drop me a note and tell me. I’m curious to learn about you. Yes, you.
