I've had a couple of conversations with someone in software development. They have some "engineers" working for him and he offered to help me out by giving me some tools to do my work. Everything cool so far? Yes. I really like help, and if there is a tool out there that can help me do my job better / faster, I'm all for it.
The reason why I didn't take up the offer is that the tools are things like a logger and a load testing tool. When offered the logger, I was like "I'd rather just use one of the common java loggers", to which the counter argument that was given was "yes, but you have to
learn how to use it and it's usually more than you need right now". Maybe, but then again I'd have to
learn how to use sw made by anyone else. There are many more arguments against using in house tools when free ones are easily available. Some of these are:
- if many other people are using it, it's been tested in the field a lot more
- my skills are more portable if I use a common tool
- if I left the company, it would take less effort for a new developer to come in and learn a tool that they could have possibly seen before
- with tools used by many people, it's more likely that there's lots of things on the 'net about how to use them
- I've not been hired to make tools, I've been hired to make another product
It just blows my mind when people have the mindset to reinvent tools. I don't know about you, but my time is short enough as it is, and I don't think that my boss would be too happy if my product was late "but I made a really cool tool!".
As for the load testing tool, the reason behind that was because they didn't want to buy a tool that costs 500,000 $, so one of the developers wrote one. With tools like
JMeter, I don't see why you would need to hire someone to redo that sort of stuff. And if you have
a developer that could turn out 500K$ sw in a couple of weeks, he surely must be able to walk on water, because I've never even heard about someone who could do that.
The short story for this rant is that by doing
engineering we
are responsible for the tools we use, and why we choose those ones. Just because you're not writing sw to control planes doesn't mean that you should take short cuts that in the long run take longer, are more error prone, you have to maintain and train people to use, and in the end cost more while not solving the customer's problem.