Do you know any full-blown products that started as an internal tool?
I think pretty much the entirety of AWS would qualify. - https://plus.google.com/+RipRowan/posts/eVeouesvaVX
The tools that define us - Building a tool culture
11–18 of 18 posts
Re: The tools that define us - Building a tool culture
#12It 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
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.
Re: The tools that define us - Building a tool culture
#13Do you know any full-blown products that started as an internal tool?
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.
Re: The tools that define us - Building a tool culture
#14Do you know any full-blown products that started as an internal tool?
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.
Re: The tools that define us - Building a tool culture
#15It 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...
Re: The tools that define us - Building a tool culture
#16Do you know any full-blown products that started as an internal tool?
I think pretty much the entirety of AWS would qualify. - https://plus.google.com/+RipRowan/posts/eVeouesvaVX
Re: The tools that define us - Building a tool culture
#17It 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.
Re: The tools that define us - Building a tool culture
#18It 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
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."