Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yagni (2015)

martinfowler.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Yagni (2015)

#51

Post by InclinedPlane »

YAGNI is no excuse to design shitty systems, however. Make your systems as modular and componentized as is sensible. It'll pay off immediately as well as down the road when you inevitably need to make modifications. However, it is wise to avoid adding in too many features that you merely think are a good idea but don't actually have proof are useful in practice.

One thing to be aware of is that YAGNI can often be the cry of someone who doesn't want to admit they are accumulating mountains of technical debt. And it's very possible to go effectively "technically bankrupt". Rewrites are expensive and take a long time, in order to do them properly it usually requires launching projects in parallel so that the rewrite can get done while the old stuff is still keeping the lights on, and so that the rewrite can attain the same level of operational maturity. You see this even at multi-billion dollar companies, changing architectures is a difficult process. But what happens if you are stuck with a mess of bad code and a business that is only sufficiently profitable to continue supporting the old code but couldn't afford doing a parallel rewrite? Well, then you could very easily find your company stuck riding that bad code forever. Given the dynamic nature of tech businesses, being unable to respond to market changes because you are mired in technical debt is a huge competitive disadvantage and likely to lead to a much shorter lifespan for your company.

So be careful making too many short-term decisions. YAGNIs add up and up and up, you don't want to get to a point where when you do "need it" it's now effectively impossible (due to requiring an exorbitant budget to implement it).

Re: Yagni (2015)

#52

Post by wsy »

ternaryoperator wrote: post #43
wsy wrote: post #27

Earlier quoted context omitted.

Do you have some pointers to important papers of this field of study?

[1] Article from Dr. Dobb's gives a very high-level overview of the kind of data that is available. [2] is one of the foundational books in this area. Its analysis of testing effectiveness is fascinating because it's so revealing. For example, comparing defect rates in projects that use TDD vs. non-TDD; the effectiveness of static analysis; etc. [1] http://www.drdobbs.com/225701139 [2] https://www.amazon.com/dp/01325…

Thanks a lot!

Re: Yagni (2015)

#53

Post by Silhouette »

combatentropy wrote: post #47
Silhouette wrote: post #40

Earlier quoted context omitted.

I'm still struggling to understand how that happens. You've got a professional programmer who's just randomly writing code for imaginary requirements they made up? I mean sure, obviously that's bad practice and unnecessary, but who does that, and why do their managers and technical leaders allow it? I've always taken YAGNI to be a cautionary principle about over-engineering and over-generalising software designs befo…

The features aren't random. They're usually related to other features. They might be variations on a feature. For example, what if the user doesn't like the apps fonts and colors? Let's let them customize the look and feel to whatever they want. Or we've made this app that let's you send text messages to people, but what if it needs to be sent to an international number? Suppose this feature is right now unnecessary…

Fair enough. If you've seen examples of that sort of thing actually happening in practice, I defer to your experience, and we can certainly agree that they are unnecessary and effort shouldn't be spent on them!

Re: Yagni (2015)

#54

Post by curuinor »

ternaryoperator wrote: post #44
curuinor wrote: post #42

Earlier quoted context omitted.

Those from that field have also often failed in order-of-magnitude ways.

> often failed in order-of-magnitude ways so, there should be lots of examples, right? References?

these folks were the first to push CASE tools, which are a footnote in software history because they failed rather completely in actual production usage. they invented COCOMO, which never gets used for the easy reason of routine order-of-magnitude margins of error (60% in studies, 600% in practice...). they were the biggest pushers or UML and graphical programming, which dies and lives again and again in increasingly zombified states...

have a dealie about cocomo specifically, I suppose. http://shape-of-code.coding-guidelines.com/2016/05/19/cocomo...

Re: Yagni (2015)

#55

Post by hinkley »

nvarsj wrote: post #16

Like any generalization, it's not always true. Boss decides to add y,x,z options "just in case"? - YAGNI Engineer wants to get the datamodel correct up front to avoid costly rework and data migration in the future? - Not YAGNI Fowler fortunately states this distinction: "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…

The best phrase I've heard in this space is "Reversible decisions".

Any decisions that can be unmade later with relative ease, should be made as quickly as possible just to get them off the board (opportunity cost). If Do X vs Don't Do X is reversible, then YAGNI can apply - do whichever is cheaper and fix it later if you're wrong.

What pisses people off is when people try to block conversation on an irreversible decision by shouting YAGNI at you. There are a lot of adjectives for this behavior and none of them are good.

Reversible Decisions+YAGNI is pretty much your answer to the bikeshedding problem. Instead of wasting hours trying to decide what color to paint the shed, just budget painting it 5 times, and get back to figuring out if you can find a cheaper vendor to provide you millions of dollars worth of ultra high quality concrete. Or whether that crack the geologists found in the bedrock means you need a different site altogether.

Re: Yagni (2015)

#56

Post by hinkley »

plasticchris wrote: post #26
Silhouette wrote: post #19

Earlier quoted context omitted.

