Yagni

http://martinfowler.com/bliki/Yagni.html

by petercooper • 11 years ago

271 178 11 years ago

beat4• 11 years ago

As always, it's a joy to read Martin Fowler.

It's so, so hard to resist the siren song of premature optimization, though. It's even harder in a corporate environment where "Well, why didn't you plan for that?" is a question lurking behind every failure or delay. Overplanning isn't punished.

mkozlows7• 11 years ago

This is becoming less true over time. As enterprises start adopting Lean practices, it becomes obvious to everyone why building something now when you won't use it for months is waste.

beat4• 11 years ago

If there's one thing enterprises don't give a flying fsck about, it's waste.

After a couple decades of mostly-enterprise development, I've learned something really important - it's better to not be wrong than to be right. Thus the overbuilding and risk aversion. Frankly, this is the only real advantage startups have over the enterprise - the ability to take risk.

briandear• 11 years ago

I disagree. If overbuilding or over planning is wrong. Then the question comes as to why you spent $200k building a feature that just got thrown out. Or worse, they try to use a unneeded feature just to justify the fact that it was built.

beat4• 11 years ago

I didn't say it isn't wrong. I said it isn't punished. That's a very, very different thing.

Enterprise environments encourage toxic behavior in numerous ways. This is one of them. Risk aversion is generally more important than cost control in the enterprise. Conway's Law in action, if you think about it.

pbreit9• 11 years ago

In startups, overplanning is punished by company failure.

Silhouette22• 11 years ago

In startups, almost everything is punished by company failure.

Another example is failing to plan ahead far enough that you can maintain your first mover advantage when a competitor comes along and already has the benefit of learning from your mistakes so far.

endymi0n• 11 years ago

We have one rule when planning product features: Everyone may shout YAGNI at every time. Saved us so much time and complexity, it's incredible.

On the other hand, I have a love/hate relationship with YAGNI, as it requires careful weighing - additional features that need to be reflected in architectural changes which would not only take refactoring code but API and data model changes as well, possibly with data migrations, coordinated across multiple teams are a completely different picture. The costs of building it now may be an order of magnitude cheaper than doing it later. Further down the road, startup mechanics and traction apply as well. If you have an order of magnitude more resources to fix YAGNI later, it might be worth the additional speed right now. I feel that putting all of these into context and doing something that makes sense is just freaking hard every single time.

angersock2• 11 years ago

Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.

And here is where the actual frontlines of the battle are fought--because it's needlessly verbose and abstract architectures (or what people think are them, anyways) that are railed against by folks chanting "yagni yagni yagni".

This article neatly sidesteps the actual thorny issue of "well, when is designing extra actual a good idea?" by ignoring one of the biggest use-cases of yagni.

oinksoft• 11 years ago

This is just my experience, but "YAGNI" is often shorthand for "I don't want to think about it." I'm not talking about criticisms of wasteful design/features, but somebody actually saying "YAGNI" with little elaboration. It's imprecise and lazy.

angersock2• 11 years ago

Yep.

I especially hate hearing it from well-meaning folks who, say, bring it up whenever talking about architecture decisions and devops stuff, but apparently see no reason not to spend one or two weeks fiddling around making The World's Best Angular Form Field Input Directive, or painstakingly tweaking the secondary and tertiary colors in their alert boxes or some damn fool thing.

EDIT:

At this point, especially in the web, I'm now considering Diarrhea Driven Development: shit out as much as fast as you can and make it as viral and sticky as possible.

wrsh07• 11 years ago

Agreed -- the article cleanly argues for Yagni by moving the heart of the discussion to a bolded sentence near the end.

apalmer• 11 years ago

I hear you, I think this article is really good for someone who isn't familiar with the term YAGNI. However as the above poster mentioned it sidesteps a big issue which is when YAGNI is wrong.

Generally I feel like YAGNI is appropriate for features but not appropriate for architecture. I feel like the purpose of architecture is to try to plan ahead, or to make the determination how far ahead one is attempting to plan. Its perfectly find to architecturally choose not to support something, but it should be a conscious decision.

Jare• 11 years ago

If I may extend your metaphor, the problem then becomes the scaffolding that lies between architecture and features. Another attempt at a rule of thumb is to ask the question: can I describe how this likely-but-not-yet-needed change would be addressed in the code? If there's no answer (or the answer is not satisfactory), the question becomes: what do I need to do to have a good answer to the previous question? And so on.

webtards• 11 years ago

I think the ability to use YAGNI scales with the experience and abilities of the developer and the team. I have walked into wonderful lean codebases where an experienced hand has kept featuritus down to a minimum, but I have also walked into codebases where multiple kitchen sinks were not only present and plumbed in, but a pile of new ones were ready and waiting by the side to join them, and it was a massive distraction.

eridius9• 11 years ago

Something this article largely ignores is that often you want to build the support for the presumptive feature now because the act of implementing it affects architectural decisions. It came close to this by saying

it does not apply to effort to make the software easier to modify

But there's a difference between making software easier to modify (where the same effort could be expended later to retrofit the software) versus making architectural decisions. Often times trying to implement something teaches you that your architecture isn't sufficient and you need to change it. If you can learn that while you're building the original architecture, then you've avoided a potential huge amount of work later trying to retrofit it.

