5 ms·

YAGNI is about avoiding premature optimisation. A lot of these make sense. But they always do. And the road to shipping hell is paved in good architectural pra

YAGNI is about avoiding premature optimisation. A lot of these make sense. But they always do. And the road to shipping hell is paved in good architectural practices. To ship a first version of a product, we always need to cut corners. Deep, horrible, painful, cuts. Because if we spent the time to make the perfect product, we'd launch too late. A lot of these YAGNI things are not "you're never going to need it", but just "can we ship the first version without it?".

scott_w 4y ago
If adding these things really slows your ability to ship the first version of your product, you need to fire your team and start with a new one. These PAGNIs are: 1. log.info() calls 2. apt-get install postgresql 3. Using timestamp and datetime.now() instead of boolean fields 4. Adding a /v1/ into your API endpoints I'm being serious. If your team says "this will add a week onto the release date" then your team is either very junior or bullshitting you.
- galangalalgol 4y ago
  If it is just API endpoints, but I can see some junior dev spending time putting version numbers on literally every data structure, taking the exception as a rule. And when logs go from "huh, if this happens I want to know about" type thoughts as you are coding to "lets make a full pass and see where I could have added some logs to this PR" then effort is being spent too far in advance. I definitely agree timestamps, two vs many, and don't reinvent the database (or don't assume your db is flat) are effort free and always worth it. With the caveat that you maybe can't afford the overhead of a full rel db, and have to use something like an ECS for performance reasons. This is pretty common for embedded or game domains.
  - scott_w 4y ago
    > I can see some junior dev spending time putting version numbers on literally every data structure That's a strawman argument. > And when logs go from "huh, if this happens I want to know about" type thoughts as you are coding to "lets make a full pass and see where I could have added some logs to this PR" then effort is being spent too far in advance. That's a strawman argument. > have to use something like an ECS for performance reasons. This is pretty common for embedded or game domains. If your domain requires something else, you probably already know it.
- marcus_holmes 4y ago
  Sure, but it escalates quickly. Logging goes from `log.Println("the thing happened")` to structured logging via an API very easily. Adding Postgres is a no-brainer. Totally agree. But should you architect the database properly? It's going to be tricky to normalise data later, maybe we should start with properly normalised tables now, instead of jamming everything into a jsonb field? Versioning, sure, but does every API need a version? If so, shouldn't we write some standard code for versioning all the things? Should the CICD process version the system automatically? Talking of which, we should set up the CICD. There's a rabbit hole. These things are all good, definitely worthwhile, but where do you draw the line? If we spend a couple of days doing X, then it becomes worthwhile spending a couple of days doing X+1, and so on. The author drew the line here. But that's not the only place you can draw the line. You can draw it a few paces back too. There's always a temptation as a techie to add a couple of days now to save a couple of weeks or months later. That may not be the right commercial decision.
  - scott_w 4y ago
    The detail you're going into are the YAGNI part. Yes, you'll get those eventually, but you deal with _those_ problems later. Log to a file right now and switch to DataDog, Papertrail, etc. later on. Add /v1/ now, worry about integrating CI/CD into that later, when breaking changes means you actually need to worry about using versioning. I'd think it's implied that you just normalise the tables. It's really not hard to build and use a normalised database. I was doing this in my first months as a junior developer, so I'd expect an engineer with any seniority to be able to do it. If you're asking: "should we model the domain perfectly?" then my answer is a simple "model the domain as you understand it _today_." YAGNI is not "write shitty code" but "don't add things you don't need right now." Again, if adding /v1/ into your first URL string or configuring your logging takes "a couple days" each, then I'm going to have serious concerns.
galangalalgol 4y ago
I agree that we have to be very vigilant against the what ifs, but with the exception of logging, which is the one I most disagree with (unless it is helping you debug a failed test), these all seem like cases where the future thinking thing takes precisely as much time as the ship-it-now thing. The versioning thing could get really out of hand too probably now that I think about it. But timestamps, many vs two, and the "uh this is starting to sound like a database, lets use one" are all effort neutral.
- hinkley 4y ago
  I irritate myself constantly by realizing that this bug fix I'm working on would have been easier if I'd written some better tests first. Or noticed the order of a couple of log messages sooner.
