Code In Review

Matt Asay posed a suggestion today on CNet.com that our healthcare problems here in the US could be solved by “Open Source”.  He points out that the current information architecture is designed to handle the needs of the insurance and collection agencies, not the doctors and patients.  Essentially, the systems handle billing, not patient care.

So the solution is easy, right?  Have the open source community create a system for free that handles the patient data for the doctors, efficiency improves and everyone wins!

Trust me, if the solution were that easy, it would have been done already.  There are a number of movements to digitize patient records and test results and otherwise bring the medical profession into the digital age, but still, as was pointed out in the article, only 34% of these records are transmitted electronically.

To give you an idea of a common problem, suppose that a hospital created a digital records system that would allow patient data, test results, care instructions and anything else you might need to be stored electronically.  A doctor goes to see a patient and takes his patient history and symptoms, discusses treatment and care and decides which tests to order. 

• How does she enter this data into the system? 
• Does the room have a computer in it? 
• If it does, how is it secured against patient/visitor access for those long periods of time when the patient is alone in the  room? 
• If it is secured, how is authentication done so that if there is an emergency other doctors/nurses can quickly pull up the patient’s data.
• If there is not a computer, is the doctor expected to take notes and then enter it into the system later?
• Does the doctor enter the notes or are they transcribed by someone else, or automatically scanned?
• If the doctor doesn’t enter the notes, how is accuracy handled and verified?  A mistake in transcribing a dosage could kill someone.
• How do you handle down-time?
• Who controls access to the data?
• Can the patient deny the doctor access to certain “sensitive” data?
• Can an insurance provider see the data?
• How do you verify the patient data against the actual patient?

Answer these questions and you begin to have a solution (and it is only a beginning, I make no claim to even understand the full context of the issue)., but nowhere in these questions is there a problem with proprietary solutions.  Doctors and nurses don’t care if the source code is available.  They just want it to work with them, not against them.  Open source in software is simply a non-issue.  Smart folks are out there working on the real problems right now, and they are making progress.  Let’s not confuse the issue by demanding they release the source code under a belief that if we simply make the software open, it will solve everything. 

How do you decide when its time to change projects, companies, jobs?  How do you decide to move from software development to management or back again?  I have one simple test – persistent boredom.

After much experience I have learned that persistent boredom is the single best predictor that it is time for a change.  The problem is that boredom can be comfortable.  Boredom is predictable.  It can be relied on in a crisis, and it keeps the paychecks coming in.  But boredom forces you to remain still. 

If you seek out new experiences and new opportunities, you cannot be bored.  If you are not stretching yourself or your abilities you are not growing, you are not moving.  In essence you become bored.  Most problems with a job seem to stem from this boredom.

A bit of boredom is natural.  We all have lulls where things aren’t as exciting as they could be.  I tend to have a hard-time with the post-release lull where everyone coasts for a few days while we re-engage with our customer about the next release.  But that is a temporary boredom, and during that time I am actively working to alleviate it.  The boredom I am talking about is a persistent state.  When I enter into that prolonged apathy, I know it is time for a change.

Most developers I know have wondered what it would take for them to “cut the ties” and go out on their own, but inevitably are ill-prepared to deal with the change.  The biggest problem most of them have is calculating their costs.  Too often they charge rates that are simply a patchwork of guesses and hopeful wishing that they are competitive.  They can’t understand why they aren’t making as much money as they should be.

So how exactly should you calculate your rates?

If you just want a ballpark figure, a rule of thumb to get you started would be to take your take-home pay rate and multiply it by 2.5.  Calculating your take-home pay rate is simple:

PayRate = DesiredAnnualSalary / PaidHoursPerYear

How many paid hours are there in a year?  If you assume a standard 52 week year with a 40 hour work week you get a total of 2080 hours (more or less – it is actually missing a day or two depending on the year, but its good enough). 

PaidHoursPerYear = 2080 hrs/yr

So a good estimate of your hourly-rate would be:

BallparkHourlyRate = PayRate*2.5

Using these two calculations, if you wanted to make $60k/yr, you would have a pay-rate of $28.84/hour, and an hourly rate of roughly $72.10/hr.

Of course, that rate is only useful as an estimate.  What you really need to do is calculate a rate based on your own circumstances.  To do that, you need to account for much more.