To use the example from the article, what if supporting piracy risks reveals that the fundamental design used for representing pricing decisions isn't sufficient to model the piracy risks, and the whole thing needs to be reimplemented? If you can learn this while implementing the pricing in the first place, then you haven't lost any time reimplementing. But if you defer the piracy risks by 4 months, and then discover that your pricing model needs to be re-done, now you need to throw away your previous work and start over, and now your 2-month feature is going to take 3 or 4 months instead.

pimlottc• 11 years ago

But on the gripping hand, deferring an implementation often means you understand the problem better by the time you get to it, so that your actual implementation is better than the naïve version you would have written earlier.

eridius9• 11 years ago

Fair point. Making these decisions correctly is hard. I'm pretty sure this is one of the things that you slowly learn how to do with experience, that no amount of being smart or research can make up for.

saganus5• 11 years ago

As I get older, both as a person and as a dev, I have come to the same realization as you: that a lot of the time I end up building things that I don't need "right now", but which I have to at least plan at the architectural level, lest be it a nightmare later on.

And then it hit me.. THIS is one of the areas of software development where I don't think reading more articles, techniques "mantras" etc will help. Only more practice will help. It ends up boiling down to how much experience as a developer you have, making those particular decisions.

I.e. It's a craft, not a science.

So as you grow up as a developer you suddenly find that you start to have certain "intuition" as to why I should actually plan for something that I don't need, vs actually ignoring something (a real "yagni"), but you just can't explain it in terms of generalizations. You end up saying.. "well.. it just feels like I Should do this, because I have been burned in the past when I ignored this intuition"

And I don't think I'm alone in this train of thought.

nvarsj• 11 years ago

I can definitely relate. The problem is, developers being a stubborn lot, "because I feel like we should do this" is a hard argument to win :).

I try to tease out the exact reasons when I feel that way about something. It can be difficult though.

johnrob• 11 years ago

I believe what you describing is the ability to predict the future. Nobody can do it perfectly, but experience can increase your odds of being correct.

guscost• 11 years ago

It's a craft, not a science.

I feel exactly the same way. It turns out everything practical I do with software depends more on the "spider sense" part of it rather than some well-defined knowledge (which is easy to look up when needed, so maybe that has something to do with it). The spider sense is not something you can teach or memorize, and it takes a while to develop. Programming is exactly like a craft in that way.

But there is plenty of better understood theory and experiment out there which if anything is the science part. From the theory and experiment I've dabbled with it's very much a different thing.

And it has a lot to do with the existence of radically different schools of programming. There's a joke, the engineer is showing a laser pointer to the scientist. The scientist asks "why didn't you get an ultraviolet laser when those output far higher energies?" and the engineer says "it's for shining a dot on the wall."

lowbloodsugar17• 11 years ago

This sounds like the journey from "realization of the cost of hacking" to its "cure", the grand solution.

I had the same epiphany in my 14th year of software development when I realized that programmers Must Be Given Solid Platforms of Well Architected Object Oriented Code or they will Make A Mess.

However, now in my 34th year, my view is more "Plans are useless, but planning is indispensable".

I have "grand" architectures, but my architectures and their implementations are designed with the assumption that they will be wrong in a week's time.

And my advice to anyone reading this is YAGNI. More practice helps. But practice the right thing.

I.e. its war, not craft.

DanielBMarkham• 11 years ago

There's an interesting thing that happens when you teach software development: many times you're forced to use heuristics in order to get something of value in the student's head. The 90 or 95% solution that somebody understands and uses is much better than the 99% solution that nobody pays attention to. KISS.

I think everybody needs to build 2,3,4,5 or more systems that you over-design in order to feel the pain and learn that YAGNI makes a lot of sense. Yep, for any given project there might be a couple of YAGNI items that make sense, but good luck trying to get a team of seven to agree on them. Most of the time instead of agreeing, everybody gets their 2 or 3 added (or they add them on their own without asking anybody) and you're back to astronaut architecture land.

A similar thing happens in C++. I firmly believe that a coder needs a bunch of projects where they shoot themselves in the ass with C++ before they finally realize that every little bit of added genericity and redirection is a ticking time bomb of maintenance work later on. Eventually you realize that brutally maximizing simplicity is as important as actually solving the problem. Probably more so.

Interestingly enough, I see more of this in high-level OO languages than I do low-level or FP solutions. I think that's because "manage the complexity" is a key part of those worlds, where "click to make a class" is a key part of the other. (Just speculating)

nostrademons• 11 years ago

I don't think YAGNI ignores this so much as explicitly rejects it. I've participated in the type of rewrites you mention here. Yes, they suck. Yes, they happen far too often. But I've also observed that they seem to happen regardless of how much you plan ahead to future requirements: even if you are exhaustively brainstorming possible future directions and are absolutely sure you're going to want something, you're very often wrong. And the inevitable rewrite that happens is a lot more painful when you have to carryover requirements that you don't actually need.

YAGNI fundamentally is a statement about costs and benefits. And it's a statement about personal experiences of costs and benefits, with a counterintuitive conclusion. I've found, however, that the teams I've worked on that just accept that they'll have to rewrite or throw away 90% of what they write end up performing at a much higher level (in terms of their impact on the broader industry) than the teams who figure "But if we could just get that 90% down to 50%, we'll be 5x more effective than other teams!"

