The Perfect IT Workplace - Revision 1

There should be a kitchen with a lot of food, hot and cold beverages, etc.

I don't necessarily agree that your workers should have spacious offices with doors that close, but they should still be comfortable enough. At one of my workplace, I constantly had to move to let other people out of their seats, and this was unbearable. So don't do that.

In one job that I fondly remember, every employee had their own spacious cube, with a desk to put a computer and a place to put a few chairs. This was much more like it.

This cannot stressed enough. As Joel Spolsky notes (based on Steve McConnell) in item No. 9 of the Joel Test, you need to "use the best tools that money can buy".

If you buy old, broken and/or barely functioning hardware, you'll spend a lot of time debugging the problems there, which will waste a lot of precious time. And you may lose a lot of reputation and customers due to down-time. Relying on reliable, high-end hardware is a much better idea.

I've been to two workplaces that gave me an old computer with a 40 GB hard-disk. It wasn't enough at all. At one place, we've reached the limit of this hard-disk due to several large source code checkouts, and as a result needed a bigger hard-disk. And the only hard-disks the lab had were 80 GB ones, which were bought because they were the cheapest (per-disk, not per-capacity). Please, buy large enough hard-disks.

At the same workplace, I was given a computer with a read-only CD-ROM drive. It was not even a DVD reader. I brought a DVD of audio files from home, and could not read it. In this day and age, read/write DVD drives are the standard, and are ultra-cheap.

Sometimes you'll need several computers, or a decent virtual machine emulator, to run alternative operating systems on the same machine.

Make sure your workers have a high-quality screen. They need to look at it most of the day, and they want it to look nice. A decent 19" LCD screen nowadays is very cheap nowadays and well worth the added productivity.

You also need a state-of-the-art version control system , of which there are currently several high-quality open-source alternatives. Some very costy version control systems have a bad reputation for being extreme troublemakers, while the modern open-source alternatives "just work".

If there's a good commercial software that your employees like to use and can recommend, don't hesitate to buy it. You'll also find O'Reilly Safari Licences to be a good idea so your employees can easily look up and read information in many books online.

Give your employees sane working hours - 40 hours work-weeks or less. While sometimes asking them to stay late to finish a deadline is acceptable, the so-called "crunch mode" is under-effective and a recipe for disaster.

Find a good place which is close enough for most people to get to. Make sure your programmers can commute to you easily. Even pay for taxi-cabs out of your own expense, or ask other employees to give them a ride, if there isn't good public transportation. The money you spend on the cabs is very small compared to the one you would lose by lost productivity, and by frustrations of travelling.

Give your workers a lot of paid vacation. Humans are not machines - they need rest and relaxation. The 14 annual vacation days mandated by the Israeli government are a joke. You should give them much more than that. Joel Spolsky's Fog Creek software gives 6 weeks of paid vacation, which is much more reasonable.

Some organisations put their intranets below firewalls that block access to almost all services. It is not uncommon to see only the HTTP and HTTPS ports open for free access.

However, there are many other Internet services that star programmers need in order to be productive. Among them are:

And naturally, malware can easily propagate and survive using HTTP and HTTPS alone, and there are ways that clueful workers can overcome such restrictions.

At one of my workplaces, I was able to chat on the IRC, connect using IM, ssh to everywhere I wanted, etc. without any restriction. It was a liberating feeling and I felt at home there. At a more recent one, I needed to connect to a remote host, and invoke port forwarding in order to talk on the IRC which was annoying and error prone.

So make sure your firewall is not over-zealous and does not prevent legitimate uses.

Competitive Salary? Yes, it's important, but not absolutely everything. Great programmers won't work for you for free, but they'll find many other conditions much more tempting than an over-blown salary. See what Eric Raymond wrote about it in "Homesteading the Noosphere", quoting many studies:

One final note: you might thing to yourself: "how can I afford all that?". Well, the answer is that the cost of all these advantages is very small in comparison to your general operation. And they will pay themselves much more as time goes by in the happiness, productivity and loyalty of your workers.

The last thing you want is to lose a competent developer. And all these things will better make sure that he or she will stay with you.

The first advice I can give is to write functional specs. In the link, Joel Spolsky explains the motivation and method of writing functional spec. A functional spec describes how the end-user will use and interact with the program. It is not a technical spec which explains how the inner software will work.

From my experience, functional specs are fun to write, reveal many problems in the initial design, and make you think how the software will work on the inside.

Here are three examples for functional specs I wrote:

You should write automated tests such as unit tests, integration tests, system tests, that will run automatically on the code and yield an answer if all of them are successful, or if any of them fail.

There are many good practices for automated testing such as having daily builds or reaching a 100% test coverage. Here are some resources to get you started:

Note that having automated tests is not a substitute for having dedicated software testers (and vice versa). By all means, they are both necessary for any serious operation.

Most people agree that designing a software, planning it and thinking about it is a good idea. Extreme Programming suggests to have one design meeting every day. I personally feel that too much design like that is equivalent to very little of it, but still design and planning should be done

Refactoring is the process of improving the internal quality of the code (from "a big mess" to "squeaky-clean and modular code"), while not changing its external behaviour. This is done for mostly functional and bug-free, but sub-optimally-written, code so it can be better managed.

"Joel on Software" features two excellent article about the motivation for refactoring: "Things You Should Never Do, Part I (why rewriting functional code from scratch is a bad idea)", and "Rub a dub dub" (how and why to do refactoring)..

There are many other resources for that online, along with many refactoring patterns.

There are many types of refactoring: grand refactoring sessions (= what Joel describes), continuous refactoring (refactoring as you go), "just-in-time refactoring" (refactoring enough to achieve a certain task), etc.

