Fog Creek Software
Discussion Board




Is faster hardware cost effective?

At my company we're working with a very large codebase. Some of our developer machines are older dual-PII machines like P400 or P500. Developers seem annoyed when working on these machines.

Does anyone know of any articles with justification for purchasing faster machines? Or articles debunking the need for faster machines?

It seems to me that faster machines let developers compile and run software faster. This helps them work faster with less  downtime when they are feeling productive. I figure most developers are only productive 4-6 hours a day (on a good day) anyway - so you need to get people the right tools to do their job before they burnout and want to go home.

What do other people think?

NathanJ
Wednesday, October 16, 2002

I once helped convince our manager to spend a few bucks on RAM and better processors to speed up our build process. It's pretty easy to break own usually - Ok so RAM was about $300 for 512 MB top of the line DDR (rough estimate from the time) and a new Processor was around $250 (not top of the line but faster). Our clean build time was 10 mins from start to finish. If I did a clean build only 10 times per day that works out to 100 mins wasted while I read a mag, walked around, scratched my ..., etc. Now multiply 100 mins X 5 days a week. Starting to add up huh? Now multiply that times your team size and you get the picture. Our time isnt cheap, but computers are.

Break down your costs and I'm sure you can show the higher ups that computers are cheap and humans are not. Updated development machines can help cut costs in the long run when done right.

Ian Stallings
Wednesday, October 16, 2002

Oh, a faster build time also helps you stay in the zone, which can be invaluable. Kind of hard to quantify that to a manager but it's still worth mentioning.

Ian Stallings
Wednesday, October 16, 2002

And don't forget some of the non-developers that may also be on the team. Some of the visual design folks may need better hardware to run some of the high-end graphics tools they need.

Some of the other folks may need more ram so they can open and edit some large documentation files without their machines crapping out on them.

I know this group is developer-centric, but you may be able to get additional "ammunition" for upgrading from people other than just the developers. There are other people in the world, and their time has value also; it's not all just about compile speed.

anonQAguy
Wednesday, October 16, 2002

Just don't get rid of all of the older machines, unless you're no longer targeting them at all.

Developers who work with fast machines exclusively sometimes don't realize how long operations can take on slower machines. Sometimes, shipping software has had to be recalled or upgraded because the developers never saw how slow it was on the hardware their customers used.

Of course, it can work the other way, too. I remember (way too many years ago) dealing with a remote serial debugger that had a command-line option to slow down serial communications for boards that couldn't keep up with a full-bandwidth stream of characters. I had no problems with it, but I was using a 10MHz XT for development at the time. The company that wrote the debugger had to modify it, because someone using an AT found out that the command-line option just invoked a delay loop, and the AT was too fast for the loop to work.

Steve Wheeler
Wednesday, October 16, 2002

Steve makes a very good point.

Recently, we shipped a game and exactly this kind of situation had occurred. We had to determine the minimum hardware configuration required and ensure playability was OK on the stated target. Nobody of course developed on the stated minimum requirement.

In our case, the realistic minimum development environment was much heftier than what it took to run the finished game.

So when the time came we had to find old, slow machines. We even had to buy an old used machine to meet one of our particular platform requirements because we had not retained such old/slow machines.

It's off-topic, but the same principle applies to older software versions, especially operating systems. So far (thank heavens), we haven't had to do anything on ms windows 3x/DOS (yech), but we routinely have to go back to windows 95(also yech). Don't be too quick to get rid of the old crap unless your entire organization is on board with what you will/won't support anymore.

anonQAguy
Wednesday, October 16, 2002

I am certain that it was brought up in at least 1 of the big 3 books brought up here: mythical man-month, peopleware, and code complete.  Probably all 3.

Tj
Wednesday, October 16, 2002

And another justification for keeping your old machines is that companies are coming out with all sorts of distributed build frontends to compilers.  Also, people may use the old machines so that they're not multitasking while waiting bored for the build.

I was about to suggest checking what the bottleneck with the builds is, but machines are getting really cheap in the US...  upgrading might be a waste of time.