Another way to look at this is in terms of external vs. internal drivers of success. YAGNI makes sense when the primary drivers of success are external and you need to quickly react to changing market conditions or customer requirements. It doesn't when the primary drivers of success are internal and you need to quickly act to get from known point A to known point B as efficiently as possible. Some engineers are lucky (unlucky?) enough to work on the latter, but typically it only happens when you either have a monopoly or you're deep in the bowels of a corporation and only need to report up to an executive who never changes her mind.

To use the example from the article - if the biggest risk or change in the external environment you'll face is your software, go ahead and build the feature into it. But who knows? You may be able to close a round of venture funding in 2 months and then hire the Gondor navy to eliminate piracy. Or Gondor may enter into a trade agreement with Rohan and redoing all your contracts takes primacy. Or Aragorn may arrive with the Army of the Dead and suddenly piracy is not a problem anymore, but a lucrative business in life insurance may pick up.

eridius9• 11 years ago

I think there's a difference between going ahead and implementing piracy risk immediately, vs determining all the requirements of piracy risk and using them when designing your fundamental architecture, with hooks left in place for extensibility that simply aren't actually implemented yet. Maybe the Gondor navy will destroy the pirates, but then you have to worry about Corruption risk because you now may need to bribe the navy or risk having your cargo impounded (so you have to balance the risk of impounding vs the cost of bribing). Sure it's not the same thing as piracy risk, but it's similar, and because you designed your architecture from the get-go to enable piracy risk and other such extensions, you can now implement navy bribes pretty easily.

Meanwhile, if you'd said YAGNI to piracy risk and just implemented support for storm risk, you may find that you can't easily implement navy bribes without re-doing much of the work you already did for storm risk.

As saganus said[1], this is more of a craft than a science. You need to plan ahead with your architectural decisions, and they need to be made using the actual requirements you expect to encounter (as opposed to theoretical requirements, which aren't really much of a use to anyone), but that doesn't mean you need to actually implement everything immediately. Just enough to be satisfied that your architecture will suffice.

[1] https://news.ycombinator.com/item?id=9607881

fournm• 11 years ago

Related to this is the question of any data migrations as part of those architectural decisions.

Especially if the "right" model in the end isn't really compatible with the first, wrong one and you can't afford to mess up the data.

mkozlows7• 11 years ago

So the thing is, yes, this hypothetical thing will affect your architecture. That's true. But what's also true is that a) this other thing over here you're not aware of will ALSO affect your architecture; and b) the thing you're planning ahead for might never happen.

Which is to say the really obvious: The future is unknowable.

Some people react to this by saying "okay, let's make everything as general as possible then, so we can be prepared for an unknowable future" and architect up a forest of abstractions.

Some people (the YAGNI crowd) react to this by saying "okay, let's making everything as simple as possible, so it's easy to change in the future when we know things" and rigorously eschew unnecessary abstraction.

In my experience (which includes creating, maintaining, and managing a single large application for a decade), the YAGNI crowd has the right of it. Complexity is a cost, and you should only incur it if you absolutely, no-question need it.

eridius9• 11 years ago

As I stated in another comment[1], this is a false dichotomy. There is a large continuum of various ways you can make decisions in between the two extremes of "YAGNI!" and "be as general as possible". The correct solution almost always lies somewhere in the middle.

YAGNI is appropriate if you think there's a very good chance that you won't need to do anything in the future, or if the future is so ill-defined that you can't make any sort of reasonable prediction of what you might need. If you're writing something that will be deployed once and never updated again, well, YAGNI is fine. But in most cases you're writing something that will need to be maintained and have more features added over time, and in that case, you have a variety of architectural decisions to make that influence what sort of changes can be easily made in the future. Determining which decisions to make in which ways is a hard problem, and it's something you basically just have to develop an intuition for by working on a lot of projects over years.

[1] https://news.ycombinator.com/item?id=9608099

lowbloodsugar17• 11 years ago

1. My team will not have to throw away our previous work. It works for storm pricing. It is deployed. Customers are using it and we are making money.

Your company has yet to deploy a storm pricing model because it got caught in the complexity of the piracy model.

2. When it comes time to write the piracy pricing system, my team has already gained a huge amount of relevant experience from writing the storm pricing system. In my experience a team that already has developed a simpler system will be better able to develop the more complex system.

3. If piracy pricing is a significant risk then it should be prioritized higher. If it is late because you thought it would take two months and it took you four, then you failed to assess risk. A really good way to assess risk is to implement something similar (may I suggest storm pricing).

However, in my experience, even if we know we want to ship storm and then piracy immediately after, I will still ask my team to develop storm first to completion. And I will stand any one of my teams up against a team that is going to "do it all in one go", and we'll get them both done before the other team.

4. Basically when you make an argument that is "Suppose you have this situation...", then it is equivalent to saying "This thing happened in the past, and if we had known then what we know now...."

They are equivalent because now matter how your frame your "thought experiment", it is guaranteed to never happen in real life. The whole point of YAGNI is that you cannot know the future, and no one ever has. The only way to know for sure that "this is how its going to turn out" is to actually be in the future.

