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
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.
Absolutely right about using standard tools. It doesn't do the project much good if new people have to learn about custom tools just to develop for it, unless those custom tools are doing something revolutionary.
ReplyDeleteFor Java you have two options: the logging API that was added in 1.4 (with a pre 1.4 JVM it can be used as an outside library) and also Aspect Oriented Programming, which is starting to catch on especially with Eclipse. They can be used together too.
we're using java 1.3 I believe, which doesn't have logging. But we're using tools like struts and others that all use the Jakarta Commons logging libs. I figure might as well use those since the jar's are in the project anyways. ;-)
ReplyDeleteI'll have to look into Aspect Oriented Programming more. Do you recommend any articles?
I linked to this one on my miniblog a little while ago:
ReplyDeletehttp://www.theserverside.com/articles/article.tss?l=AspectOrientedRefactoringPart1