Yagni (2015) • Hacker News Board

Re: Yagni (2015)

#31

Post by stcredzero » Sun, Aug 12, 2018, 8:35 PM UTC

Silhouette wrote: post #19

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…

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…

Except for the part where you refactor your code, which by definition shouldn't be changing its behaviour and therefore can't be driven by adding tests to your test suite, where exactly the same design issues will immediately arise.

By comparison to Smalltalk, most environments seem broken to a seasoned Smalltalker. The main refactoring tool in Smalltalk would happily refactor your tests, so you'd just do your refactoring and re-run the tests. No interference with any reasonable implementation of TDD needed at all. You just counted refactoring as writing the tests and then immediately ran the unit tests.

Re: Yagni (2015)

#32

Post by xapata » Sun, Aug 12, 2018, 8:51 PM UTC

Silhouette wrote: post #19

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…

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…

In my experience, a great deal of software development, or indeed much human activity in general is wasted on things no one wants.

Re: Yagni (2015)

#33

Post by jstimpfle » Sun, Aug 12, 2018, 9:24 PM UTC

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…

Generalizations are always wrong?

Re: Yagni (2015)

#34

Post by Silhouette » Sun, Aug 12, 2018, 9:51 PM UTC

combatentropy wrote: post #25

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…

> 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 features, so we're only talking about "capabilities built into the software to support a presumptive feature", and if we then further exclude things that "make the software easier to modify", then how much development is really left for YAGNI to affect?

I can't speak for anyone else, but when I write new code, it is generally either implementing some specific functionality that we want right now or improving the common foundations of the system in some way. The usual reasons for the latter would be either gaining some immediate benefit, such as improved performance or robustness, or making the code easier to modify so we can then gain some benefit. By Fowler's argument, I don't see much of a middle ground where YAGNI would mean anything, unless maybe a developer is in the habit of starting to develop code for some specific feature when there isn't actually any requirement for it yet, but why would anyone do that anyway?

Re: Yagni (2015)

#35

Post by Silhouette » Sun, Aug 12, 2018, 10:00 PM UTC

stcredzero wrote: post #31

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…

Except for the part where you refactor your code, which by definition shouldn't be changing its behaviour and therefore can't be driven by adding tests to your test suite, where exactly the same design issues will immediately arise. By comparison to Smalltalk, most environments seem broken to a seasoned Smalltalker. The main refactoring tool in Smalltalk would happily refactor your tests, so you'd just do your refact…

Perhaps my analogy wasn't clear. I wasn't really commenting on refactoring. I was arguing against the common claim that you don't need to do much design work if you're using TDD. In reality, most of the same work does still happen, it's just being brushed under the carpet to make the process look simpler and more efficient than it actually is.

Re: Yagni (2015)

#36

Post by keithnz » Sun, Aug 12, 2018, 10:33 PM UTC

YAGNI is very useful. But :-

It's mostly useful in a situation where problems that YAGNI was trying to help with are happening. Namely, when people are trying to ask for anything that is possibly needed upfront because if you change your mind later it will cost a lot more to get it. For developers it was to try and get them to think vertically through software rather than horizontally and to stop designing large layers of goop instead of focusing on working software which you build out incrementally which means a HUGE focus on composable modular software.

It's also not a justification by itself. Lisa: "Lets do X" Bart: "YAGNI"

There needs to be a bunch of thought about things and YAGNIs purpose is really to just challenge what it is that is going to get built.

Most of the criticism of YAGNI is mostly YAGNIing something that was actually needed, or using YAGNI to compromise a software design. But that's not a fault of YAGNI, that's either because you let YAGNI hold too much power over your decision making because you felt its pressure to stop you doing something, or you just weren't capable at decision making time to work out what you really needed. YAGNI is just a focusing tool to work out what you are going to need and it's as strong or as weak as the people making the decisions.

Re: Yagni (2015)

#37

Post by mmt » Sun, Aug 12, 2018, 10:53 PM UTC

derefr wrote: post #9

bastawhiz wrote: post #3

The problem I've seen when yagni is applied is not building something now leads to a costly data migration down the road when you actually do need it. I run a site that stores audio files. For the first half of its life, it simply stored the URL of the file on S3. I could have used objects representing audio assets with metadata to store the reference, but I didn't think I'd need it. When I was building another featu…

To be clear, did your debugging problem come down to the fact that the metadata for the objects was on "the other side of" the S3 URL, being held as object metadata headers in S3 that you would need to do a HEAD request to retrieve per object, rather than as e.g. columns in a local RDBMS—such that you couldn't do aggregate queries on it to figure out what a customer's files "looked like" in a statistical sense? If so…

> or at least, they trust their knowledge of infrastructure solutions better than their coding abilities

Or we trust our knowledge of such solutions more than even your (anyone's) coding abilities :)

I realize, of course, that you're using "trust" as a metaphor for expertise, as well as that we all have a tendency to be biased in favor of solutions that favor that expertise/familiarity.

The trouble is, programmers outnumber ops people by a vast, vast margin, especially here on HN.

> often, an ops person can take your developed software as a black box, and solve its scaling problems without touching the box.

Not often enough, not any more. It seems that this skillset has been sufficiently devalued in the industry that, however rare it was originally, it hasn't spread, which means there may well be a significant plurality of coders out there who have never worked with such an ops person.

> And this is often the optimal way to solve these problems: you probably can't write a caching layer for your web app, inside your web-app's process, that will work half as well as Memcached

This goes back to my original, partly facetious, comment about trusting anyone's coding. My real point is that I don't need any kind of faith in something like memcache, since I've seen it work many times before, whereas someone's coding ability (even my own) does require a leap of faith, since it's totally unknown how effective the effort will be or on what time scale.

> And, since these scaling problems can be solved without ever touching your code, it's especially silly to try to anticipate scaling problems you might have and solve them in your code

That's a message that's difficult to hear for management that's made up entirely of programmers (such as at many software startups, even grown to a larger size). Witness the willingness to pay huge premiums for cloud ("infrastructure as code"!) solutions, that eliminates huge low-level scaling opportunities.

Re: Yagni (2015)

#38

Post by combatentropy » Sun, Aug 12, 2018, 11:31 PM UTC

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…

Fear. I worked with a programmer that did it a lot. What if the customer wants this, or what if the customer wants that? And his reason was just what the article highlights: "I programmed it now so I won't have to program it later." It doesn't make sense unless you are trying to get a program done for good and hope never to have to work on it again afterward.

Re: Yagni (2015)

#39

Post by postfacto » Mon, Aug 13, 2018, 12:40 AM UTC

It’s been my experience that most programmers who have worked on many different projects across many different employers for many years can intuit whether something will be needed with a very high degree of accuracy.

Re: Yagni (2015)

#40

Post by Silhouette » Mon, Aug 13, 2018, 1:02 AM UTC

combatentropy wrote: post #38

Silhouette wrote: post #34

Earlier quoted context omitted.

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…

Fear. I worked with a programmer that did it a lot. What if the customer wants this, or what if the customer wants that? And his reason was just what the article highlights: "I programmed it now so I won't have to program it later." It doesn't make sense unless you are trying to get a program done for good and hope never to have to work on it again afterward.

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 before there's sufficient expectation that the extra flexibility will justify the implementation cost. I'm not sure I've ever seen it used (or needed) in the context of someone just randomly adding arbitrary functionality because they felt like it, and it had never previously occurred to me that someone might restrict the term to only that scenario as Fowler seems to be doing in the quoted comment.