The tools that define us - Building a tool culture
cucumbertown.comGreat post. A point worth highlighting even more than it is in the post is this: "A tool is ready when others can use it."
Totally agree, tools are important and key to real understanding of what you're building. I worked for many years as a tooling and manufacturing engineer (non-software). Our typical product development cycle was something like this:
1) R&D engineer: invent something
2) Process & tooling engineer: invent the manufacturing process and design the tools to build the thing
3) Manufacturing & product engineer: monitor and improve product quality and yield
Many software companies, especially startups focus too much on 1 and not enough on 2 and 3. Also, there's always some friction between the R&D and process/manufacturing camps, the former typically look down on the latter as technicians or paper pushers. In the other direction there's often the perception of R&D as being out of touch with the real world. Also, it's easier to hide incompetence in R&D because the metrics are foggy.
It guess the counterpoint to this is that tools are fun to build and it can be easy to fall into the trap of spending too much time building tools instead of other priorities. I've seen a lot of developers over the years use tool building as a way to procrastinate on more important tasks (myself included), or build things that just become obsolete and useless within weeks
You can avoid the trap applying the usual rule of three [1]. You do something manually once or twice - once you find you need to do it the third time, it's a good indication you should automate.
[1] http://en.wikipedia.org/wiki/Rule_of_three_(computer_program...
But don't short-circuit this. If you build after the first time, you may well not know enough to build the tool right. After you've done the process more than once, you have a fair idea of what the tool needs to do.
Exactly - the Agile Manifesto came to mind as soon as I read the title. i.e. "Individuals and interactions over processes and tools"
I don't think the Agile Manifesto is saying "Don't build a bash script, type it in by hand each time." I think it's saying "Don't assume that a vendor can sell you software to make agile happen - it's up to the people to interact with each other in less-burdensome ways."
Or a tool can suck up more time than it saves.
Yes, anytime you're working on something that's supposed to be for a business and you're going "wheeee!" and "wow so cool", you should be questioning whether you're building it because it's needed, or because it's fun to build. Engineers have a way of doing things they enjoy, and then retconning it as important and necessary, even noble.
This is also my problem with people who talk about being "builders" and "makers". Are you building and making things that need to exist, or sating your need to build and make? Not that that's inherently wrong, but it is certainly not inherently noble or impressive.
Do you know any full-blown products that started as an internal tool?
http://phabricator.org/ - at Facebook
http://www.google.com/analytics/ at Urchin
I think pretty much the entirety of AWS would qualify. - https://plus.google.com/+RipRowan/posts/eVeouesvaVX
I have heard from friends at Amazon that that is in large part an origin myth. This is hearsay, so take it fwiw.
In gaming: all of the idTech engines, the Unreal engine, and so forth.
Unix was an internal tool at Bell Labs, as was C.
Rails was pretty much just a framework over at 37signals before it spread.
~
This happens a lot in software.
Isn't the Swiss Army knife pictured in the dictionary next to "dull tool?"
The cult of the Swiss Army Knife is right up there with the cult of the Leatherman and the cult of WD-40 in encouraging people to fetishize general-purpose but dull tools. The Leatherman is a bit better than the SAK, but it is nothing like a set of top quality tools, just as WD-40 is both a cleaner and lubricant which means it isn't good at either.
I don't really like Swiss Army knives either many of the features are not very functional, or redundant within the tool itself.
I do have a, non-leatherman brand Leatherman and it's totally great.
It's great because I have it on me when I need it, and that's not going to happen with the rest of my tools, as I'm not bringing an entire tool box on a camping trip, or a bike tour, or traveling around the country.
I mean, ask Aron Ralston what he thinks was a good tool to bring along (other than a freakin' clue on things to do, before going on the types of trips he goes on).