I was struck recently by how rarely software developers and project managers really analyze software development expenses.
Ever been part of a discussion about purchasing a third party library? Ever considered whether to automate a particular task? How often have you or anyone involved estimated how much money the library purchase or automation would save in comparison to the needed developer time?
I’ve seen managers reject purchasing a library because “it costs too much” though the developer time needed to implement those same features from scratch would cost five times what the library does. I’ve also seen developers automate a repetitive task that is far cheaper to perform manually from time to time than it is to write the script to automate that task.
I suspect this disconnect is related to the nature of the jobs. Most programmers rarely if ever deal with finance and budget in any meaningful way. Most managers rarely if ever actually code. Consequently, neither programmer nor manager is exposed to the full range of concerns that would naturally motivate financially informed decision making. I wouldn’t be surprised if the love of programming (or pride) drives many developers to create unnecessary automation or take on building functionality that a commercial library could better provide.
As a matter of professional development I believe it’s a developer’s responsibility to become proficient at analyzing the costs of software decision making. Providing sound financial analysis to a customer or manager is essential to doing the best possible work. Anything less is waste. Remember that your time costs someone money; if you cost too much you may not have a job for long.
The math needed to make financially informed development decisions is simple.
Tools. Before automating a task or creating a tool to help you do your job estimate how much time you or your team spend performing the task you wish to automate. Then estimate how much time it will take you to develop the tool or script. If you don’t have good historical data to base your development time estimate on, just take an informed guess and double it. Will the tool save significantly more developer time than that necessary to create it? Unless more difficult to quantify issues exist (e.g. maintainability, documentation needs, policy adherence, an acceptable opportunity cost to learn a new technology, etc.) it may be, in fact, cost-prohibitive to develop that tool or script.
Libraries. Take your approximate hourly wage and double it. To account for overhead like benefits, facilities, the costs of securing new work, etc. a multiplier of two is a good approximation of your total hourly cost. Estimate the time you need to implement the features a library could provide. Again, if you don’t have historical data to draw on, use a best guess and multiply by at least 2.5 (production code generally requires more effort than creating scripts or tools). Multiply the estimated hours by your hourly cost. The comparison of the costs should be obvious. In some circumstances the library may provide desirable features beyond those absolutely needed. In these situations a conversation among your team and client or project manager is in order; having financial numbers to drive a conversation about “value” is itself a valuable thing.
Go forth and multiply.