Calculating Hours

The first thing we need to change is the number of hours in a year.  When you determine your pay-rate you include all of your paid time-off.  When you calculate your hourly rate, you do not.  This means that we need to remove all the vacation and holiday time from our hours in a year. 

WorkingHours = PaidHours – VacationHours – HolidayHours

If you assume a 10 holiday year and 4 weeks of vacation, you would get the following number of working hours per year:

WorkingHours = 2080 hrs/yr – 80 hours – 160 hours = 1840 hrs/year

However, not everything you do during a day is “billable”, which is the number we really need.  So our final calculation reduces the number of working hours by the amount of time spent on “overhead” – tasks that cannot be billed but are still necessary:

BillableHours = WorkingHours – OverheadTime

Overhead time can range anywhere from 20% to 50% of the time.  I usually use a 25% overhead rate.

OverheadTime = .25 * WorkingHours

Calculating Salary Costs

Now that we know how many hours we can bill for in a year, we need to determine how much total money we need to make to cover all our costs.  Of course, our major cost will be our salary.  We will also be responsible for the employer portion of Social Security taxes and Medicare, along with any state taxes (for simplicity, we will combine these into a single number).  We should also include any retirement benefits we may have to pay, and the cost of insurance:

AnnualSalaryCosts = DesiredAnnualSalary + EmployerTaxes + RetirementBenefit + EmployerInsuranceCost

Currently, Medicare costs 1.45% of the salary and Social Security costs 6.2% of the salary (Social security has an income cap, but I am ignoring the cap to keep it simple).  State taxes will depend on your state, so I am going to ignore them:

EmployerTaxes = .0145 * DesiredAnnualSalary+ .062*DesiredAnnualSalary

Insurance costs can vary greatly, so I am just going to use a rule of thumb that says it will be about 25% of the annual salary:

EmployerInsuranceCost = .25 * DesiredAnnualSalary

Finally, we can use a fairly standard 6% matching program as our retirement benefit:

RetirementBenefit = .06 * DesiredAnnualSalary

If we combine all these different numbers and assumption, we get the following equation:

AnnualSalaryCosts = 1.3271 * DesiredAnnualSalary

Calculating Total Cost

You may have noticed that the multiplier used to calculate the salary costs is a little over half the multiplier we used to create our ballpark estimate.  So what else do we need to account for to determine our total costs?

There are 3 major areas left to consider.  The first is equipment.  This means computers, software licenses, etc.  The second is facilities.  This means the cost of renting an office, keeping the lights on, the water running, and the internet surfing.   The final major component is the profit.  This is the money that goes back into the company to build and expand it and keep it running.  Adding these final items into our cost calculation gives us the following:

AnnualCost = AnnualSalaryCosts + AnnualEquipmentCost + AnnualFacilityCost

TotalAnnualCost = AnnualCost + Profit

Profit is usually some percentage of the annual cost.  A modest profit would be 10%, but a 20% profit is not unreasonable.  For a single person, the facility costs can run from about $500 a month up to as much as $1000 or more.  The equipment costs will obviously vary depending on your needs, but I usually assume about $3000 a year.  That covers a new computer every few years and license costs for any needed software.

Calculating the Hourly Rate

Now that we know what our total costs are, and how many billable hours we have, we can calculate a much more accurate hourly rate:

HourlyRate = TotalAnnualCost/BillableHours

Using our example salary of $60K/yr and the assumptions  list above (with a $500 monthly office cost), we can calculate our actual hourly rate to be

HourlyRate = 101409 / 1472 = $68.89/hr

Of course, I would round that number up to a nice and even $70/hr and use that as a basis for all my calculations.  If I needed to know how much I should bid for some project, I would first estimate what I need to do and how long it will take me, then multiply that by my hourly rate.  If I was making a commercial piece of software, I would use that development cost to help guide how I set its price.  If I combine that information with sales forecasts, i can get an idea of whether I will even be able to break even on the project.

Knowing your true hourly rate is essential to determining how to price yourself and your skills.  Even if you are working for a company it is worthwhile to calculate it simply to have an idea of what your time is actually worth.  Plus you’ll know how much to ask for the next time a friend calls up asking for technical support.