3 ms·

> How do programmers here account for the unexpected? You don't. At least, I don't. When I'm writing code for an application, I'm doing the following... "Hmm

> How do programmers here account for the unexpected? You don't. At least, I don't. When I'm writing code for an application, I'm doing the following... "Hmmm, I need a function to perform <certain thing>" Function is written... tested... debugged until <certain thing> is achieved. Job done. Whilst writing said code, I do not think to myself "Hmmm... y'know in the future it might need to also do <some future thing>" and proceed to add additional function parameters and write additional code which would only be useful sometime in the future, just in case. No. I write sufficient code for what is required of said function at that moment in time. It is only if and when required would I then add any additional parameters and code to that function. Or write new functions.

klausjensen 8y ago
When I started as a developer 20 years ago, this was the most difficult thing for me. I would tend to over-think and include WAY too many "what if"-scenarios. So that is what I try to teach junior developers today: Only write what is required now and don't think too much about what the function might be expanded to do in the future.
pytester 8y ago
>"Hmmm... y'know in the future it might need to also do <some future thing>" Those are my trigger words. My experience is that about 97% of the time somebody says those words (in the past it's been me) in the context of writing software and it turns out that: * <some future thing> is never required. * <some future thing> is required but it ends up being needed in a completely different form, rendering the preparation work pointless. * <some future thing> was nice to have but it ended up so far down the list of priorities that it might as well not have been. This applies to every level of the stack from one off functions to grand features, to refactoring, testing and even to things that many people consider "best practice". I don't think it pays to be an extremist about many things in software but "if there isn't a glaring need for it then don't implement it" is one of them.
javajosh 8y ago
There's a difference between not adding bells and whistles you might not need, and shipping asymmetric, broken abstractions. Just because your app doesn't need to support vectors in the negative plane, for example doesn't mean you should ship a vector library that doesn't support negative numbers. In the same way I see well-meaning devs "dribble" data into an API, forcing future users to expand the API into a shape that could easily have been anticipated, and made cohesive sense. This stinginess with API is particularly bad because now developers learn to not respect API boundaries at all, because there aren't any. (And additionally it contributes to a lot of unnecessary indirection and typing because you have to define subset types at both ends of the API.) So, yeah, DON'T just add arbitrary stuff because you'll think it will be useful to someone; but DO add stuff to maintain the symmetry and understandable abstraction of what you've made.
- kungtotte 8y ago
  I think you're agreeing with everyone else. Including/writing a fully featured Vector library when you need a Vector library is perfectly fine; but if you're writing some code to handle those Vectors you should stop after it's done and not generalise it to also handle a bunch of other types in case you might need it later (because you probably won't).
  - javajosh 8y ago
    I wish I was agreeing! But sadly I am seeing more than a little but of jingoism here, which I think is 80% right, but like anything you can take it too far. "Every generalization is false," etc.
diminoten 8y ago
Not thinking about the future of your code is a great way to get your 9-5 done, but not a great way to actually write software. Honestly, it sounds like you're hourly, and not at all related to what the submission is talking about...
userbinator 8y ago
No. I write sufficient code for what is required of said function at that moment in time. It is only if and when required would I then add any additional parameters and code to that function. Or write new functions. I'll add that sometimes the more general solution also happens to be the simpler one, and in that case you should always take the simpler one even if it's more general, because then you have both the advantage of simpler code now and flexibility for future change. To put it succinctly, "increase generality only when it decreases complexity."

klausjensen 8y ago

When I started as a developer 20 years ago, this was the most difficult thing for me. I would tend to over-think and include WAY too many "what if"-scenarios. So that is what I try to teach junior developers today: Only write what is required now and don't think too much about what the function might be expanded to do in the future.

pytester 8y ago

>"Hmmm... y'know in the future it might need to also do <some future thing>" Those are my trigger words. My experience is that about 97% of the time somebody says those words (in the past it's been me) in the context of writing software and it turns out that: * <some future thing> is never required. * <some future thing> is required but it ends up being needed in a completely different form, rendering the preparation work pointless. * <some future thing> was nice to have but it ended up so far down the list of priorities that it might as well not have been. This applies to every level of the stack from one off functions to grand features, to refactoring, testing and even to things that many people consider "best practice". I don't think it pays to be an extremist about many things in software but "if there isn't a glaring need for it then don't implement it" is one of them.

javajosh 8y ago

There's a difference between not adding bells and whistles you might not need, and shipping asymmetric, broken abstractions. Just because your app doesn't need to support vectors in the negative plane, for example doesn't mean you should ship a vector library that doesn't support negative numbers. In the same way I see well-meaning devs "dribble" data into an API, forcing future users to expand the API into a shape that could easily have been anticipated, and made cohesive sense. This stinginess with API is particularly bad because now developers learn to not respect API boundaries at all, because there aren't any. (And additionally it contributes to a lot of unnecessary indirection and typing because you have to define subset types at both ends of the API.) So, yeah, DON'T just add arbitrary stuff because you'll think it will be useful to someone; but DO add stuff to maintain the symmetry and understandable abstraction of what you've made.

kungtotte 8y ago
I think you're agreeing with everyone else. Including/writing a fully featured Vector library when you need a Vector library is perfectly fine; but if you're writing some code to handle those Vectors you should stop after it's done and not generalise it to also handle a bunch of other types in case you might need it later (because you probably won't).
- javajosh 8y ago
  I wish I was agreeing! But sadly I am seeing more than a little but of jingoism here, which I think is 80% right, but like anything you can take it too far. "Every generalization is false," etc.

diminoten 8y ago

Not thinking about the future of your code is a great way to get your 9-5 done, but not a great way to actually write software. Honestly, it sounds like you're hourly, and not at all related to what the submission is talking about...

userbinator 8y ago

No. I write sufficient code for what is required of said function at that moment in time. It is only if and when required would I then add any additional parameters and code to that function. Or write new functions. I'll add that sometimes the more general solution also happens to be the simpler one, and in that case you should always take the simpler one even if it's more general, because then you have both the advantage of simpler code now and flexibility for future change. To put it succinctly, "increase generality only when it decreases complexity."