Why your company should buy you a new dev machine today
When you go to work and write code, you have one main tool that you use – your dev machine. The power of your machine will partially determine how fast you can get things done.
How often does your company buy you a new machine? Every 2 years? Every 3 years?
I don’t know many companies where developers get new machines every 2 years or less. I’m here to show you why waiting longer than this makes no sense.
It makes no sense because hardware is cheap, but developers are expensive. I’m currently on a project where I’m working on dev machines that were purchased in early 2008. I’ve worked on other projects with machines that were 6 months old that were considerably faster.
On my project, it takes about 45 seconds to compile the solution. But what if I could reduce that to 40 seconds per compile by buying a brand new top-of-the-line machine?
Let’s say that I compile every 5 minutes. So in an 8 hour day, I compile 96 times. Each day, I will save 480 seconds, or 8 minutes. If I work 1900 hours in a year (which equates to about 11 months of work days since most people have about one month of work days in PTO), I will save 1900 minutes, or 31.6 hours.
Let’s say that the average developer on your team makes $75,000 a year. If that were the case and you worked 1900 hours, you are making $39.47/hr. This means that if you save 31.6 hours of this developer’s time, you are essentially saving $1250 over the course of the year.
For $1250, I can buy a pretty good dev machine, especially if I don’t buy monitors to go with it and use existing monitors. I think I used pretty conservative numbers here too:
- I think I could probably cut compile time by more than 5 seconds by replacing a 2-year-old machine with a new one.
- I probably compile more than every 5 minutes (especially when I’m making failing tests pass or making little changes in the app and running the app to see if it worked).
- I only looked at compile time — I didn’t look at how long it takes for a machine to run tests, how long it takes to run long-running database queries, or how long it takes for your app to start up.
- I didn’t account for the productivity hit developers take because they switch their focus on to something else for 45 seconds while they wait for the solution to compile.
- Some developers make more than $75,000, and if you’re dealing with consultants, you have higher hourly rates.
- Many developers work more than 1900 hours a year.
- I didn’t take into account the feeling your developers get when you reward them with shiny new hardware, which will make them feel like you really care about them.
Even with my conservative estimates, I would say it is definitely worth it to buy new machines at least every 2 years. You might even be able to argue that you should buy machines every year. You would have to do the math and see if it’s worth it.
Convincing IT managers to go for this is difficult for some reason, even when you show them the numbers. So many IT managers will tell you that spending is frozen, or that they don’t have money in the budget for hardware, or that it’s not fair to buy the dev team new machines but not buy <insert team that doesn’t really need it> new machines. Are you serious? You would rather have your developers, who are expensive relative to the cost of hardware, have to sit and wait longer for the solution to compile? This is short-sighted thinking. You’re pretty much guaranteed some level of return on that investment within a year.
If you’re going to hold your developers to a high standard, empower them to meet these expectations and make sure that you’re giving them the best tools available.
I agree with your premise that it is penny wise and dollar foolish. But, maybe we should take a hint from the mechanics out there and buy our own tools. You fashion yourself a craftsman, then act like one and buy yourself a laptop that you can take from client to client, employer to employer.
Great comment Todd! I came here from Twitter to post the same thing, you think I could drive the virtual Snap-On truck to all the development shops? My father-in-law drove the Lancaster, Ohio snap-on route for 35+ years, and just recently retired.
I totally believe devs and arch should be buying their own tools. And if there are any IT app dev Managers out there that aren’t also devs/archs, find a new career, please. If you haven’t written coded or debugged in the past 3-6 months what value do you bring? Please all IT app dev Managers sit down for some paired programming within the week.
Sorry for the soap box rant.
In some industries, the computers, networks, tools and everything else is heavily regulated by the government, ie. defense contractors. You can’t even move a mouse to another machine without permission. You can’t bring *any* software, flash drives, cds, cellphones or the like into a classified environment. Win2k and scroll-wheel mice are the standard, unfortunately.
If the developer were in charge of buying and maintaining their own software and machines, would the developer be paid more to reflect the lowered costs to the company? I’d hope so.
@Pete – On large projects, functional managers are there to manage costs, schedules, write proposals, etc. Technical leads are the ones who keep up to speed with the actual source code.
I’m currently on a project for the state of Ohio and they won’t allow any other hardware on their network. They also don’t allow remote access or copying source files to or from their machines.
I’ve got one of the most kick-ass laptops available collecting dust because I can’t use it on the project.
@Matt,
So dumb! If I were on a project like that, I would be willing to let them install an OS on a VM that can connect to their domain and be locked down however they want it to be locked down. But I’m sure they wouldn’t go for that either.
We are trying to make the same argument for new machines here. The response from management was “why are you building so much? Just build less often.” I posed this question the Stack Overflow community:
http://stackoverflow.com/questions/1229611/explaining-software-development-to-management