Don’t be stubborn! Choose the right tool for the job
Software Development August 3rd, 2006I’m sure everyone knows a developer like this. No matter what the task or goal is, they always use the same toolset. The question I’m going to pose is why? It’s my contention that programming languages should be like tools in a toolbox. You can have the nicest hammer in the entire world, but it’s not going to do much for you if what you need to do is to put a hole in a piece of wood. This is one reason that I like learning new programming languages, some languages are just better suited at specific tasks.
I’ll give you an example. I was involved in a software project that went something like this. We downloaded a third party library in PHP, but it didn’t have all the features that our team needed, so we decided to engineer our own. It was going to be a web application, so we stuck with PHP. The project also was a great candidate for object oriented design, so that is how we developed our package. Now lets fast forward a little bit. Our library worked great, but we were starting to see some performance issues because of large data sets, so we decided to port this to a compiled language. We had some people suggest C, because….well they know C. Don’t get me wrong, C is a great language, but C++ would be a much better choice. We could keep the object oriented design and just port the existing code for the most part. The argument I got back was that we could just use C and use function pointers and structures. Sure. That’s a great idea. We could also try to dig a ditch with a spoon. Why not use the tool best suited for the job? This whole “fit the square peg into the round hole” philosophy is enough to drive me insane.
My favorite programming language is C#, but if I had to write a web application on a Linux server I sure wouldn’t install Mono on it to do it, I could very easily use PHP instead, because in my opinion it’s a better tool for the job. Some of you are probably saying to yourselves, “you’re just stating the obvious here”. I wish that was the case…I’ve seen this phenomenon way too many times. We all have our favorite languages and tools, but I won’t blindly defend my choices without at least considering the task at hand, and whether or not something else makes sense in this situation.
Another problem I see is taking an existing piece of software, and using it again in another application. Before you say it, I’m not going crazy……let me finish. Generally this is the GOAL of a piece of software, but don’t reuse stuff for the sake of reusing it. Make sure if you are going to reuse something that it actually accomplishes the goal, and does it well. Don’t just bolt on a crappy library because it kind of does something that you think that you need. Just because one of the things that library you wrote back in 2001 did was dynamic image manipulation doesn’t mean it’s a good fit for your web application today.
But it’s not standard!!
This one is harder for me, because standards are a good thing. BUT, if you are going to have standards they need to be kept up to date, and a full range of tools should be available. I’ve run into people who are working on projects using languages that they know aren’t the best choices. They are forced to do this because the companies they work for won’t allow any other tool to be used. Your just putting yourself in a position to fail in this case.
So change the way you design your application. In fact, don’t even choose a language until you have all of the requirements. Figure out your use cases and requirements, then talk about the pros and cons of different languages. Also, if you have some down time, try a new tool or a new language. Heard a lot about Ruby on Rails? Try it out! Reading the pros and cons of PHP vs. ASP or ASP.NET? Try both and form your own opinion. It never hurts to add to tool to the toolbox.
August 5th, 2006 at 11:54 pm
“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.
November 24th, 2007 at 12:35 pm
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.
November 24th, 2007 at 4:21 pm
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.