

Face It: You Can't Predict the Future - koblenski
http://sam-koblenski.blogspot.com/2015/04/face-it-you-cant-predict-future.html

======
aepearson
I feel like I don't have time to predict the future - too busy pushing things
into production...

I've worked with many future predictors though and it's absolutely horrible.
Always behind schedule, always seemingly off-task, and their code is a
nightmare to maintain.

Gotta admit, I'm a much greater fan of building stuff that works. If you need
a gizmo later, add it later.

------
jetskindo
I predicted the future all the time. The problem was I worked in a team, so
there were too many factors at play. When I was wrong, I could blame it on
others who didn't follow my structures to a T.

Then I was given the chance to work on a project on my own from scratch. It
was the most beautiful architecture I ever implemented. 30 deadline later, and
the stress of the real world, every single new feature was so hard to add
because they couldn't all be abstracted to just in case we used it more than
once.

Now I had no one to blame. Today, I hard code things and don't feel bad about
it because I know it doesn't matter until it matters. I can only imagine all
the time I would have saved if I had this mentality in the beginning.

------
j_baker
I think this is exactly the reason why you should make code generic enough to
be re-used. We have no idea what code is going to be re-used where, so it's
better to try to make sure it's easier to plug code into other unexpected
places.

Besides that, what the author proposes doesn't scale very well. If you're
working on a small codebase and you have a few classes that aren't as generic
as they could be, it's no big deal. But things get more complex when you have
a big codebase where bad design decisions can affect code in hundreds of
places.

~~~
proksoup
I don't build something complex from scratch, it comes from working simple
systems.

I don't know where to abstract and genericize (it's a word now) code until I
know where things are repeated.

I am more frustrated and confounded by my peers' attempts to abstract
prematurely than I am if they had simply tried to write code that did what it
needed to do instead of planning for a potential future before we have any
idea what that potential future is like.

My process is

1) Write it for one case 2) When the second case comes along, consider
abstracting 3) When the third case comes along, much more seriously consider
abstracting 4) When the fourth case comes along, it's probably embarrassing to
not have abstracted yet ... but depends on the goals of the project and the
timeline and the ease of learning the abstraction for the peers.

------
ianstallings
Keep in mind that "You aren't going to need it" comes from evidence gathered
over decades of the craft. And it focuses on _premature_ effort. Optimize and
make things generic where possible, just don't do it prematurely.

