5 ms·

> misdirected effort, when a problem is solved in a way that doesn't facilitate preparing other, possibly hardly-related, solutions in the future Would you be

by jsty 9y ago

> misdirected effort, when a problem is solved in a way that doesn't facilitate preparing other, possibly hardly-related, solutions in the future Would you be able to clarify what you mean by this? In my experience, trying to write all-encompassing software quickly leads to issues with actually ever getting anything out the door in a working state - better to solve your particular problem and generalise later as needed.

corobo 9y ago
In my experience misdirected effort comes more from a lack of planning or full-fat spec being produced before the work begins rather than an attempt to cram in every feature under the sun. Instead of knowing exactly what features to put in you get a request along the line of "We need something that does x" and no time to plan how to do x, so you end up with something that does it then the feature creep starts, making the original x look like a code version of Seth Brundle after his teleportation mishap in The Fly. The age old "Weeks of programming can save hours of planning"
- jsty 9y ago
  Totally agree. A few pages of good spec / design docs can save so much wasted effort. Indeed I'd struggle to think of many non-trivial past projects where committing the design to paper hasn't revealed some hidden flaw that would've bitten hard later on. > Seth Brundle after his teleportation mishap in The Fly For anyone who didn't get this reference like me ... http://i43.tinypic.com/2ngr969.jpg http://i43.tinypic.com/2ngr969.jpg
- _asummers 9y ago
  I think the underlying wisdom is "don't create frameworks for your solution before you have it" not "don't anticipate your first and second degree direction changes".
dmos62 9y ago
I meant the opposite of all-encompassing software. What I mean is largely summed up by the linked Wikipedia article, but I'll give a go at explaining it in my own words. Given a problem, a solution can be found that explicitly composes simple routines in simple ways, or a solution that may do the same thing implicitly, but only exposes an in and an out. The first solution can be said to be following the Unix philosophy; the second follows the monolithic design [0] paradigm. The first solution is superior, in that it is "simple, short, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators" (quote from Wikipedia). Generally, creating something new in the Unix style goes like this: I have `X`, I want to arrive at `Y`. The process can be summed up as a sequence of these transformations: `f1`, `f2`, `f3`. So the solution can be said to look like this: `Y = X | f1 | f2 | f3`. `f1` and `f3` are already available, possibly created by someone else while solving an entirely different problem, but the same subproblem). That means implementing `f2`. To implement this missing subroutine, the process is the same. So the benefit of this philosophy is that it leads to pooling of problem solving resources (i.e. people), by allowing multiple problem solvers to arrive at their unique solutions by solving common subproblems (writting common subroutines). [0] https://en.wikipedia.org/wiki/Monolithic_application https://en.wikipedia.org/wiki/Monolithic_application

by jsty 9y ago

corobo 9y ago

In my experience misdirected effort comes more from a lack of planning or full-fat spec being produced before the work begins rather than an attempt to cram in every feature under the sun. Instead of knowing exactly what features to put in you get a request along the line of "We need something that does x" and no time to plan how to do x, so you end up with something that does it then the feature creep starts, making the original x look like a code version of Seth Brundle after his teleportation mishap in The Fly. The age old "Weeks of programming can save hours of planning"

jsty 9y ago
Totally agree. A few pages of good spec / design docs can save so much wasted effort. Indeed I'd struggle to think of many non-trivial past projects where committing the design to paper hasn't revealed some hidden flaw that would've bitten hard later on. > Seth Brundle after his teleportation mishap in The Fly For anyone who didn't get this reference like me ... http://i43.tinypic.com/2ngr969.jpg http://i43.tinypic.com/2ngr969.jpg
_asummers 9y ago
I think the underlying wisdom is "don't create frameworks for your solution before you have it" not "don't anticipate your first and second degree direction changes".

dmos62 9y ago

I meant the opposite of all-encompassing software. What I mean is largely summed up by the linked Wikipedia article, but I'll give a go at explaining it in my own words. Given a problem, a solution can be found that explicitly composes simple routines in simple ways, or a solution that may do the same thing implicitly, but only exposes an in and an out. The first solution can be said to be following the Unix philosophy; the second follows the monolithic design [0] paradigm. The first solution is superior, in that it is "simple, short, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators" (quote from Wikipedia). Generally, creating something new in the Unix style goes like this: I have `X`, I want to arrive at `Y`. The process can be summed up as a sequence of these transformations: `f1`, `f2`, `f3`. So the solution can be said to look like this: `Y = X | f1 | f2 | f3`. `f1` and `f3` are already available, possibly created by someone else while solving an entirely different problem, but the same subproblem). That means implementing `f2`. To implement this missing subroutine, the process is the same. So the benefit of this philosophy is that it leads to pooling of problem solving resources (i.e. people), by allowing multiple problem solvers to arrive at their unique solutions by solving common subproblems (writting common subroutines). [0] https://en.wikipedia.org/wiki/Monolithic_application https://en.wikipedia.org/wiki/Monolithic_application