Some throughs on a very geeky and techie conversation at work this week on the reasons we have for picking the tools we use to do our daily job.
We where talking at work again (yes I manage to get lots of work as well as talk in an average day) about development tools and projects.
The conversation came about because of a new project for an internal system which is coming from a different department. This project is going to be linux based.
This started the conversation of why this should be? Most of the core internal systems are Windows based, yes we have a few linux systems for one particular department, but this is while large is only used by a small number of people for a very specific task.
I mentioned that of course for any job the tool used should be the best for the job at hand, but this isn’t really an answer. What do you define as the best in this case? The cheapest, the fastest, the easiest to implement? Of course in any business project the best tool is defined as the one we already have (and have paid for) and the one we have the most experience in using.
This means the current tool set is almost always the one that gets used, so in this case the programers coming from a unix world, chose unix tools, Perl, Python, MySql and Apache. Okay so strictly speaking these are not unix tools, since all of them can run on a windows platform, but they all started off in a unix world and have been ported to windows.
This leaves a couple of problems, one the IT team doesn’t have any real unix experience and it would down to us to maintain the system. It’s only really me that has real world experience of managing Linux systems and I’m not really a sysadmin, I’ve got more experience on the programming side of linux. The second problem is are they going to authenticate against windows servers, since all uses exist on a windows domain?
Given these problems, is linux the best platform for the project? Well probably yes, since the team which is going to write build the project (who are not the normal in house development team) have experience there and the in house team, doesn’t have the time or experience work on this project. But the integration between the two different worlds is not going to be easy.
Feb
28
2010