That's a bit of a cop-out, though. How much software development isn't either implementing the actual features or making the software easier to modify? This one is a bit like the TDD advocacy that says you shouldn't need to do much design work up-front because you can let the tests drive the design along with everything else.* *Except for the part where you refactor your code, which by definition shouldn't be changin…

I always thought tests were supposed to make refactoring easy since they ensure correctness. In practice I've only seen that a couple of times since the tests usually end up tightly coupled to the implementation.

It's easy for tests to pick up structural artifacts from the code, creating friction for making changes instead of reducing it.

At the end of the day it's a matter of the quality of the tests. Bad tests can be worse than none (because at least you know to be afraid).

Re: Yagni (2015)

#57

Post by hinkley »

Silhouette wrote: post #34
combatentropy wrote: post #25

Earlier quoted context omitted.

> How much software development isn't either implementing the actual features or making the software easier to modify? The key is the adjective, presumptive. YAGNI is about features that aren't needed now and it's uncertain whether they ever will be.

This seems awfully close to a No True Scotsman argument. The Fowler quote was, "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." If we exclude features we definitely do want from consideration, so we're only talking about presumptive features, and if we exclude actually implementing those presumptive featur…

I'm not satisfied by his criteria.

There's a particular design failure mode where an emphasis on 'easier to modify' results in a codebase that's difficult to follow. You're making some future code change easier at the cost of all current code changes.

You can infer a concern about overall cost of modification into his statement, and claim that such a person is increasing the cost of code modification, but it's dangerous to leave it unsaid.

Re: Yagni (2015)

#58

Post by paulddraper »

nvarsj wrote: post #16

Like any generalization, it's not always true. Boss decides to add y,x,z options "just in case"? - YAGNI Engineer wants to get the datamodel correct up front to avoid costly rework and data migration in the future? - Not YAGNI Fowler fortunately states this distinction: "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…

An essential distinction is the difficulty differential.

How much more expensive are options X, Y, and Z in the future compared to now?

How much more expensive is a correct data model in the future compared to now?

If it has a 50% chance of being needed in the next two years and will be 10% harder by then, YAGNI.

If it has a 50% chance of being needed in the next two years and will be 1000% harder by the then, do it now.

Re: Yagni (2015)

#59

Post by wsy »

wsy wrote: post #52
ternaryoperator wrote: post #43

Earlier quoted context omitted.

[1] Article from Dr. Dobb's gives a very high-level overview of the kind of data that is available. [2] is one of the foundational books in this area. Its analysis of testing effectiveness is fascinating because it's so revealing. For example, comparing defect rates in projects that use TDD vs. non-TDD; the effectiveness of static analysis; etc. [1] http://www.drdobbs.com/225701139 [2] https://www.amazon.com/dp/01325…

Thanks a lot!

After having read a bit, I'm a bit disappointed. While the intent goes in the direction I would like to see, the actual execution does not follow scientific principles. "Consultant collects some data, derives conclusions, and writes a book" is actually again only anecdotal. You need to think about your sample before collecting the data, otherwise your outcome is biased by who gave you a consulting gig.

Consequently, the work has never been published as peer-reviewed paper with experiment and/or real-world data, so that someone else could validate or reproduce results. Is that assessment correct, or did I overlook scientific papers?

Re: Yagni (2015)

#60

Post by andrewbinstock »

wsy wrote: post #59
wsy wrote: post #52

Earlier quoted context omitted.

Thanks a lot!

After having read a bit, I'm a bit disappointed. While the intent goes in the direction I would like to see, the actual execution does not follow scientific principles. "Consultant collects some data, derives conclusions, and writes a book" is actually again only anecdotal. You need to think about your sample before collecting the data, otherwise your outcome is biased by who gave you a consulting gig. Consequently,…

> the actual execution does not follow scientific principles.

It can't really. The practitioners are generally brought into a project under heavy non-disclosure and generally allowed to keep stats on the project as long as it is completely anonymized. This makes it hard to publish data in a scientific research mode, because it's hard to reproduce or validate independently.

Most of the time the practitioners are called in (hypothetical example) b/c a manager says, "I have the requirements for this project, I have 11 developers on the team, and we need to produce a working model of X by January, which is sufficiently defect free that we can put it in autos for initial test without losing a lot of cars." Thresholds are identified. Then the practitioner goes to his/her database of similar projects and says, "OK, when using these tools, we found you can get this level of defects on projects of x LOCs within the time frame you're going for. However, if you forgo Y, you can get higher levels in 10% less time. Etc." That can be valuable information, rather than just throwing developers at a project and hoping for the best.

The books that you dismiss as consultants just publishing their anecdotal info are often the product of hundreds of projects. Sure, the data is empirical, but it doesn't mean it's not rigorous. You'll note that the numbers in books and articles are often presented as ranges, which is due to the sensitivity of one factor to the presence of other factors (size of project being a particularly prominent factor).

Going to your original point, all established practitioners agree on the leading causes of defects. And this is where I fault most developers today--they plain don't know what those are. They'll guess, but they don't know. Which is what I think I hear you lamenting at the top of this thread.

Disclaimer: I'm not a specialist in this field nor a consultant, but I find its research interesting and have spoken to practitioners.

Post reply on HN