This essentially describes how to set up one step of a production process such that workers who fulfill that step are interchangeable cogs. In practice, people within a software project are not interchangeable cogs, and treating them as such, even indirectly, is counter productive.

There are good reasons, however, to have a standardized devlopment environment. For one, if you're doing eXtreme Programming, then pair programming is difficult if only one half of a pair can drive a customized editor. For another, if tools are standardized, then updating them (say, for security patches) is a lot easier if all desktops have a common set of tools.

For another, if tools are standardized, then updating them (say, for security patches) is a lot easier if all desktops have a common set of tools.

That's an argument I do not buy. I've worked too long in sysadmin departments. Maintainance of tools is important (and needed). And therefore, desktops shall have NO tools. Nada. You put them on a central file server, and use NFS (or whatever they use in a Windows environment) to install something once, and make it available everywhere. In a large environment, or in a heterogeneous environment, you might use AFS instead of NFS, for the same reasons.

Providing your developers a consistant set of tools, regardless of their actual physical seating place is a good thing, and independent of whether you have a standard set of tools. But standardizing (or rather, limiting) the set of tools has its benefits too. Take editors for instance. Installing a flavours of emacs, the entire army of vi look-a-likes, pico and whatever else is out there is one thing, but once you do, developers will insist you always have the latest version with all the bells and whistles possible. Of course, you'd need to keep the old version around, because someone will exploit the undocumented feature that was fixed in the newest release. And then a new flock of cheap teenagers enters the workforce, and rob the sysadmin of her valuable time by asking how to delete a line using editor X (which the sysadmin doesn't know, as she has always used 'd' or 'dd' just as god intended). And that's just free editors - there are also commercial editors like Crisp, that need license keyservers.

This is just text editors, which are relatively small and easy to maintain. But then everyone wants their favourite mail reader, news reader, web wowser, GUI editor, scripting language, coffee machine, and god knows what. Then the situation quickly becomes unmanageble.

It's best to have some form of middle ground. Have a relatively small set of tools for the same task. Emacs, vi, ed and a modern vi-look-alike for editors for instance. More editors can be included if someone can make a good case. But "I got to use vi-plus-plus 4.7.2.5alpha2b with these 15 options buildin, because I like the dancing penguin theme" just isn't going to do it. "Here's vi, kiddo. It has no theme or colours. Deal with it.". And the same for other classes of tools.

Abigail

This was how they did it at a LARGE company that I worked at recently. Their solution was not allowing any text editor except EditPlus & VI, and any OS except Windows 95 and HP-UX. (They are moving to Win2k in the next six months if they can figure out how to do it without bringing down the network.) Allowed programming languages were Java 1.3.1, PHP, Pl/SQL and Korn shell. They did have official version control software, PVCS, but only the managers were allowed to use it so as to keep things effecient.

The company worked very hard at keeping desktop problems to a minimum saving a lot of time and money in terms of tech support and system administration. It also helped keep quality programming down to a minimum.

It's amazing to me that companies hire people that they entrust with programming very expensive networked servers and yet don't think that they can be given control of a $1,000 desktop workstation. Garbage in, garbage out.

