4 ms·

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 "ri

by saganus 11y 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.

guscost 11y 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."
- saganus 11y ago
  I think what I was trying to say it's not really that developers are divorced from science, but that the day-to-day tasks that we do end up being far from whatever paper or thesis taught us how to do. The example that comes to mind is REST. There is a lot more in that PhD thesis than what is actually used and implemented outside of the lab. That's what I meant for craft. In the end I don't see anyone implementing "all the science" regarding REST, only those parts that are needed and even then... as best as some engineers understood it (myself included of course). That's also the reason why we end up calling "RESTFul" a lot of stuff that Thomas Fielding clearly states is not. At least it's good knowing that I'm not alone and other people feel the same. So in the end I know that I can do my best... but not more. It's a funny beast this development thingie... Edit: So basically just reinforcing your point...
nvarsj 11y 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 11y 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.
lowbloodsugar 11y 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.
- saganus 11y ago
  This is actually very interesting. However, I still am left with the feeling that you have reached this conclusion by means of more than three decades of practicing both the right thing and the wrong thing as well (we all make mistakes, etc). So basically, how did you realized that "Plans are useless, but planning is indispensable" if not precisely by trying to plan, and then observing it's uselessness? I could almost bet that you now assume that the architecture will be wrong in a week's time and yet you always find a way to actually make it resilient to this and make it work, otherwise I would have to wonder how did you ever accomplished something if indeed 100% of your architectures was wrong in a week's time. I.e., this is your experience in your craft. Flowing like water, Bruce Lee would say. Now, the point I did not get though, is, what exactly are the differences between being a craft or being war? If it's a craft I kind of assume, like you, that I'll never be able to design the perfect architecture, but only the best architecture that I could have produced at the time. And just strive to get better every time. If it's war, then it basically means that at any time anything can explode, but then I would be filled with despair all the time I guess. Maybe not. Is this what you refer to? if it's war you have to design assuming it will break very shortly and then work around that? or "make do with what I have" as they say? Again, very interesting points and I appreciate the discussion since this has been haunting me almost my entire career. Edit: By the way, I hope you don't me if I quote you. Those are some nifty points right there.
  - lowbloodsugar 11y ago
DanielBMarkham 11y 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)
- zimpenfish 11y ago
  > Eventually you realize that brutally maximizing simplicity is as important as actually solving the problem. Probably more so. Just wanted to quote this as a perfect software development aphorism.

by saganus 11y ago

guscost 11y 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."

saganus 11y ago
I think what I was trying to say it's not really that developers are divorced from science, but that the day-to-day tasks that we do end up being far from whatever paper or thesis taught us how to do. The example that comes to mind is REST. There is a lot more in that PhD thesis than what is actually used and implemented outside of the lab. That's what I meant for craft. In the end I don't see anyone implementing "all the science" regarding REST, only those parts that are needed and even then... as best as some engineers understood it (myself included of course). That's also the reason why we end up calling "RESTFul" a lot of stuff that Thomas Fielding clearly states is not. At least it's good knowing that I'm not alone and other people feel the same. So in the end I know that I can do my best... but not more. It's a funny beast this development thingie... Edit: So basically just reinforcing your point...

nvarsj 11y 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 11y 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.

lowbloodsugar 11y 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.

saganus 11y ago
This is actually very interesting. However, I still am left with the feeling that you have reached this conclusion by means of more than three decades of practicing both the right thing and the wrong thing as well (we all make mistakes, etc). So basically, how did you realized that "Plans are useless, but planning is indispensable" if not precisely by trying to plan, and then observing it's uselessness? I could almost bet that you now assume that the architecture will be wrong in a week's time and yet you always find a way to actually make it resilient to this and make it work, otherwise I would have to wonder how did you ever accomplished something if indeed 100% of your architectures was wrong in a week's time. I.e., this is your experience in your craft. Flowing like water, Bruce Lee would say. Now, the point I did not get though, is, what exactly are the differences between being a craft or being war? If it's a craft I kind of assume, like you, that I'll never be able to design the perfect architecture, but only the best architecture that I could have produced at the time. And just strive to get better every time. If it's war, then it basically means that at any time anything can explode, but then I would be filled with despair all the time I guess. Maybe not. Is this what you refer to? if it's war you have to design assuming it will break very shortly and then work around that? or "make do with what I have" as they say? Again, very interesting points and I appreciate the discussion since this has been haunting me almost my entire career. Edit: By the way, I hope you don't me if I quote you. Those are some nifty points right there.
- lowbloodsugar 11y ago

DanielBMarkham 11y 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)

zimpenfish 11y ago
> Eventually you realize that brutally maximizing simplicity is as important as actually solving the problem. Probably more so. Just wanted to quote this as a perfect software development aphorism.