How to solve the governments' budget crises, and design great code | Cypress Semiconductor
How to solve the governments' budget crises, and design great code
This WILL get to an embedded design topic, but permit me a few paragraphs to get to the point.
If you have been paying attention to the news, our national government and those of nearly every state is in budget crisis. Here are just a few glimpses of the crisis:
"Facing another fast-approaching deadline to avert a government shutdown"
None of this should be a surprise, especially if you've lived through more than one recession. When the economy is good, individuals and governments as well become much freer with their(?) money. Then the economy turns, the revenue (incoming taxes) slows down and voila! budget crisis. You and I know what we have to do when we have a personal budget crisis: spend less, get more efficient or borrow money from someone willing to lend (much easier before 2008).
So which of these does government typically choose? First borrow more (not always possible for some states due to their constitutions that require a balanced budget - they can only spend out as much as they are taking in) and if/when required, spend less. But if you and I were to spend less like the government does, we would start by cutting back on milk and bread while maintaining a steady-stream on-demand pay movies on hi-def digital cable.Why? Misplaced incentives.
"Human beings adjust their behavior based on the metrics by which they are evaluated." (a quote from HBR article by Dan Ariely: "You Are What You Measure." , NOTE, I have had trouble getting this site to load, but the link is correct). This means if you give someone an incentive, they will take it, and every measurement "scheme" you have is an incentive of some sort, though most not as you intended. Let's look at the well-known government budgeting practice called "Use it or Lose it". This technique encourages a program or department facing a budget surplus late in the fiscal 4th quarter (August) to spend every penny as fast as possible.
Actually, there are many, many organizations who can help you get a piece of this action, like TargetGov.com with their helpful tips like:
"End of the Fiscal Year, Big Government Spending"
. The actual tagline for this site is "Helping you sell what government buys". Here is the intro to the referenced article: "We are now entering the fourth quarter of the federal fiscal year. The federal government spends nearly 60 percent of the year’s budget at this time because of “use it or lose it” requirements." It goes on to provide tips to get "your share" of this spending free-for-all. I cannot vouch for that statistic personally, but if true is shocking. No wonder it's hard to make government better, if that is accurate. Of course, it must be, I found it on the internet :-)
So when it comes to a budget crisis, and planners are facing a large shortfall, if you and your efficient department are showing year after year more results with less proportional spending, guess what happens when the money is short - the team that is NOT bursting their budget certainly doesn't need more when compared to a program that year after year can't seem to even get the same results with more money. Repeat this year after year and you can be sure to find over-budgeting (to be able to handle necessary cuts one day) and frivolous depletion of surpluses.
So how to fix the budget crisis (crises)? Incentives, but ones that reward efficiency, backed up by actions. It is obvious the "use it or lose it" budget incentives are NOT doing anything for efficiency.
OK, now that's settled, let's see how the same logic applies to designing embedded systems. Well, just like government budgets, you can easily incentivize the wrong behavior in your project. For instance, think what happens when you measure the quality of a software product simply by the number of defects reported against it. Under such a system, what would you expect a developer is to do when he/she finds a minor bug: report it or perhaps spend time trying to figure out how to ignore it with a clear conscience. "It might just be a corner case", or "perhaps no one else will find it" or "maybe the root cause is someone else's code". Besides, accurately logging a bug and detailing the steps to reproduce it takes real time to do right, and in the end it only adds a black mark to your product.
So if you have a "defect" crisis in your project, look at the incentives and the forecasted results, the "gaming the system" results like the example shown in this article on the "Defect Black Market" that developed in one project. But look also at the less obvious incentives, starting with the behaviors you find common that are not what you want (you may even find a "friendly" on the inside to provide clues).
Or like the government, just take the list of defects (or other measure) and just cut (or dictate a cut of) 33% off the top. Crisis fixed.
Methods and Madness, March 14, 2011
Happy 17th Birthday Linux (version 1.0.0 was released, with 176,250 lines of code on 14 March 1994. Go Linus and the open sourcers!)