4 ms·

You're dismissing bottom up programing. That is actually a wide used technique, especially useful when the problem is not completely understood at the beginning

by nn3 12y ago

You're dismissing bottom up programing. That is actually a wide used technique, especially useful when the problem is not completely understood at the beginning.

_asummers 12y ago
It is also useful as a refactoring technique. Pulling common structures and patterns out to helper code often reveals the true structure of the existing code, which makes the end result easier to see.
- lugg 12y ago
  .. That is, provided you refactor again afterward to put things into the correct abstractions. I call this pulling out into helper code function "blowing up" the code, because it usually results in an order of magnitude larger amount of lines of code. This refactoring technique certainly helps make the core logic of the (usually) over complicated program visibly easier to see / grok from a distance. From there its just a matter of reducing / refactoring / simplifying things down to more correct (at least I hope) abstractions that don't overcomplicate the solution. This is most useful when you're given something like a 5k line script that does far too many things for far too many different reasons, all with very little if any documentation. (ie, bottom up refactoring, don't really know what the solution is but you know the current solution isn't the way to go)
Arwill 12y ago
>when the problem is not completely understood at the beginning That was my point too, you just formulated it in a more positive way. If the developer does not understand the problem completely, then he will do what you describe as bottom up programming. Experimenting, in addition to taking more time than just spilling out the solution, also produces code that is not used in the final solution. So yes, a library for manipulating a certain kind of data is nice. But when it has functions that are never used, that is lost productivity. And even if the library is there, when a function becomes necessary, it might require different parameters or different application over data. Then making a conversion routine around the library function to fit the new usage also takes time, and potentially leads to inefficiency. So my principle is that understanding the problem well is still better. That does not exclude experimenting, but its easier to experiment without spending time actually coding up a false solutions, just in ones head, when the problem is well understood.

by nn3 12y ago

You're dismissing bottom up programing. That is actually a wide used technique, especially useful when the problem is not completely understood at the beginning.

_asummers 12y ago

It is also useful as a refactoring technique. Pulling common structures and patterns out to helper code often reveals the true structure of the existing code, which makes the end result easier to see.

lugg 12y ago
.. That is, provided you refactor again afterward to put things into the correct abstractions. I call this pulling out into helper code function "blowing up" the code, because it usually results in an order of magnitude larger amount of lines of code. This refactoring technique certainly helps make the core logic of the (usually) over complicated program visibly easier to see / grok from a distance. From there its just a matter of reducing / refactoring / simplifying things down to more correct (at least I hope) abstractions that don't overcomplicate the solution. This is most useful when you're given something like a 5k line script that does far too many things for far too many different reasons, all with very little if any documentation. (ie, bottom up refactoring, don't really know what the solution is but you know the current solution isn't the way to go)

Arwill 12y ago

>when the problem is not completely understood at the beginning That was my point too, you just formulated it in a more positive way. If the developer does not understand the problem completely, then he will do what you describe as bottom up programming. Experimenting, in addition to taking more time than just spilling out the solution, also produces code that is not used in the final solution. So yes, a library for manipulating a certain kind of data is nice. But when it has functions that are never used, that is lost productivity. And even if the library is there, when a function becomes necessary, it might require different parameters or different application over data. Then making a conversion routine around the library function to fit the new usage also takes time, and potentially leads to inefficiency. So my principle is that understanding the problem well is still better. That does not exclude experimenting, but its easier to experiment without spending time actually coding up a false solutions, just in ones head, when the problem is well understood.