I have this wish that every large company that hired programmers would place at the programmers' disposal a Linux server with just about every GNU programming tool in existence on it -- or would install every GNU tool on every workstation that has the disk space for them. It doesn't seem that a server would cost the company much of anything, and its existence would guarantee that if a programmer found himself needing some GNU tool that actually existed, he or she could go use it on the server. Giving programmers more tools seems like a good thing, and if the tools are free, it doesn't seem to matter much if the tools sit around most of the time not being used. I guess I don't understand why company management would want to pick and choose the tools their programmers are allowed to use. You don't hire carpenters and tell them, "We don't use hammers in this company," but managers over programmers do make these decisions, and this makes programmers' lives more difficult. Companies seem to find every reason not to set one of these schemes up, including:
- It would make it too easy for some programmer to use a tool that nobody else knows how to use, thereby promoting a lack of standardization, and low TruckNumbers. (On the other hand, with PairProgramming or some other proper communication system in place, programmers should be able to teach each other the tools until all of them knew all of them.)
- Two programmers might end up doing the same exact thing with different tools. Redundant work eliminates the benefits of hiring more people.
- Programmers would spend more time playing with the server, or the programs on it, than working. (But a good company checks whether its programmers are getting assigned tasks done or not.)
- It's more likely that the company could get entangled in licensing issues. Most companies don't want to find that they have "accidentally" authored a bunch of new GNU code. (But it's certainly possible to guard against this.)
- Making programmers more skilled without giving them consummate pay increases just encourages them to leave the company. I have actually heard senior managers say this to meetings of programmers.
- The programmers might automate some poor non-programmer out of his job.
All of these seem like silly excuses. Is there something critical I'm missing here? Why aren't companies doing this?
Some companies do. I am in a very Windoze company; In my team we converted a 450MHz machine which had become available to SuSE 7.1. This is to run roaring penguin PPPoE termination (don't ask, look it up on the web and provide a URL here if you care) [PointToPointProtocolOverEthernet], and we're now also running a wiki for all kinds of odds and sods of project information, the most important current use being meeting agendas and minutes.
The main real 'resistance' was that PCs ship with windows not with Linux. This is irrelevant once older PCs become available for reuse. The forces you mention above are countered by:
- There's an ethos of people educating each other in this company, so the 'obscure tool that no one else can use' risk doesn't apply.
- The danger of wheel-reinvention isn't solved by denying people access to wheel building tools. The solution is communication and sharing of tools and techniques, which happens between the groups using this Linux server.
- People would 'spend more time playing with Linux than working', so far hasn't happened. There is too much to do for that, and the work we do is visible.
- We're not selling-on any tools or software developed on the Linux box. We're mostly doing perl scripts, and if perchance we are actually violating a GNU license by not releasing our in house code, no one would know. [The GNU license does not require you to release your code; it only says that if you release a binary, you have to release all the source code, too (and meet a few other simple conditions).]
- The company's attitude to up-skilling is that you are more likely to lose good programmers if you give them dull work and no control over it than you are by helping them develop their skills. Another take on this is that the best way to retain people is to make it easy for them to leave - for it forces you to make the working environment one that people would think twice about giving up.
- A programmer is unlikely to automate some non-programmer out of a job. All that would happen is that the quality of documentation, or of testing would increase suddenly as the existing documenters and testers found themselves with more time to do their job. [There is also a policy of turning testers into developers, but that is another story]
Oh dear. I sound like an apologist for the management at our company. I think it is relevant that the managers of the software development side were all once programmers, and good ones too, and most still keep their hand in.
Stats - number of employees in development about 40. Typical team size about 6.
--JamesCrook
A lot of people don't know about the GNU tools or are put off by the command line interfaces. A lot of companies fear OpenSource.
I find that in situations where a company is paid to write software for someone else on a contract basis, the people with the money tend to ask that the software be written to conform to their coding standard, and to work with their tools, in their version control system, and so on. I think that the more familiar a programmer is with the available tools of the industry, the more suited he or she will be to facing a new client with a new set of idiosyncrasies.
While it is true that a programmer is probably a lot more efficient using tools they are very familiar with and an environment in which they are comfortable, someone down the line has to make everything fit the customer's specifications, and the customer is probably not going to be too keen on doing it themselves. -- JacobCohen
Common Programmer Tools