Tj
Wednesday, October 16, 2002

old machines are also good for running back end stuff older DBMS versions (I used to work on reporting software), Older ldap servers, older app servers. Also browser different versions can be put on older machines (if you do web dev)

Daniel Shchyokin
Wednesday, October 16, 2002

Developer turnover is expensive - in the extreme.  If buying someone a "cool" machine makes them feel valued and important, it's often a bargain on that aspect alone.  A nice machine is what, $1,000?  Turning over a key programmer costs, what, $50,000?

My experience is that older developers often don't care; they'd almost rather the money was spent on salaries.  Younger coders brag to friends about this kind of stuff.  Ever heard "yeah, come work at my company; we just got 19" flat panels!"?  Want to absolutely thrill this kind of employee?  Say "here's $1,000, go build whatever machine you want".  Sure, your IT people will hate you, but you'll have a loyal dog for a long time.

Mind boggling to me is the company that won't spend $400 on a grid control and instead develops one in-house.  Things like that make me wonder how the earth keeps spinning...

Bill Carlson
Wednesday, October 16, 2002

"Mind boggling to me is the company that won't spend $400 on a grid control and instead develops one in-house. Things like that make me wonder how the earth keeps spinning..."

No kidding, Bill. But as a QA Manager who's spent years trying to get one organization after another to do the 'right' thing -- because it's what ** works ** and it's what's cheaper in the long run, I continue to be amazed at the short-sightedness I encounter.

Whoever once said "penny-wise, pound-foolish" certainly nailed it. So did you.

anonQAguy
Thursday, October 17, 2002

[There are other people in the world, and their time has value also; it's not all just about compile speed. ]

I never said your time was not valuable just because you are a low life photoshop goon who's only function is to shine terds and suck money out of the budget while working on your 22 inch viewsonic flat panel while I work on my green CRT mainframe client you bastard! Just kidding ;-). What I meant was computers are cheap when compared to human costs in general, I just compile time as one example. Another example might be time spent batching photoshop filters.

[Developers who work with fast machines exclusively sometimes don't realize how long operations can take on slower machines]

Which is exactly why I love building server based applications. It's were the big iron and muscle is. I always take into account slow connections but as far as raw power my dev machine usually pales in comparison to the target application host.

Ian Stallings
Thursday, October 17, 2002

Upgrading hardware is a good idea, in most cases.  Just break down the cost of the new computers compared to how much your developers are paid.  If the new hardware costs less than the time your people waste waiting for builds, it is a no brainer.  If not, you need to take into consideration less tangible benefits like not losing concentration, keeping your employees happy, etc.

Similarly, spending money on getting software that will result in higher productivity (better debuggers, editors, etc) is also generally a good idea.

As someone mentioned before though, keep those slower computers around if that is your target market.  You want to make sure your product runs well on the level of machines that you are selling to.

Mike McNertney
Thursday, October 17, 2002

>>> My experience is that older developers often don't care; they'd almost rather the money was spent on salaries.  Younger coders brag to friends about this kind of stuff.  Ever heard "yeah, come work at my company; we just got 19" flat panels!"? <<<

I might qualify as one of those older developers.  Been at it for a couple of decades, but now am using C++ instead of MAD and FORTRAN IV.

No, I wouldn't rather the money get spent on salaries.  I'm not getting six figures, but close enough.  But the 19" flat panels don't impress me either.  What does impress me is having an office where I can get some work done. Would those young coders brag to their friends "Come to work at my company.  You get an office with a desk and it's quiet."  But that would add maybe 2% to the cost of a coder, so it's not likely to happen.

We just had 4 experienced developers cut from our staff.  There is the same amount of work to do, but management needed to "cut costs".

mackinac
Friday, October 18, 2002

I often use VMWare to simulate slower machines. Since I figure running a system in VMWare is about 25-40% the speed of running on an actual computer, it usually works out well. Also, the ability to setup multiple OS setups and run all at once is always handy too (I hate rebooting just to change the active OS).

Sanjay Sheth
Saturday, October 19, 2002

*  Recent Topics

*  Fog Creek Home