... my company frowns on telecommuting, but it's small and informal enough that people do whatever they want to anyway. I program, and when I have to work on a large chunk of code and I don't need user input then I check the neccessary stuff out of the code repository and work at home.
Programming on a project at home does require that the project is set up so that programmers can check out source from CVS or VSS or whatever, compile, test and go. This requires attention to a few things:
1. A uniform, easily reproducible build environment. Choose industry standard tools (e.g. gcc/makefiles on *nix, Visual C++ on *doze); burn a CD in so that you can take a fresh laptop, install the OS, pop in the CD and have a working build environment.
2. The entire build environment must be stored in CVS. This includes, if possible, all dependent libraries and DLLs. When you check out your project you want it to compile straight away. To avoid bloat, modularize as much as possible, so that you don't have to check out all 300 MB of your co-worker's shit in order to get your own module compiled.
3. Choose standardized software. I'm not plugging any platform here, just giving an example: my company is a Microsoft shop, and we use Visual Studio, Win NT, MS Office and Exchange, MS SQL Server (for small and medium sized databases) and Oracle (for large databases). The languages are C++ for systems programming and Visual Basic for glue. We have a list of acceptable hardware. There are almost no exceptions allowed. The downside to this is that we rarely get to play with cool stuff, exotic languages, or personal favourites. The upside is that we can set up shop quickly and efficiently almost anywhere: at home, at work, and at clients.
4. Store test environments and test cases for each product. Include initialization SQL scripts and SQL scripts that create test databases quickly. Make sure the test cases match reality. There are few things more irritating than have someone code up the perfect program at home, only to have it barf all over the customer's data.
5. Agree on standards. This includes coding conventions, modularization conventions, libraries and language features. Teleworkers should be an integral part of the company, not hermits working on isolated projects at home. This however means that programmers should be able to understand and work with each others' code without difficulty, and realizing this neccessitates the use of fairly rigorous standards.
It is possible for a large number of workers in a software sweatshop to telecommute, if the basis is laid carefully. IMHO it can lead to much happier and more productive workers.