But is it worth it? How do you weigh the time spent on optimizing storage against the cost of simply adding a few more HDs?
The answer: hourly cost of a developer in GBs of storage.
So let us calculate.
The average developer in the US makes more then $70K a year. He/she costs a lot more to the employer, mind you. Divide this by about 2000 work-hours per year and you get $35 an hour as a lower-bound for average developer cost per hour.
Now, what does storage cost? How much does 1TB of storage cost these days? Or more accurately, what's the marginal cost of adding another 1TB of storage to your company's network? Well, unfortunately the answer isn't so simple. It all depends on what types of storage you want, how secure it should be, how robust, and of course speed, latency, the type of network access, etc. For sure, the high-end storage solutions are expensive. Rediculously so. But my intuition tells me most teams can definitely settle with something saner.
So consider a rack-ready NAS solution that can hold 8 SATA drives and give you 1GBit ethernet. These start at about $1000. A single 1TB SATA drive is about $100 (though prices are dropping as I type this, and, no, wait, it's now $90). So if we want 8 of those the whole thing costs less than $2000, and with RAID-5 with 2 spares we would get 6 TB, so that's about $0.33 per GB.
Thus, assuming my napkin-math isn't seriously off, the average developer costs 105 GB per hour.
That's 1.75 GB per minute.
Keep this in mind the next time you decide to spend half a day worrying about keeping those "huge" debug symbol archives of the product's old versions, or about whether or not you should be backing up the entire DB as part of the release procedure.
Explain to your manager that the time it would take you to convince him to approve the purchase of more storage space probably costs more than the storage itself.
Save time, buy storage.
7 comments:
You forgot another part of the equation. You develop a product that has a user base of 25000 users. Your cost per GB just went from 1.75 gb/hour to 43750 GB per hour and if you are a growing firm, and you would be if you considered the need of your customers, that number would only grow.
I was referring more to optimizing storage as part of the ongoing R&D effort (as the examples I noted suggest) and less as part of the product's design.
Of course, you're right. If a product is wasteful of storage space customers would buy the alternatives.
Sorry, missed that part, but I do agree with giving the developers whatever tools they need to works as efficiently as possible. Every employee with our company has 2 monitors as an example. We have as much hard drive space as we need. Need more, just get more drives. Done!
Time spent in optimizing code for speed or size is a one time cost vs the long term savings that stays there until the code is updated or outdated.
Code optimization should always be factored in the development cycle. How long and rigorous it should be, is something for the project lead / manager to balance and decide.
Something tells me that some folks in redmond thought that it is ok to simply to let code size grow, and their code just kept bloating. But looking at the economics of software business, they are the one who currently own a huge chunk of the desktop OS market, though that is poised to change.
Balance and moderation. :)
There's also a cost to keeping all organized and working.
At some point someone will have to look at all those files and if there are less files to work with it will also be less work for that someone.
But as long as the files are in a consistent structure and not "spaghetti" it's not s big problem.
You forgot to include the cost to install the storage space.
Disk space scales much better than disk bandwidth.
I've worked with TB-scale map databases in the past. The hard part is not the disk, that's cheap. The only expensive thing is the IO bandwidth between disks. Even really fast disks are <80MB/s
Every time you decide to copy a terabyte, the disk bandwidth is a killer.
Post a Comment