AnimalMuppet 4y ago
YAGNI is about much more than avoiding premature optimization. It's about avoiding premature work, of any kind. Optimization, sure, but also implementation and even design. I know that design sounds like the kind of work you don't want to avoid. But designing, say, a spiffy database query cache so that you don't hammer the database with repeated queries, before you know that you need such a thing? Don't bother designing it. YAGNI. (I mean, you might go so far as to think "If we need it, we'll put it here". But an actual, detailed, implementable design? No. It's likely to be never needed, and is therefore a waste of your time.)
- hinkley 4y ago
  > It's about avoiding premature work, of any kind. It's even worse than that. Features have complexity, and they introduce constraints. Without active effort to fight entropy, each new feature costs a bit more than the last. Putting what-if delegation in, before the Rule of 3 tells you how to best accomplish it, slows down everyone working in that part of the code, especially new people and folks trying to debug. You can organize code so it's hostile to delegation, or amenable to delegation. It's not free but it's relatively cheap, if your team is on-board. If not you're going to have a lot of teachable moments. I don't build what-if features into my code much anymore. What I build in instead is potential. If I wanted to change this code, here is where I would do it. But not yet.
hinkley 4y ago
The hard lesson I learned during the dotcom era and immediately after is that this cult like worship of version 1 ends up sinking many companies but since it's new nobody wants to hear, it doesn't get reported well. Any asshole can ship version 1. Shipping version 2 takes some talent. In particular, to your scenario, there's a reason why companies operate in 'stealth' mode. The moment they are on the public radar, now all of the time frames are based on customer interest and customer complaints. We have to keep some tempo of releases to build customer confidence. You can't launch the MVP and then immediately stop all work to address the tech debt you acquired. So we're not talking about 'after MVP' versus 'before MVP', we are talking 'this year' versus 'next year or the year after'. That's a long time to creak along with very bad initial architecture decisions. The value of a coach in sports or other activities is that this is a person who is not bogged down by the minutiae of the performance. They can see when you're stuck and tell you to stop. Very, very few developers have the ability to self-coach. It's one of the purposes of the morning standup: the hope that you hear yourself saying you've been wrapped around the axle on something and need a change of perspective. But the "stuckness" I'm talking about here has to do with Sharpening Your Axe. You're in a bad way because your 'tools' are not 'sharp', but you've already panicked about deadlines so you keep muscling through instead of realizing that the fastest way to complete tasks is to make the tasks easier and then do the task. That's the sort of tech debt that gets devs angry and resentful of people who tell them 'no'.
- marcus_holmes 4y ago
  Totally agree that version 2 is really painful, and more painful the more we cut corners on version 1. But I've seen sooo many startups ship version 1 and sink without trace. I'd say the vast majority of startups don't ever need to worry about version 2 because version 1 isn't going to get any traction. The thing about YAGNI isn't technical - it's commercial. Ship version 1 as cheaply and quickly as possible so you understand whether there's any point in continuing.

scott_w 4y ago

If adding these things really slows your ability to ship the first version of your product, you need to fire your team and start with a new one. These PAGNIs are: 1. log.info() calls 2. apt-get install postgresql 3. Using timestamp and datetime.now() instead of boolean fields 4. Adding a /v1/ into your API endpoints I'm being serious. If your team says "this will add a week onto the release date" then your team is either very junior or bullshitting you.

galangalalgol 4y ago
If it is just API endpoints, but I can see some junior dev spending time putting version numbers on literally every data structure, taking the exception as a rule. And when logs go from "huh, if this happens I want to know about" type thoughts as you are coding to "lets make a full pass and see where I could have added some logs to this PR" then effort is being spent too far in advance. I definitely agree timestamps, two vs many, and don't reinvent the database (or don't assume your db is flat) are effort free and always worth it. With the caveat that you maybe can't afford the overhead of a full rel db, and have to use something like an ECS for performance reasons. This is pretty common for embedded or game domains.
- scott_w 4y ago
  > I can see some junior dev spending time putting version numbers on literally every data structure That's a strawman argument. > And when logs go from "huh, if this happens I want to know about" type thoughts as you are coding to "lets make a full pass and see where I could have added some logs to this PR" then effort is being spent too far in advance. That's a strawman argument. > have to use something like an ECS for performance reasons. This is pretty common for embedded or game domains. If your domain requires something else, you probably already know it.