So, yes, if you had a time machine, you could argue that big upfront design would work.

Of course, if you were to start your argument with "Suppose I had a time machine and I could go back in time and tell my team that the piracy model is a perfect superset of the storm model, but is twice as complex because of x, y and z, but there are no other unknowns, and customers love it, and the Navy doesn't kill the pirates, and so therefore we should do it all in one go" then it would be much more obvious that your argument was flawed.

eridius9• 11 years ago

You're still making some pretty strange assumptions here. An imperfect prediction of the future does not render the prediction meaningless, and making architectural decisions to support expectations of the future does not necessarily mean a significant increase in complexity, it often merely means some upfront "critical thinking" time. In fact, this upfront time may very well speed up the rest of the implementation, even if the predicted future requirements never come to pass, because it produces a more well-thought-out and well-understood architecture, that may be cleaner and more powerful without making the actual implementation any harder.

But again, there is a large continuum of possible approaches here, and insisting on reducing it all down to either "do everything" or "YAGNI" is really kind of bewildering.

fr0styMatt2• 11 years ago

This still seems to suggest some up-front design though. How do you know that the piracy pricing is going to be a significant risk (as pointed out in 3) unless you think through some of its' design?

Why wouldn't the engineers then go into developing the Storm feature with this knowledge, so that they avoid making any decisions that might cause significant rework when it comes time to implement piracy?

I can't see how they could assess the risk of the piracy feature without having thought it through and then choose not to take any of that thought into account when implementing the storm pricing feature.

saganus5• 11 years ago

" The only way to know for sure that "this is how its going to turn out" is to actually be in the future."

But then what kind of "time resolution" do you use for "in the future"?

I mean, of course if you talk about weeks ahead, then yes, why should I plan for something that I may or may not need need in 4 weeks?

What is the cutoff then? Next week? Tomorrow? In an hour? 10 minutes?

After 34 years of experience, you have fine-tuned this. But there IS a line, right? Maybe not fixed, but there should be one, otherwise you won't do anything unless it's needed like right this nanosecond.

Reductio ad absurdum of course, but I'm curious how do you know where to draw the line?.

unclebucknasty11• 11 years ago

* If you can learn this while implementing the pricing in the first place, then you haven't lost any time reimplementing.*

But, isn't this the same kind of thinking that necessitated a precept like Yagni?

I wonder if the very notion that we are "architecting" vs. simply building software to solve a clear and present problem is at the heart of the tendency to overengineer.

pacala• 11 years ago

I have found the opposite. Building things you don't need yet it's just increasing the mass of code that needs to change when the real requirements hit. It pays off to build software as simple as possible, and modify / generalize later, as opposed to designing an up-front "architecture" that is bound to become obsolete and a hindrance in 6 months.

olavk• 11 years ago

If you know that you are going to need piracy risk support, then of course it makes sense to prepare the architecture for it, even if you only have to deliver the feature four months down the line. But YAGNI does not apply if you know a feature is needed. If you don't know but are just guessing about possible future development there are a million things in various directions you could also prepare for, and all preparations have a cost.

lmm9• 11 years ago

Every "architectural decision" I've ever seen has been wrong. It's always resulted in a worse product than simply writing the code and allowing the architecture to happen.

