Hacker News Reader

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.

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.

I have done my fair share of over-engineering. =) Its not over-engineering if you need it, but turns out, most of the time, you aint gonna.

A team that just hacks and does YAGNI by accident, or a team that does YAGNI but doesn't plan, they often have a choice of how to build the feature right now. With a little bit of planning, we can see past the first few meters and choose the first step to be in the direction of the bigger plan. Without planning, the first step might be in the wrong direction. The hard part for my teams is to plan, and then still only implement the first step. They're getting better =)

Its war because if you're doing something worthwhile, there's someone else trying to get your customers. I'm not suggesting your stuff should break. The opposite. Combine YAGNI with TDD and push working, tested features to production ASAP.

With a little bit of planning, we can see past the first few meters and choose the first step to be in the direction of the bigger plan.

I had a suspicion that despite the black-and-white way you have expressed your opinion elsewhere, particularly in your exchange with eridius, there probably was actually some common ground here. I don't believe it's possible to avoid the failure modes eridius describes without thinking ahead to some extent; this passage suggests you actually agree.

I can't speak to your experience with your team, but I can say that I've spent a lot of time fixing or working around other people's poorly-considered design decisions. In many cases I understand there wasn't time to do it better; the product had to be shipped. But in some cases I think a little reflection would have shown a better way which wouldn't have taken any longer to implement.

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

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...

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)

> 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.

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.

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.