()-()
 \"/
  `                                                     

That's an argument I do not buy. I've worked too long in sysadmin departments. Maintainance of tools is important (and needed). And therefore, desktops shall have NO tools. Nada. You put them on a central file server, and use NFS (or whatever they use in a Windows environment) to install something once, and make it available everywhere.

Our experiences differ here. I've seldom worked at a place where run-everything-off-one-server was a stable solution, usually because of a geographic split between servers and developers, complicated by building moves and "oh f*ck, somebody didn't arrange for enough bandwidth between building A and B."

A run-everything-off-one-server configuration also introduces a single point of failure. You can protect the server with RAID5 and big UPSs, but it's still a single box sitting there waiting for the gremlins to sink their teeth into it. If a single developer box goes out, replacing it is easy, and at worse you lose a developer day. If the server everyone depends on goes out, you're hosed. And for some strange reason, hosing always seems to happen about 12 hours before a major deadline.

A couple of thoughts come out of your words here.

First, I completely agree with your point about the importance of the maintainance of tools.

I was instrumental in setting up an architecture that automated this task of program installation and maintainance of 700 'approved' apps (reduced from the surveyed 7000+ prior to integration) across 600 LANS in 350 locations spread across an entire country. If the right SysAdmin tools are used, the requirement to limit the users choices (without moving from the sublime to the rediculous) in order to cut down on SysAdmin costs and workload is lessened.

I did roaming profiles a disservice when I mentioned (desktop's, fonts, color schemes etc.) in my earlier post. Under Win32. the "user's desktop" is more than just these trivia--although if your short-sighted not having access to your large font isn't trivial; nor lack of a high-contrast color scheme to the 10% of users that are red/green color-blind; nor visual 'audible warnings' for the deaf; swapped mouse-buttons for the left-handed etc.-- it is also everything s/he is able to see and do.

In essence, the users 'desktop' is the users computer; His or her 'virtual machine' to use a quiant old-fashioned phrase. The "shortcuts" available on my 'desktop' are the only applications I am able to run.

Whether the application a shortcut points to is locally or remotely installed doesn't matter, the fact that it (the shortcut) is installed on my desktop means I can use it. If it isn't, generally, I can't. Yes, it is possible to invoke programs manually via the filemunger/explorer, or even through the still-born CLP--assuming it hasn't been disabled--but in the Win32 sense, the desktop is more virtual than physical. More akin to a visual representation of the *nix .profile (and other .files).

So when I say 'desktop', I mean somewhat more than just the pretty bits.

Secondly, I also agree that there is a real need to restrict what gets installed and where, especially with the advent of easily accessible cracking tools and wide-spread exposure of the corporate network to downloads from the internet. However, forcing the user to use vi or notepad (or even worse, I've seen people using Word as a program editor!) when they have become accustomed to and dependant upon the features of X, because it make the SysAdmin function easier seems all wrong to me.

Can you imagine the caddy telling Jack Nicklaus (or Tiger Woods dependant upon your generation) that he can only use a sand-wedge for his golf cos it makes cleaning his kit so much easier. Or drawing analogy to the described use of Word, a 1-wood!

Or replacing the vehicle mechanics sets of straight-necked, cranked-necked, open-ended, flat-ring, shallow-offset-ring, deep-offset-ring, 6-point and twelve-point spanners(wrenches to most of you guys), short-reach and long-reach socket sets etc, with one two of these and one of these?

I guess what I am saying is that the SysAdmin role, often under resourced and under funded as it is, is the support role. Whilst, as one monk's wry tag line would have it, downtime is that time when systems have a 0% user errors, without the users the SysAdmin role has no purpose. That makes the users the customers and although I have never subscribed to the customer always being right, restricting the users productivity in the name of simplifying or reducing costs in the SysAdmin role is not good management nor good fiscal policy IM(NS)HO.

I'd be tempted to ask them how the Watchmakers dealt with:

• Left-handed watchmakers?

  Screwdrivers may be universally handed, but even such simple tools as hammers and mallets aquire a handedness with use. Each user holds the tool in a different way, strickes in a different way. Using another man's (well-used) hammer is pergatory if you are used to your own. So it is for a programmer's tools. They may start the same, but they aquire distinctive faces with use.

• Physically different watchmakers? Tall, short, big bellies etc.

  My roommate at one of my previous jobs always had his keyboard far enough back on his desk that he could have an a4 sheet or a book in front. He was tall and long armed and simply reached over to type (at great speed I will add). For me this was physically impossible unless I stood, and I am not that short.

Having worked at several places where the 'powers-that-be' spend immense amounts of time constraining "the users" ability to change anything (desktop's, fonts, color schemes etc.)

Even to the extent of forcing those with newer monitors capable of running in 1200x1024 or higher to using clunky 800x600 modes "because if we let you use the higher modes, everyone will want a new machine/screen".

Or removing the waste bin (and the ability to retreive accidently discarded files) from the local machine drives "because it doesn't work on network drives, and the inconsistancy would confuse the users".

All in all, I'd agree with you that these kind of 'one-size-fits-all' attempts at corporate bondage, serve no-one except the bean counters.

In the Win32 environment, one of the features that MS got right (IMO) is the roaming desktop facility. Sit down at any machine with the LAN (or even the WAN if its done correctly) and log on and lo- I get 'my desktop'. Colours, short-cuts etc.

I assume (but don't know) that something similar can be done using *nix .profiles etc.

My advice. Stand up for "viva la difference" if you have the status or the backing of your peers. And do it ASAP, because once these things take hold, undoing them is nigh impossible.

Clarification is needed here .. M$ stole the idea of a network environment from unix :-). In my experience, Unix does this much better. Most modern unices are ready to go on the network. Then you got X ... the client/server Gui Framework... nfs + nis+/LDAP etc == better roaming "profiles" than you can get by _default_ with windows. Considering aplications (console adn gui) can also be launced off of the network you can truely go from workstation to workstation and have all your tools available.

Personally I haven't been a "users" admin. Most of my roles have been supporting production systems running web systemsn and not supporting 1000's of developers. I have settup test labs, adn smaller workgroup centralized environments with NFS as well as callcenter/NOC setups. In these setups users had controll of thier systems, but all the "standard" tools were available. So if someone needed to use some other application they could, but if someone else logged in they had access to all the "standard" things they wanted. ( vim emacs etc.. ) When IT needed to update somthing it was done on one or 2 servers ( backup server ) and that was that.. .

On the flip side.. When I am not an admin and I got a workstation where i can't do what i need. I simply rebuild _MY_ desktop.. Typically with some free unix ...

think that's about $0.02 worth of MHO :-P

Sure, we use our tools. For instance, you are clearly a misguided vim heathen, whereas I program in the light of pure (X)Emacs. Even vi lovers are better than the wimps who "program" Perl using pico. Then there are tagging tools, cross-referencing tools, different modules for profiling, programs for printing code, ... Since we all have Too Much Time, we tweak our tools: syntax highlighting editors, macros, indentation styles, ...

So almost no two environments are alike.

But are we really each building our own tools? Not really. I didn't write my text editor. RMS did, but he still uses other tools he did not write. I pick and choose which Emacs Lisp extensions to add to my basic setup; I occasionally add some Emacs Lisp of my own, but I did not write my own editing environment. I suspect you did not, either.

The solution? Set things up so you can work from any station at your place of work. With centrally-installed Emacs, vi, compilers, perl, and a few other well-chosen components, you get access to your heart's desire (or at least to your less-hated tool).

But how to load your configuration? Usernames are a great help here (too)! When I log on as ariels, I can run Emacs and know it will read ~ariels/.emacs for configuration.

I believe in centrally-installed tools, but with an "open" administration policy: If I want some other tool, I stuff it in ~ariels/bin (or an architecture-dependent subdirectory for a binary). If two more people show an interest, I should be able to ask administration to install it centrally.

Everyone should use mostly centrally-provided tools, but with personal configurations. Woe to the person who forces an editor on me.

I can see some points to both sides of the argument. (For reference, "STS" where it appears below indicates the phrase "standard tool set," referring to a uniform set of tools on a system.)

Having an STS to work with makes it easier to set up new systems, handle updates, and troubleshoot issues. It also makes it easier for anyone to interchange machines (whether temporarily or on a more permanent basis), and having a standard configuration for those tools in the STS can make things such as applying a standard coding style easier, which in turn can make life easier for things such as CVS repositories. (Yes, I know about things like PerlTidy, just pointing out the logic.) In addition, having an STS means that a new person doesn't have to wonder where to get a tool to do (fill in blank) function.

The other side of the coin that I see is that many people, while competent enough to use other tools when necessary, have a set of tools that they are the most productive with. The ability to do function (fill in blank) in one tool may be something they use extensively, but may not be used by (or may even be missing) from a tool in the STS.

Having said that, the former view can lead some to assume that programs can be written in assembly-line, cookie-cutter fashion, while the latter view to the idea of the programmer as an aloof artist who slaps code on a phosphorescent canvas with a brush. While I think some engineering/scientific/mathematical principles can be useful in the development process, I still find it to often include just as much of artistry and craftsmanship.

The best compromise I see is to provide an STS (maybe even with more than one tool that does the same function, if there is enough desire for it, such as providing both vi and Emacs), but allow programmers to use other tools if it improves their productivity (I am ignoring such administrativia as licensing and such, for this discussion), and to allow suggestions and evaluations of other tools for inclusion in the STS, especially if the people having to use them do so for very different circumstances (such as someone writing *nix/perl code in a department with persons writing database queries or ASP/PHP/HTML).

...standardize on a coding style. It's not important for your co-workers to be able to work on your PC, but it is important for them to be able to work on your code.

Question: is it practical to let each programmer use their favourite (and obviously correct (as long as it's 1TBS ;-)) coding style, and let programs like indent and perltidy "standardize" the code when it gets checked in? That gives you fewer holy wars (bracing style, indent depth, tabs vs. spaces, etfc) but adds an extra layer of complexity. (You'd still have to standardize on things like naming conventions.) Has anyone tried this?

--
The hell with paco, vote for Erudil!
:wq

What follows is a true story. It may bring reminiscences for the older monks and might amuse a few of the younger ones. It may also serve to identify why I have strong feelings on the subject of this thread.

A few years ago I was working on a customers site coding in C. The company had a set of C coding standards, which whilst a perfectly reasonable thing to have and in this case a perfectly reasonable set of standards, they did not match my personal set of coding standards in various trivial ways. Open curly under the for or while not on the end, stuff like that.

Whilst its not the end of the world, I found myself perpetually having to go back and edit stuff that worked fine but didn't comply with the standard. This had a disastrous effect not just on my productivity but also on my mood.

The environment was OS/2 - and I was something of a guru. I had 'sneaked' a copy of my favorite editor (at that time an IBM 'Internal Use Only' editor called E3 that later became a commercial product called SlickEdit) which had its own built-in, c-like macro language. And I had in my personal armory a small shareware c-beautifier program which had options for reformatting to various conventions. So, like any good craftsman would, I adapted my tool to suit and added macros that used C-Beaut to convert to my preferred format on load and back to the house standard on save. Sorted.

A few days later I was taking my boss through some of my code on screen, and he commented that I wasn't using the house standards, so I showed him what I had done. He liked it.

He thought it significant enough that he asked me to show him how it was done, and that brought up the subject of licensing. I had paid ($35) for my copy of C-beaut, and whilst the editor was IBM IUO, it was also available for free, unsupported use to IBM customers so that was ok. So my boss asked me to write a short memo detailing the tools I used and how I had set them up to the corporate IT dept (actually still called EDP Dept.:), which I did. The idea that the tools would be officially sanctioned and made available internally.

A few weeks went by and I had forgotten about it, when a "report" landed on my desk with a (literal) thud bearing a pink "Needs urgent attention!" label attached. The report consisted of approximately 600 sheets of continuously printed, 132 column green-lined listing paper. (How many remember that stuff? Is it still used?) Each page was formatted identically.

There was the name of a program as the title.

A short description of what it did.

The author /supplier name and address.

License type:Freeware, shareware, commercial etc.

Test methodology:

"I installed the program. Loaded it up and tried it."

Test results:

"I input the file testnnn.c (available in \\server\path\to\testnnn.c) and it produced the file outnnn.c (\\server\path\to\outnnn.c)"

Conclusions:

"Seemed to work ok!".

Cutting a long story short, my original memo requesting the site licensing of C_Beaut had been brought up in a meeting of the EDP Dept "steering committee". The lowly SysAdmin guy to whom it had fallen to 'implement' the memo had been completely blown away by E3 (they still used SPF and wrote everything from their time sheets to annual reports using it and Bookmaster!). He had been brought in to give the "demonstration" having first coordinated the efforts that where involved in getting a PC (ps2 m80) running in the meeting room. It hadn't been done before so took some effort. This was the EDP dept.'s. own, private meeting room you understand. There had never been the need to put a PC in there before. They had a 3270g in one corner, but that got very little use during meetings.

As a result of the guys enthusiasm, the proposal was provisionally accepted, but the committee felt that if the C_Beaut was so good and useful. Maybe there were other, similarly small, cheap utilities available that could be used to set up a productive, standardised "development environment" for the "PC types".

So they commissioned a report. An external consultancy was paid (10,000 1988 UK£'s - a pretty good annual salary for a junior prog. back then! And yes. I said ANNUAL!), to produce the report. Four weeks work later and the thud on my desk was the result.

The young SysAdmin guy had moved on and no one else in the dept. wanted to sully themselves with reviewing 600 pages of 'PC stuff', so it had eventually found itself to my desk. My job was to 'approve the report'!

And so it goes.

A request for a simple, $35 productivity tool had chewed £10,000 of company money (not counting the thousands in salaries of those in the 3 committee meetings (never less than 30 people) that had been spent as a result of my original request.

The final kicker. The author of the program was contacted and asked how much he wanted for a site license for the program. He quoted something like a $1000 one off payment. That seemed ok and a purchase order was raised and sent to purchasing. The purchasing department contacted the 'supplier' with a standard contract for supply, complete with support requirements, response times, update licensing clauses etc.

The supplier wrote back saying that the program was supplied on an "as is" basis and no support was available.

The purchasing dept. wrote back saying that they could not accept these terms.

The guy wrote back saying "Bad luck! Those are the terms. Take it or leave it.

The purchasing dept wrote back again saying that the only way that could accept those T&C's was if the program was supplied with source, that the source be supplied free of any legal ties etc. Could the supplier please provide an updated quote for the supply of the program--"royalty free source inclusive"-- and reflecting the new pricing arrangement.

The guy replied with a 3 1/2" floppy disk (containing the executable with his copyright amended to include the companies name and a "joint and several" clause, 1 .h file (32 lines), 1 .c file (66 lines), a make file (4 lines)), and an invoice for $5000. 90 days later he was paid.

Oh! nearly a year later, I finally got irritated by C-Beaut's habit of leaving the last line of its output without a "\n", so I asked if (as we had the sources), it would be ok to fix it. After approval was sought, given, and I had provided a test plan for verifying the changes, the sources were sought so that I could 'implement the changes'. Alas, the sources could not be found.

They were eventually found. The floppy disk had been carefully filed along with the invoice and associated correspondence. Stapled to the purchase order!.

Using perltidy as a formatting standard is a good idea. You may have to standardize things like brace style, depending on how flexible your group is. That's much harder for people to adjust to though.

You should definitely standardize things like variable and method name capitalization.