(This doesn't mean writing code with no layering, just deferring those decisions to the point where you actually have the code that makes use of them)

jmadsen2• 11 years ago

I think it is important to differentiate between "early building" of features you don't yet need, and building in a way that doesn't require much refactoring in order to extend/add those features on.

More common than overbuilding features is overbuilding function or library capability. The right balance, IMHO, is _thinking_ about the extendability & designing for it but leaving out the actual details. This tends to lead toward good, SOLID designs that are easy to work with later rather than a blind-ally you need to spaghetti-mofongorate to get to work.

"Refactor later" is fine for folks like Martin Fowler who know _how_, and who haven't painted themselves into a corner with bad early decisions. It is a bit dodgy to tell the average mid-level dev who just wants to "get it done" so his Project Manager can check off their Excel spreadsheet that they are on time.

moron4hire2• 11 years ago

Extensibility is itself a feature, so YAGNI would imply it shouldn't be assumed until proven necessary.

I personally use the "zero, one, many" rule (i.e. those are the only counts of things, there is no such thing as 2 or 3, etc.) as my proof of necessity. If I ever get to the point that I need two of something, I make it useful for many of something.

beat4• 11 years ago

I've found that designing for extensibility is wrong more often than right. The code doesn't stretch the way you expect, and then it strains against other boundaries you didn't realize you were setting.

gav• 11 years ago

There's a lot of times where you know that something needs to be extensible, but you only know the immediate requirement.

From Martin's example, the team needs to support storm risk, and think they need piracy risk in the future. I'd suggest that they are 100% sure they need to support multiple risk calculations, they just only have the requirements for the first type now.

It's at this point you have several options, but by choosing something that is a bit more generic than the base case but without being an over-architected mess will save you a lot of time in the future.

chipsy• 11 years ago

The only thing I design to extend is the data. That is, I get suspicious now when I take an existing method and try to parametrize it, because what I'm doing if I do that is building up a richer all-purpose code edifice - and that is a Bad Idea when we know that code is disposable and data isn't. By default, all programmers start by planning and testing code towards one use-case, and then they add the other cases one by one. Code that is arbitrarily made "generic" or "extensible" imposes a testing regime that programmers do not arrive at within the natural edit-test-debug cycle, but instead have to consider separately.

With data this isn't really the case. Achieving both YAGNI and DRY at the same time is _easy_ with data. Data tends to become more generic and more fungible as it becomes more crude and simplistic, and less so as a defined schema builds up - for example, a Point class with "x" and "y" fields, vs. a numeric array of 2 or more entries. With the former, you can end up with your Point not being the same type as someone else's completely equivalent Point. With the latter, agreement mostly rests on which kind of numeric type you're using(which can be enforced by the language), and the ability to operate on many points as well as just one point is straightforward to support yet not strictly required. And so if the goal is reuse, you design downwards; if it's type safety, you design upwards. Achievement of both imposes an enormous code burden as you try to enumerate all the types and provide various translation layers and fallbacks - in turn creating more code paths, more situations where you can throw an exception or return a null value, etc. That can add up to a lot of lines of code, and a performance tax, and more failure modes, in exchange for sometimes eliminating some runtime errors.

I think we naturally tend towards overdefining our data, though, because it looks more "correct" to tightly define each block of code so that it says "point.x" instead of something like "x = point[index * 2]".

chris_va4• 11 years ago

I think this is trying to simplify an already simple idea, succinctly: "Optimize your time intelligently".

Rules of thumb (like YAGNI) may not be correct, depending on the situation. Estimating time complexity is hard, so deferring development defers mistakes in estimation. Great.

However, if you know that you have a 90% chance of needing a feature in 6 months, and it will be 2x easier to build now when you have a team actively engaged on a similar project, then YAGNI is the wrong choice. Counter examples exist, like you are in such an extreme environment where (like first month of a startup) the opportunity cost of those programmers is very high.

Regardless, I would ask "Is this the best use of time now" rather than "YAGNI".

pbreit9• 11 years ago

The whole point of the article is that you're wrong. And I tend to agree. Not trying to predict feature needs down the road is extremely empowering. Building you're unnecessary feature now is just as likely to increase the complexity of everything in the future as it is to be 2x easier to build now. YAGNI dramatically simplifies the answering of your question: if it's not needed now, don't do it.

chris_va4• 11 years ago

Using your example: Let's say I know it will cause a complexity burden in the future. Shouldn't we ask if that complexity burden and opportunity cost are outweighed by the expected benefits, rather than rather than simply relying on a simplistic rule of thumb of always deferring?

People are capable of (which, to your point is not the same as being consistently good at) making good calculations as to what is a waste of time.

jonahx4• 11 years ago

Making decisions by flipping a coin also simplifies them dramatically -- it doesn't mean it's optimal.

I think your reply captures both the appeal and the danger of YAGNI well. While I think it's often a good heuristic in practice, it is just a heuristic and it can be badly abused in cases where future needs can be accurately predicted today. Saying "But can they really ever be predicted?" is a cop out imo, because in some cases the answer is yes.

sbov• 11 years ago

It's still not that straightforward.

What if features X, Y, and Z needed in < 6 months each are 2x harder to code because of the planning of feature B that has a 90% chance of being needed after them? You potentially "saved" time by doing feature B but depending upon the total time to code feature X, Y, and Z, 10% of the extra difficulty in features X Y and Z may still outstrip 90% of the time saved in feature B.

Nevermind that as feature B goes unused for 6 months bugs and incompatibilities may creep in. Eventually what you wrote for feature B may be mostly useless when you finally get around to actually needing it. I have had this happen on projects before.

chris_va4• 11 years ago

I agree. Projects should not be scheduled in isolation. Delay may be a great idea, or a terrible idea. Sometimes prediction is easy, sometimes it is not. Trying to oversimplify the decision making is a mistake.

jonahx4• 11 years ago

These days, I think "Yagni" is often used as an excuse for sloppy code and as a justification to avoid thinking about design.

I think the principle as Fowler describes it is valuable, but it can be easily abused. Taking the application of "Yagni" at the microlevel to its logical conclusion can be used to justify a mindless, just move on it and fix it later style of coding into which good architecture cannot be retrofit.

esfandia• 11 years ago

YAY (Yagni Ain't Yolo)?

lmm9• 11 years ago

I have yet to see up-front "architecture" add value, and I have seen it sink a company.

robmcm5• 11 years ago

Working on software with 10s of developers it is vital.

jonahx4• 11 years ago

Hi lmm, perhaps the world "architecture" has bad associations for you that I don't intend to imply. If you code anything non-trivial, you are doing architecture whether you like it or not. The only question is how well you do it.

Over-engineering is a real danger, to be sure, and terrible ideas can by justified in the name of "architecture," just as they can in the name of YAGNI.

Fwiw, I have personally seen costly decisions made in the name of YAGNI, literally. So I don't think it is the essentially "safer" default.

My view is that you can't always wish away complexity with heuristics. Often, you have to think through your special situation, weigh the factors, and make tough judgment calls without knowing if they'll be right.

robmcm5• 11 years ago

Unfortunatly most "buzz words" can be used to avoid doing work, this seems to be the selling point of Agile in a lot of places I have worked.

I think what the pro and anti YAGNI groups can agree on is that maluable code is better.

pbreit9• 11 years ago

I love how these types of articles always bring out the architecture astronauts with all their pronouncements of "it depends" and whatnot. How hard is it to understand the notion of "building what you need, and not what you don't"?

asgard10242• 11 years ago

How hard is it to understand the notion of "building what you need, and not what you don't"?

Very hard, because it's in fact a tradeoff. Let's say you are building a house. Will you have wife and kids in the future? YAGNI says you can always expand your house once you have kids. But do people really build houses that way?

To take more extreme example, first thing you expect from housing is a protection from elements. So according to YAGNI, you should build the roof first, and see if it's good enough for you (and you don't bother, for instance, that you can only stand in the middle of the room). Again, no one really does that with real houses.

The whole art of engineering is to pick the reasonable tradeoffs, and this includes hedging against the risk of future expansion. That's why simple pronouncements as YAGNI are not of much help.

lmm9• 11 years ago

To take more extreme example, first thing you expect from housing is a protection from elements. So according to YAGNI, you should build the roof first, and see if it's good enough for you (and you don't bother, for instance, that you can only stand in the middle of the room). Again, no one really does that with real houses.

