4 ms·

When you do a cost-benefit analysis, do you find that it's worth your time to tinker with all that and switch between systems? That's why companies standardize

by barnaby 17y ago

When you do a cost-benefit analysis, do you find that it's worth your time to tinker with all that and switch between systems? That's why companies standardize on a toolchain. By the way, we standardized on Ubuntu at my company. And while the the home computer is my girlfriends Macbook I hardly ever really use it, so I voted once.

davi 17y ago
It depends on the context. In my context, we are building something new, that has never existed before, and we don't know the design we are going to converge on. Of course we have some reasonable ideas that we want to try out. But for us, slapping components together to achieve a desired behavior is way more productive than building that behavior cleanly de novo, because we don't know if the behavior we have in mind will work. The immediate goal is to try out a broad gamut of possibilities, quickly; find something that works; and then to push ahead to the next stage of the workflow. The medium term goal is to assemble a workflow that takes us from sample to analyzed data. The longer term goal is to iterate this workflow, so we go faster and faster from sample to analysis, on bigger and bigger data sets. As we complete a single iteration, we get a chance to clean up our toolchain. But we only to clean it up enough that it will support the amount of scaling up we want to do in the next iteration, since the next level of scale will introduce new, unexpected problems. Once we have a system that runs fast enough, and big enough to be worth deploying on an ongoing basis (say for a five year lifespan) it starts to pay to build a clean toolchain, reducing our ridiculous, MacGyver'ed, Rube Goldberg monstrosity into something clean, maintainable, and extensible. But if we tried to do this from the beginning, by now we would have gotten exactly.... nowhere. Of course there's a balance. One perpetually runs the risk of creating an intractable hairball. That's another sign it's time to clean up the toolchain...

by barnaby 17y ago

davi 17y ago

It depends on the context. In my context, we are building something new, that has never existed before, and we don't know the design we are going to converge on. Of course we have some reasonable ideas that we want to try out. But for us, slapping components together to achieve a desired behavior is way more productive than building that behavior cleanly de novo, because we don't know if the behavior we have in mind will work. The immediate goal is to try out a broad gamut of possibilities, quickly; find something that works; and then to push ahead to the next stage of the workflow. The medium term goal is to assemble a workflow that takes us from sample to analyzed data. The longer term goal is to iterate this workflow, so we go faster and faster from sample to analysis, on bigger and bigger data sets. As we complete a single iteration, we get a chance to clean up our toolchain. But we only to clean it up enough that it will support the amount of scaling up we want to do in the next iteration, since the next level of scale will introduce new, unexpected problems. Once we have a system that runs fast enough, and big enough to be worth deploying on an ongoing basis (say for a five year lifespan) it starts to pay to build a clean toolchain, reducing our ridiculous, MacGyver'ed, Rube Goldberg monstrosity into something clean, maintainable, and extensible. But if we tried to do this from the beginning, by now we would have gotten exactly.... nowhere. Of course there's a balance. One perpetually runs the risk of creating an intractable hairball. That's another sign it's time to clean up the toolchain...