Should a software developer get a yearly equipment budget?
Definitely a nice to have and something I would bring up for discussion or even as part of your bargaining chips for salary negotiation. The question is more about whether it's a "should" or a "must".
Does anyone know if the industry has such a standard to offer an allowance or budget?
Unfortunately the industry definitely doesn't have it as a standard practice, but thankfully some companies are a bit less greedy and more in touch with their developers' (and employees' at large) needs.
This is going to be a rather broad answer, and by budget I don't make a distinction between a budget given to you to buy or place an order, or as something transparent where you request an upgrade managed by your company's staff. In their books, it's all the same thing anyways.
It's Handy
The problem is that this can obviously quickly represent a huge budget for a company, if it reaches a certain critical mass. However, I'd agree with you and Joel that it can be well worth it.
There's absolutely no point in frustrating employees.
Don't Get Spoiled
That being said, you also need to keep employees in line and make them realize that sometimes bad performance or slightly out-dated hardware is just a fact of life. You don't want everybody to turn into spoiled kids who want a new SSD, the latest iN processor, the extra GB of ram, etc...
I don't want people to obsess over eternal youth, and that applies to hardware as well.
(With software projects, however, I tend to push for staying as close to the latest release as possible... Analogies don't always hold :))
Specific Needs for Specific Hardware
I think there's a distinction to be made between:
- the basic equipment that is definitely required for your job when you start,
- and the more advanced equipment where the need stems from specific requirements.
Base Package
For instance, the following are pretty standard things you'd be entitled to expect, and for which I don't see a (strong) need for special orders:
- a laptop + cellphone (if you are an on-site consultant),
- a workstation if you work off-site and stay at the mothership,
- plus maybe a few non-controversial goodies like:
- decent input devices (keyboard, mouse, maybe trackballs...)
- decent chair.
These can be the same for the whole company, except for special cases like employees with disabilities. Employees with disabilities or injuries should obviously be accommodated.
Bonuses
Then if obviously you'll need to do lots of videoconferencing and presentations, you might want a few gadgets like bluetooth thingies, tablets and styluses. Which can actually be shared across departments by using a reservation system, to not end up with everybody requesting some (and losing them), while cutting down on the room for whining.
If you are a designer, you'll need your drawing tablet, your trackball, etc... I do every once in a while see the one developer who begs for a trackball instead of a mouse. Personally I've tried both, and I see both as almost equally identical, so I never really bought into this claim, if you don't have a specific need for it other than "I like it better". You can live with a mouse instead of a trackball without developing an RSI within 8 hours if you don't already have issues and have correct usage habits. It's a different issue when you get a crappy mouse or trackball or keyboard, but I don't see a clear win for one or the other.
If you are a developer needing to run 4 application servers simultaneously, building projects, and keeping 3 instances of Eclipse or Visual Studio open at all times, you'll obviously need a rather competitive workstation. I'd consider this "basic needs" for developers, so it doesn't mean the marketing dudes necessarily need to be aligned on that.
Build Your Case: Hard-Data For the Win
From experience, most companies are understanding with regard to your needs if you can prove that they are legitimate. If you can defend the rationale for it, they'll cough up the money or try to accommodate you. They're paying you to work, so they really don't want you to be wasting time.
(That is, if they care one bit about your job... if you're irrelevant, I'm afraid you're out of luck there...)
Show the Gain for You
So, in the past, my coworkers and I did get upgrades for RAM, input devices, chairs, hard-drives and whole workstations or even server farms based on clearly collected and outlined requirements. It does take a bit of your time to build your case, so discuss it first with your line manager, but it will probably be fine. Or spend the extra hours one week at the office to build the case, it can be worth it and your line manager will trust you more with such decisions in the future.
Show the Gain for Them (Money is the root of all evil...)
With regard to the above example, we did for instance calculate build-times and the reduction we could get, and did comparisons between the different setups present at the company, calculating the average of wasted time per developer per day, and then making them realize that it was equivalent over a year to about 20 full days per person of being unable to do anything (as the computer would basically be unresponsive if you didn't have a least a quad-core and 8GB of RAM for this build). Times the number of developers, that's a hefty amount of hours they pay people to stick around doing nothing, which was way higher than upgrading at least some of the stations.
More recently, a co-worker has been doing a similar evaluation to persuade them to consider SSD drives, and is in the process of collecting really fine-grained data on how much time would be saved for every body, in a similar fashion.
For health-related queries, a simple recommendation from your doctor, even informal, might be enough.
For custom software, you may just need to present the advantages of the tool and its impacts when integrated into your process. For instance, I managed to get my last 3 companies to purchase licenses for wireframing tools after using a demo version for a presentation to grab their interest, and then using them more extensively in one or two short-lived projects involving a few people. These were rather cheap, but originally they didn't want to buy the licenses without seeing the need. When they realized it clearly helped to visualize prototypes and make educated decisions earlier, they gave the green light quickly.
Plan
- Define an upgrade plan.
- Define benchmarks and metrics to use for measuring the gain.
- Provide clear results.
- Draw conclusions on these results.
- Maybe do some initial legwork on cost- and savings-calculations (discuss with line manager as well, or do this in a second review of your proposal).
- Get coworkers to sign off on your request, possibly with each writing a statement about how they feel about the update, be it positive or negative (the point is not to make a completely biased marketing speech to extort something from your company, it's also to really research this and see if it's really needed).
A Quick Note on Large Upgrades for a Whole Team
Suggest rolling releases if you request upgrades for a whole team:
- it distributes the cost over a longer period,
- it gives time to iron out transitional issues ("whoops, just realizing that this CPU combined with this OS version actually presents issues when cross-compiling our product X for other platform X"),
- it prevents the whole team from being stuck in IT maintenance hell with system reinstallation, system updates and the usual clean slate issues, or the occasional mishaps’ ("whoops, deleted that important backup...").
Admit Defeat: It Doesn’t Always Work For Everything...
And rightly so. Not everything is acceptable. And things that are acceptable may be out of reach for your company. Build your case, bring it to the line manager, discuss it over a team lunch or something more friendly and team-spirited than in the heat of this year's financial review.
Also, if you have a hard time building your case:
- admit you probably don't need it,
- admit you probably were wrong and upgrade X doesn't buy you what you thought it would.
If you can't build a case and start being defensive about your request, it means you'd be better off doing something else.