Maybe they should. I once stayed in a house with no internal walls. It seemed weird at first, but then I realized I actually quite liked it.

pbreit9• 11 years ago

Extreme examples are not that interesting (to me) since it's far more important to optimize what is not extreme.

A better house example is to go ahead and build the 2-4 BR house (like pretty much everyone does) but wait on the pool and jungle gym.

addisonj• 11 years ago

These comments seem to illustrate something I have felt for a while: yagni is incredibly divisive topic and for every person saying praising it is another who is at the very least cautious of its application.

It makes me wonder where the divide is.

Perhaps more large 'enterprise' shops where projects can spin out of control into what they 'must have' whereas the small shops where you need to get a product out ASAP?

Or maybe age of developer, with the young eager guy confident he can whip out all n features in 3 weeks so we might as well add that feature too vs the experienced dev who knows better and we will add it once it is needed?

I have put some time and effort into asking people about this very question, but still am no closer to understanding why some really appreciate it and others hate the phrase.

Personally, my guiding principle after being bit by yagni is that it is a wonderful principle to use when making product/feature decisions but should be exercised very carefully when making architecture decisions. Which makes sense, features come on and go, but architecture is generally something you need to live with. In other words, whenever yagni is used is an argument against what are more good coding and design practices than practical problems, then it may be something more of a case of 'no really, we are going to need it'

TillE• 11 years ago

It makes me wonder where the divide is.

I think it works beautifully if you're applying it along with "refactor mercilessly", backed by good unit tests. It's a principle that doesn't necessarily stand on its own; it needs to be part of a healthy, iterative system of development.

If refactoring becomes difficult or dangerous for whatever reason (eg, designing an API for long-term, widespread usage), then YAGNI may not work.

mtVessel• 11 years ago

Funny, I think of the age divide running the other way. Younger devs, who came up during the age of agile, take YAGNI as a given, while older devs have seen the results of too many hasty decisions.

The advice I was given when I started out was, "it's cheaper to fix something upstream". Catching a potential problem during design is always cheaper than catching it during development, which is cheaper again than catching it after release.

This argument always seems to get lost in the YAGNI discussion.

spookylukey• 11 years ago

YAGNI only makes sense in the context of other extreme programming[1] practices, such as making code safe to modify through unit tests[2] and easy to modify because you refactored mercilessly[3] to produce a nice, modular design.

I suspect the divide in reactions to YAGNI comes between people who have embraced those practices and those who haven't (and probably don't even know what they would look like, and can't imagine an environment that uses them).

In the context of a project where making changes is hard and dangerous, and where you have few automated tests, you will be tempted to change a lot at once, so that you can then manually check everything works once, rather than having to do that multiple times. And that might well be the better strategy.

Consider the question "What if we need extra fields in our 'product' table?". The Extreme Programming answer is both 'embrace change' and YAGNI. That means 1) we absolutely definitely require some general mechanism to be able to add columns to tables in the future, so we must have that in place, and not assume the product table schema is fixed forever 2) we have no idea what columns or how many columns will be needed in the future, so we don't add any now speculatively.

But many people work in environments where adding a column to a table would be a massively expensive task (thousands of stored procedures that need rewriting etc.). In this context, the 'YAGNI' response which just refuses to think about future does sound stupid, because it is.

[1] http://c2.com/cgi/wiki?ExtremeProgramming [2] http://c2.com/cgi/wiki?UnitTest [3] http://c2.com/cgi/wiki?RefactorMercilessly

rsp1984• 11 years ago

In my years of experience (both in big corporate R&D as well as startups) I've never seen a project fail because of the end product being too simple or not having enough features.

However on the other hand I've seen countless projects suffering delays, staff departures, emotional team arguments and eventually bad end product because of too complicated software architecture that overwhelmed its creators and because of obscure features that well-meaning engineers built in because "it'll save time in the long run".

