Comments on: Don’t be stubborn! Choose the right tool for the job http://www.jaltiere.com/index.php/2006/08/03/dont-be-stubborn-choose-the-right-tool-for-the-job/ .NET Software Development Mon, 14 Nov 2011 14:58:38 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Jack Altiere http://www.jaltiere.com/index.php/2006/08/03/dont-be-stubborn-choose-the-right-tool-for-the-job/comment-page-1/#comment-16189 Jack Altiere Sat, 24 Nov 2007 20:21:54 +0000 http://www.jaltiere.com/?p=8#comment-16189 You had nothing to do with my rant. :) I forget what inspired it, probably a blog entry or article somewhere...........I just tried to relate it to my own experiences. You both make solid points, it is a difficult balance between the capabilities of a software team and the needs of a given project. You had nothing to do with my rant. :) I forget what inspired it, probably a blog entry or article somewhere………..I just tried to relate it to my own experiences.

You both make solid points, it is a difficult balance between the capabilities of a software team and the needs of a given project.

]]> By: bmr http://www.jaltiere.com/index.php/2006/08/03/dont-be-stubborn-choose-the-right-tool-for-the-job/comment-page-1/#comment-16183 bmr Sat, 24 Nov 2007 16:35:46 +0000 http://www.jaltiere.com/?p=8#comment-16183 I think I agree with Steve. Although I definitely agree that it is frustrating to work with a manager/decision maker that is not willing to entertain new (or unfamiliar) technologies. Somehow you have to balance the current capabilities of your organization with the needs of the project. So hopefully this rant was not inspired by something I said -- since I am familiar with said project. To me it makes no sense to take an object-oriented design back into an imperative framework, unless the project was abysmal failure to begin with. The point is the decisions should be based on logical arguments. "We don't do that" is a pretty weak argument unless the barrier of entry is extremely high. On the other hand, I have seen certain developers design whole frameworks for something like servo motor control. Which is not necessarily bad, but the developer had no experience with that concept and did not consult others who had a lot of experience. I think I agree with Steve. Although I definitely agree that it is frustrating to work with a manager/decision maker that is not willing to entertain new (or unfamiliar) technologies. Somehow you have to balance the current capabilities of your organization with the needs of the project. So hopefully this rant was not inspired by something I said — since I am familiar with said project. To me it makes no sense to take an object-oriented design back into an imperative framework, unless the project was abysmal failure to begin with.

The point is the decisions should be based on logical arguments. “We don’t do that” is a pretty weak argument unless the barrier of entry is extremely high. On the other hand, I have seen certain developers design whole frameworks for something like servo motor control. Which is not necessarily bad, but the developer had no experience with that concept and did not consult others who had a lot of experience.

]]> By: Steve F. http://www.jaltiere.com/index.php/2006/08/03/dont-be-stubborn-choose-the-right-tool-for-the-job/comment-page-1/#comment-9 Steve F. Sun, 06 Aug 2006 03:54:58 +0000 http://www.jaltiere.com/?p=8#comment-9 "Best tool for the job" has a qualifier that should be considered -- the strengths of the developer entrusted with executing the job. For example, if the lead developer in Company XYZ, with years of understanding the business requirements of Company XYZ, is charged with building a new business app on a Windows box, and this developer eats and breathes, say, Perl on Linux, is slapping a copy of ActiveState Perl on the Windows box and going to town a recipe for disaster? It would be hard to argue that WinPerl is the best tool for the job on a Windows box if evaluated as a purely technical decision. However, what is gained by this compromise is the comfort of your developer lead -- the person with the outstanding sense of the business requirements. By making this technical compromise, he's more likely to be able to see the solution as a whole, seamlessly translating business requirements into technical output without a painful bottleneck as he learns a new language. Ideally, this example user would be the program manager in charge of tech folks who COULD use something like .NET. But in smaller companies, that's not always an affordable luxury. “Best tool for the job” has a qualifier that should be considered — the strengths of the developer entrusted with executing the job.

For example, if the lead developer in Company XYZ, with years of understanding the business requirements of Company XYZ, is charged with building a new business app on a Windows box, and this developer eats and breathes, say, Perl on Linux, is slapping a copy of ActiveState Perl on the Windows box and going to town a recipe for disaster? It would be hard to argue that WinPerl is the best tool for the job on a Windows box if evaluated as a purely technical decision.

However, what is gained by this compromise is the comfort of your developer lead — the person with the outstanding sense of the business requirements. By making this technical compromise, he’s more likely to be able to see the solution as a whole, seamlessly translating business requirements into technical output without a painful bottleneck as he learns a new language.

Ideally, this example user would be the program manager in charge of tech folks who COULD use something like .NET. But in smaller companies, that’s not always an affordable luxury.

]]>