But refactoring is important, makes development faster in the long run (and even in the short-run), and can prevent the code from deteriorating into an ugly, non-functional mess that would be hard to salvage.

There are few software engineering methods that I find pointless, so I'd like to briefly point them out.

The first is the "Huge-design-up-front", where an "architect" or even the entire team spends a very long time writing an extremely comprehensive and detailed technical document that specifies in detail how the software will work.

The problem with this approach is that it is a huge waste of time and also it is impossible to design a large project top-down like that. A better way is to involve the entire team in a good design session (a week long at first) while writing some functional specs, diagrams and some other documents, and then to write it incrementally.

A similar fallacy is the "Mountains of documentation fallacy" of having superflous commenting, Literate programming, etc. The problem with this approach is that the extra documentation is often redundant if the code is well written and factored out ^{[Extract Method]}

Some documentation (especially API documentation such as Perl's POD or Doxygen) is good, and you shouldn't feel too guilty about writing a comment for an interesting trick, but too much documentation slows things down, and doesn't help with the design process, and eventually may turn out to be misleading or harmful.

Something else I consider a bad idea is Overengineering or YAGNI ("You Ain't Gonna Need It"). The basic idea is not to implement too many features at once, or over-complicate the design of the code, and instead focus on getting the necessary functionality working.

YAGNI, put aside, I still believe that some forward-planning is good.

The code-with-accompanied-documentation is somewhat a sub-case of a more general fallacy: the belief that a company can simultaneously maintain two different codebases (say two codebases implementing the same functionality in two different languages), while keeping them both synchronised.

The Extreme Programming experts have been warning against it, and it also makes sense that it is hard to do given that programmers, by nature, lack the appropriate discipline to keep maintaining two or more codebases at once.

One possible solution to this problem has been illustrated by Fog Creek software. What they did was implement a compiler from a common language, to several target languages. Naturally, this compiler also needs to be maintained and extended, but it is less work and less error-prone than maintaining several different codebases.

One huge advantage to a technology is that it will be open-source and available on several operating systems, including most Unixes and Windows 32-bit, and on many CPU architectures. While, often you'll encounter many platform-specific bugs or libraries or programs that work properly only on certain configurations (which is expected), you should still have the choice of being able to rely on the technology being present.

For example, Microsoft's Visual Basic was a closed-source and Windows 32-bit and x86 specific programming language, which had proven to be very popular. However, Microsoft decided to discontinue it completely, and as a result, many of the applications developed for it can no longer be maintained into the future, and important bugs in Visual Basic will not get fixed.

Eric Raymond's "Tale of J. Random Newbie" is illustrative of the many problems programmers encounter in highly-prorietary environments. Generally however, even if you're using proven, mature, well-documented and functional technology, you are likely to encounter bugs.

I like Perl a lot, and have recently found some bugs or even crashes in Perl code, which I've been trying to isolate and report. Perl is otherwise very good and reliable, but advanced users, or even intermediate ones are likely to discover many edge cases.

You should make sure you have the capability to isolate, report and possibly send a fix to such a technological problem, and get a prompt fix. This often depends on having good support from the technology vendor or developer.

Various technologies and development platforms, vary in their power and cost. As opposed to the possible mis-conception of "If you want something good, you'll have to pay more.", often cheaper, or even gratis (or open-source) solutions are more powerful (not to mention more reliable and faster) than their more costy counterparts.

Often, however, the really good solutions will be an overkill. Most experts I've talked with agreed that the Oracle Database is the most powerful on the market and "years ahead of anything else out there". However, most run-of-the-mill web applications won't make use of even a small percentage of its advanced features, enough to justify using it instead of, say, the open-source and gratis PostgreSQL.

For many problem domains, Oracle would make the most sense, but it's still not very useful in the general case.

It makes sense to choose a technology which you know very well, so you can overcome problems more quickly. However, smart programmers can learn different technologies very quickly. As Spolsky notes:

If you expect that you will hire the best developers, as I pointed earlier, then they should probably be able to pick up something new fairly quickly. If, on the other hand, you're going to hire bad programmers, then you're likely to be screwed - even if they have extensive experience with their native technology.

So you should choose the best technology - not the one for which you expect to find the most "experts".

Often a technology will get a bad reputation as being "quirky", "hard-to-get-right", "buggy", "unreliable", etc. This for example, has been the case against MySQL, against PHP, against Sendmail, and against other technologies. From my experience, such common criticisms often have a lot of substance for them and should be evaluated, especially if there are equally affordable technologies, but such of a better reputation.

I once been to a job interview in downtown Tel-Aviv, which went very well. Then I received a phone call from them that they want me to come and install Fedora Linux on the computer. I did that, and next thing I knew, I was given other tasks.

I was instructed to write a mail-processing framework in PHP. Now since I know and love Perl, I know there are many fine modules for doing that on CPAN (= The Comprensive Perl Archive Network), but there was little of subtantial quality for PHP. At a certain time I needed to register at a site, to download the latest version of a PHP library, that was free software, because the download required authentication. There didn't seem to be anything better.

I was told that they would prefer to write everything in PHP, because they expected to hire only PHP programmers, possibly without any Perl experience.

That wasn't all. They also decided against using Postfix, which is a modern, high-performance and open-source SMTP server, and instead prefered the old Sendmail SMTP server which has a far worse reputation, and an arcane configuration system.

Furthermore, they also decided to use MySQL instead of PostgreSQL, and we ran into a PHP misbehaviour (which was fixable given a lot of PHP know-how) that made us have to restart the connection to the server after every request. Both MySQL and Sendmail were chosen from political reasons.

With my PHP code barely working and prune to many errors, I decided to quit after about a month, out of being appaled by the bad code craftmanship I could do there. Make sure you don't repeat such a mistake.