Btw this well known XKCD sums it up just perfectly: http://xkcd.com/974/

krupan5• 11 years ago

I dealt with this recently. We wrote a system that had a hard-coded data size in it. Later, that data size had to change to a flexible value chosen on the fly, and I was the one that had to go through all the code to make all the changes so we could handle that. It took a long time. Partly because we had no unit tests (a whole 'nother discussion), partly because I wasn't familiar with the area (all the areas) of the code that needed to change, and partly because we had said, "YAGNI" and not made our code configurable enough from the get go.

I started to curse YAGNI in the middle of that chore, but then I paused and thought about the many months of productive use of this code that we had been enjoying before this point. And even though it took me significant time to make that change, the production code was still running along just fine during all that time, still bringing us value. I decided that I was glad we had said, "YAGNI" at the start.

mbell• 11 years ago

Partly because we had no unit tests (a whole 'nother discussion)

I think that the is the primary point. If you have good test coverage at each level, it's actually really easy to make large sweeping changes to a codebase. If you don't have those tests, it's hell. This is a big part of why I think unit tests are ok, but not nearly as important as good E2E and perf tests, as painful as they can be to write and wait for to run some times. Good high level tests let you tear the heart out of the codebase, replace it and still be confident it works.

shoo• 11 years ago

I agree that having good test coverage across different levels/purposes makes sweeping changes far quicker, easier, and even feasible to consider doing.

Building and shipping the software is perhaps half the work - another half of the work is growing and maintaining the scaffolding to rapidly, automatically and reliably measure the properties of the software that you wish it to have.

It seems no-one here is arguing that YAGNI should be applied to justify not building automated tests.

krupan5• 11 years ago

The one thing we did have was good end-to-end tests. When they failed, it was the unit tests I was wishing for.

BurningFrog4• 11 years ago

It sounds like most of your pain came from the code not being DRY. That is, this data size constant was duplicated in many places, rather than defined in one central place.

Unless I'm misreading you, that's not an appropriate YAGNI case, as Fowler writes:

"Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify"

unclebucknasty11• 11 years ago

It sounds like most of your pain came from the code not being DRY.

Exactly this. Yagni does not preclude following generally good design principles, which almost always saves future pain; unlike attempting to predict and design for the future.

Silhouette22• 11 years ago

"Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify"

That's a very convenient distinction. It lets you No True Scotsman anyone who challenges your position, yet provides little if any practical guidance about the best thing to do in the real world.

krupan5• 11 years ago

You missed the point that I probably made too subtly, that it went from being a set size to a variable size. Yes, we did have some terrible non-DRY code and it would have been a little easier to make the change if not for that. But going from same size all the time to different size every time was never going to be as easy as changing the value of a constant.

mwsherman• 11 years ago

Yes! And in this case, you “cursed” yourself for not making the prediction that this change would be necessary. One discounts the 100 other wrong predictions that would have accompanied this right one.

jkaptur• 11 years ago

The incredibly interesting thing about this example is that it sounds like the design actually had to change in two ways: 1) the value had to be configurable and 2) it had to be configurable on the fly.

Anticipating and designing for (1) is simple enough - the costs that the article refers to are quite low - but to think ahead and design for (2) is a completely different task that might radically complect the code.

krupan5• 11 years ago

You caught the subtlety that I should have emphasized more. Number 2 was the really difficult part. We had some hard-coded constants as others guessed, which also made this really hard, but just fixing that problem was wasn't enough.

JamisonM• 11 years ago

If making the size of a item of data different required a lot of effort to change your problem is one of a far more fundamental nature than YAGNI.

lowbloodsugar17• 11 years ago

I used to play Age of Empires. Its a real time strategy game where a common match is for two teams of three to try to kill each other. A feature of the game is that each player can spend resources (gold, wood, etc) to reach new "ages". Players start in the stone age, and advance to tool, bronze and iron ages. Each new age offers better weapons, better technology, greater efficiency.

Consider two games. In the first game, we observe that the players take on average 30 minutes to get to tool age, and only one player ever makes it to iron age before a team is victorious after about two hours.

In a second game, we observe that the players average ten minutes to bronze age and all but one player makes it to iron age before the game is won after about an hour. All players invest in technology before fighting.

Who are the better players?

pdpi• 11 years ago

I can only assume that the point you're trying to make is that there's not nearly enough information for a reasonable answer. It's certainly hard to come up with solid ideas without a clear understanding of the game's pacing.

In RTS games, teching and building armies compete for resources, so I'd hazard guessing that Game 1 happens because somebody opted for early aggression, which forces everybody to spend money on units to fight off the early threat. Looks like a well balanced game where both teams kept the aggression level high, which justifies the long duration, and the low-tech end-game.

Second game looks like there was little to no early-game aggression, which meant that everybody got to funnel resources into teching up early. I'm not sure if late-tech battles are more all-or-nothing, or whether one team was just clearly stronger than the other -- though if that's the case, why didn't they push for an advantage earlier? AoE is much more symmetrical than, say, Starcraft IIRC, so one team having a weaker early game but a stronger late game doesn't seem likely.

I'm curious, though: how does this relate to the article?

lowbloodsugar17• 11 years ago

Thank you for biting =)