marcus_holmes 4y ago
Sure, but it escalates quickly. Logging goes from `log.Println("the thing happened")` to structured logging via an API very easily. Adding Postgres is a no-brainer. Totally agree. But should you architect the database properly? It's going to be tricky to normalise data later, maybe we should start with properly normalised tables now, instead of jamming everything into a jsonb field? Versioning, sure, but does every API need a version? If so, shouldn't we write some standard code for versioning all the things? Should the CICD process version the system automatically? Talking of which, we should set up the CICD. There's a rabbit hole. These things are all good, definitely worthwhile, but where do you draw the line? If we spend a couple of days doing X, then it becomes worthwhile spending a couple of days doing X+1, and so on. The author drew the line here. But that's not the only place you can draw the line. You can draw it a few paces back too. There's always a temptation as a techie to add a couple of days now to save a couple of weeks or months later. That may not be the right commercial decision.
- scott_w 4y ago
  The detail you're going into are the YAGNI part. Yes, you'll get those eventually, but you deal with _those_ problems later. Log to a file right now and switch to DataDog, Papertrail, etc. later on. Add /v1/ now, worry about integrating CI/CD into that later, when breaking changes means you actually need to worry about using versioning. I'd think it's implied that you just normalise the tables. It's really not hard to build and use a normalised database. I was doing this in my first months as a junior developer, so I'd expect an engineer with any seniority to be able to do it. If you're asking: "should we model the domain perfectly?" then my answer is a simple "model the domain as you understand it _today_." YAGNI is not "write shitty code" but "don't add things you don't need right now." Again, if adding /v1/ into your first URL string or configuring your logging takes "a couple days" each, then I'm going to have serious concerns.

galangalalgol 4y ago

I agree that we have to be very vigilant against the what ifs, but with the exception of logging, which is the one I most disagree with (unless it is helping you debug a failed test), these all seem like cases where the future thinking thing takes precisely as much time as the ship-it-now thing. The versioning thing could get really out of hand too probably now that I think about it. But timestamps, many vs two, and the "uh this is starting to sound like a database, lets use one" are all effort neutral.

hinkley 4y ago
I irritate myself constantly by realizing that this bug fix I'm working on would have been easier if I'd written some better tests first. Or noticed the order of a couple of log messages sooner.

AnimalMuppet 4y ago

YAGNI is about much more than avoiding premature optimization. It's about avoiding premature work, of any kind. Optimization, sure, but also implementation and even design. I know that design sounds like the kind of work you don't want to avoid. But designing, say, a spiffy database query cache so that you don't hammer the database with repeated queries, before you know that you need such a thing? Don't bother designing it. YAGNI. (I mean, you might go so far as to think "If we need it, we'll put it here". But an actual, detailed, implementable design? No. It's likely to be never needed, and is therefore a waste of your time.)

hinkley 4y ago
> It's about avoiding premature work, of any kind. It's even worse than that. Features have complexity, and they introduce constraints. Without active effort to fight entropy, each new feature costs a bit more than the last. Putting what-if delegation in, before the Rule of 3 tells you how to best accomplish it, slows down everyone working in that part of the code, especially new people and folks trying to debug. You can organize code so it's hostile to delegation, or amenable to delegation. It's not free but it's relatively cheap, if your team is on-board. If not you're going to have a lot of teachable moments. I don't build what-if features into my code much anymore. What I build in instead is potential. If I wanted to change this code, here is where I would do it. But not yet.

hinkley 4y ago

The hard lesson I learned during the dotcom era and immediately after is that this cult like worship of version 1 ends up sinking many companies but since it's new nobody wants to hear, it doesn't get reported well. Any asshole can ship version 1. Shipping version 2 takes some talent. In particular, to your scenario, there's a reason why companies operate in 'stealth' mode. The moment they are on the public radar, now all of the time frames are based on customer interest and customer complaints. We have to keep some tempo of releases to build customer confidence. You can't launch the MVP and then immediately stop all work to address the tech debt you acquired. So we're not talking about 'after MVP' versus 'before MVP', we are talking 'this year' versus 'next year or the year after'. That's a long time to creak along with very bad initial architecture decisions. The value of a coach in sports or other activities is that this is a person who is not bogged down by the minutiae of the performance. They can see when you're stuck and tell you to stop. Very, very few developers have the ability to self-coach. It's one of the purposes of the morning standup: the hope that you hear yourself saying you've been wrapped around the axle on something and need a change of perspective. But the "stuckness" I'm talking about here has to do with Sharpening Your Axe. You're in a bad way because your 'tools' are not 'sharp', but you've already panicked about deadlines so you keep muscling through instead of realizing that the fastest way to complete tasks is to make the tasks easier and then do the task. That's the sort of tech debt that gets devs angry and resentful of people who tell them 'no'.

marcus_holmes 4y ago
Totally agree that version 2 is really painful, and more painful the more we cut corners on version 1. But I've seen sooo many startups ship version 1 and sink without trace. I'd say the vast majority of startups don't ever need to worry about version 2 because version 1 isn't going to get any traction. The thing about YAGNI isn't technical - it's commercial. Ship version 1 as cheaply and quickly as possible so you understand whether there's any point in continuing.