Having the Right Tools
Everybody knows that having the right tools has key importance on getting things done. Although we know this, sometimes we are lazy and avoid the overhead of reusing or developing this and that, here and there.
There is a great pleasure in doing things from scratch, starting a blank notebook. Well, this is not totally bad, particularly in science. As Joel says in here:
"When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.
Independently of reusing or rewriting, you'll take a toll for not having the proper tools for the job. This is a lesson I've learned a long time ago (mainly here and here) therefore I try to avoid making this mistake as much as possible. I always think: is there any tool I can have that will save me time on the long run?
A few weeks ago while talking with Hugo about the importance of having a framework that you grow by gluing the bits and pieces of the algorithms you develop, we got to the topic of having an inspector to the data structures used in the program. Ideally, these are the characteristics we would want it to have:
- Informative - Should give detailed information about the current state of the data structure, produce high-level metrics, meta-information about the algorithms and some kind of graphical representation;
- Unintrusive - Shouldn't alter the behavior or speed of the algorithms;
- Pluggable and Parallel - Should be able to start, stop and work while running, from remote processes and locations;
Probably we are asking too much but it's possible to have a compromise without over-engineering a solution.