The players in the first game are likely experts and if a team from the first game plays against a team from the second, the game will be over in less than ten minutes. Its not merely that "someone opted for early aggression", its that when playing at the elite level all players opt for aggression. Its not rock, paper, scissors. Its a game of rock, paper.

The point is that deployed features trump undeployed "it'll be great when its ready" technology.

I'm happy for my competitors to opt for spending money attempting to achieve "good architecture" over "working code".

Ok, so the analogy is kind of shitty. Unlike Age of Empires, spending money on "good architecture" is actually less effective at creating good architecture than writing working code.

lowbloodsugar17• 11 years ago

Another point is that to the beginner, the second game looks like the better players. The experts would identify the first.

The skill necessary to recognize the better strategy is the same skill required to implement the better strategy. The beginner lacks this skill.

regularfry• 11 years ago

The best* players are the ones who gank their opponents in 10 minutes using clubs and pointy sticks.

*For certain values of "best"

robmcm5• 11 years ago

It depends on the market conditions. If you are the only player you should spend your time investing so when the competition comes out with pointy sticks they can't get through your electrified Graphene perimiter.

If you don't then there is a risk you get iPhoned, Facebooked, Googled etc.

bsder4• 11 years ago

Except that Fowler used YAGNI to produce the "Chrysler Comprehensive Compensation System" that FAILED MISERABLY. I still don't understand why people continue to listen to him--he has yet to demonstrate a large project he was in charge of that succeeded.

YAGNI gets you the easy 80%. The problem is that YAGNI means you didn't prepare for the hard 20%, and now you're going to get killed.

Of course, YAGNI is really good if you're an ambitious manager since you'll be gone when the 20% comes home to roost.

necrodawg2• 11 years ago

Such failures are more often because of bad developers than anything else. It's not really fair to blame a single person on a big project with lots of people on it.

bsder4• 11 years ago

Except that he is preaching the exact opposite.

He is preaching "Follow my religion and your project will succeed! Pay me money to teach you."

Given that, it is entirely fair to blame him and his system for the failure.

Just so you know: I do agree with you that big projects rarely fail because of a single person. But Fowler pisses me off because he preaches his religion with zero empirical evidence it is any better than anything else.

lmm9• 11 years ago

Most C3-like projects fail after a decade and millions of wasted dollars. Failing faster and cheaper provides real value.

bsder4• 11 years ago

Except that there was already a working system. So, the C3 system was totally wasted money, and never achieved any significant subset of functionality of the old system.

A "proper" use of agile would have been to gradually convert chunks of the legacy system to a unit-tested system. Use bug reports and feature requests to prioritize the chunks which need to be tested. Once that happened, you could begin evolving the old system and adding features without worrying about breaking it.

But that wouldn't get noticed. Much better to have a BIG, NOTICEABLE failure that you blame others for than a less noticed success. That's how you get promoted, don'tcha know.

See: https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successfu...

anigbrowl• 11 years ago

There's an extensive literature on opportunity costs in economics, but you wouldn't know it from reading this article, even though that's basically what it's about. Discussions of programming methodology often seem to involve reinvention of the wheel. Has there been any work done to quantify these theories?

phamilton• 11 years ago

I'm always a bit surprised when we treat "cost" as something binary.

Successful people, in my experience, are those who take calculated risks and are right often enough to differentiate themselves. Software is no different.

When faced with a YAGNI situation, you need to make a judgement call. There will be costs in building it now. Those costs might be less now vs later (sometimes just because the context is fresh). The cost may vary depending on how much work you do.

There will also be "expected benefits". The estimated (judgement call) likelihood of actually needing it times the cost savings (future cost - current cost). Compare the expected benefits between projects and pick the one you expect to add the most value.

As pointed out by others, this often means simply drawing the abstraction in the right spot to make future development easier. Even if future development never happens, it's likely you built a good abstraction that was well thought out. The cost is low (you had to frame the abstraction somewhere) and the expected benefits are high.

mc808• 11 years ago

Other than the navy wiping out all the pirates, I foresee a couple of other unforeseen scenarios:

1. Within the next few months, a new risk emerges with higher priority than piracy. Implementing this feature will delay the piracy addition, but only by 1 month because much of the basic "support multiple risks" problem will be solved by this other feature.

2. Within the next few months, a new product or tool will become available/known that makes it trivial to support storms, piracy, and a dozen other risks, making this whole effort redundant. It may be impossible to migrate to the superior alternative if all the resources are already tied up in a half-finished project that has generated no benefits to date.

robmcm5• 11 years ago

The use case in these discussions is never about framework or shared code.

Taking the example of the lookup tables for error messages, imagine if you shipped your framework and lots of teams started using it, then you iterate to change your APIs in a breaking way and suddenly the cost of that change is multiplied by all the teams refactoring.

It is also worth considering the cost of changing existing production code, this is typically where most bugs are introduced, especially when someone else is implementing the fix without the domain knowledge of the original author. Unit tests won't help if they also have to be re-written to match the new API, as they are by definition new/different tests.

I think writing malleable code is the key takeaway from this article, and if thinking about future possibilities helps with this, then it should be encouraged.

Being unable to predict the future doesn't mean you shouldn't anticipate and prepare for change.

Yagni

Related Stories