But, in the US at least, ONLY if you are a fully protected wage slave. If you are instead a contractor/consultant type and personal, property, or capital damage is possible you either do what is right or you walk away from the contract. Wage slaves are shielded from prosecution except in certain cases of extremely egregious misconduct, but as a contractor/consultant there is no such shield regardless of any contract between the client and the consultant. In (US) law, the client is fully entitled to act in reliance upon the consultant's professional judgment and the duty of diligence is placed squarely and completely upon the consultant's shoulders.

Risk analysis. Business need. Nothing more. Excrement of the male bovine! A high flying Master of The Universe with no more conscience than that of a sack of frozen green beans might be able to rationalize that kind of thinking, but only until the rest of us hunt him down and kick him to death. Risk analysis and business need might yield an action that generates $1B in revenue over ten years with projected liability payouts of $5M, so the Master of The Universe will take it up and start flipping through the pages on jaguar.com. Meanwhile somewhere in a small town very far away a child is being born, one who will be three years old when her family is killed by a product that was unsafe only because the cost of liability mitigation would have exceeded the projected liability costs. The Master of The Universe will be trading in his three year old Jaguar that day. So I say:

Conscience. Responsibility and accountability to the society that sustains you. Nothing less. Only after these considerations are fully met do you think about risk analysis and business need.

This is going to sound extremely harsh and cold, but those are realities. And, frankly, I'm not sure those realities should change. Liability will always catch up with a company. Yes, some people may be adversely affected. Some of those people may be people I know and love. I will be very furious by that and attempt to address it. That doesn't mean that my philosophical stance is any different.

Before you return back with an idea that you can predict risk, let me put this in front of you - if the current risk-averse culture had been in place a hundred years ago, we would NOT have:

• Aspirin
• The car
• The plane
• Plastics (and everything that goes along with plastic, like sterile hospitals and the Internet)
• Coal-fired power plants (which currently provide about 60-80% of power world-wide)
I'm sure I could come up with another 500 items like that. Risk drives innovation. Without high-risk/high-reward, there is no incentive. Think about that before you respond.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Remaining on point, the fact is that consultants and contractors are not shielded as are employees and officers. If as a consultant or contractor you create, enable, or perpetuate a hazard the full measure of responsibility for any harm done is upon your back. In some cases, failure to mitigate a hazard is just a minor division below enabling or perpetuating it.

Maybe your wealthy client can afford to pay out a few million and still show a profit while sleeping soundly at night, but if you cannot then you owe it to yourself to fully mind your own best interests.

I don't care to give further voice to my opposition to laissez faire capitalism or the folly of a pseudo-religious belief in Smith's invisible hand, so I'll just let that go and spare the monastery the negative vibe.

Be well.

I thought about it.

There is incentive without high risk/high reward.

Figure out the impact of your project, make a risk analysis, then consciously determine which procedures aren't necessary in your project.

On risk -- decompose this into two factors. (1) Probability of an "incident" (inverse of frequency of incident over a period of time) and (2) impact of an incident (usually expressed in dollars). The product of those factors is the expected loss. Risk mitigation steps reduce either probability or impact. Thus, don't spend more on risk mitigation than the benefits gained from the reduction of expected loss.

Overall, nice post, though a bit off topic. I'll try to be more on topic by saying that I think that one nice thing about Perl's strong automated testing culture and tools is that it probably lowers the cost of some basic risk mitigation.

Waltzing With Bears: Managing Risk on Software Projects by Demarco/Lister covers these things really well (though I don't quite buy the way they use math to quantify risk).

Well worth a read if you're even close to managing a team or project.

/J

The topicality of this post has to do with how one perceives advice given. I addressed this in the middle of the post. If someone makes a suggestion (like use strict or don't backup your mysql database through a cgi script), it should be taken as a suggestion for an attempt to get to five 9's. If you don't need that level, then you should evaluate the advice in that light.

There is also a perception that IT doesn't have to be subject to business concerns. Wrong! IT's only usefulness to a business is in how it supports that business. Nothing less and nothing more. It is only as we view IT's basis through the lens of business that we know how much or little is needed.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

If someone makes a suggestion ... it should be taken as a suggestion for an attempt to get to five 9's.

That's a little extreme, I think. Perhaps its better to say that suggestions have some implied context and one should consider whether that context matches one's own.

For example, I don't consider use strict part of a five 9's regimen. I think it just has very low cost and high payback in time saved avoiding dumb bugs.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

"IT's only usefulness to a business is in how it supports that business."

The usefulness for business lies in the eye of the beholder.

Because IT structures in some sense separate the business logic from the business implementation via the IT process IT delivers insights beyond the pure usefulness in the day to day work. However usually this is ignored because IT is not a profit center, thus IT has to shut up and let the cash collectors speak.

Thats way I support the view that some part of the IT should be IT for the ITs sake. The reason for such an approach is called Serendipity.

Business need: Frankly, what does the business need? Or, turned around, what impact does this project have upon the business's bottom line. How much money can this project make?

Take NASA, for example... ;-)

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Given that almost all of us work for organizations whose purpose is either to make money or only achievable if money is brought in, then it's a good metric.

Think about this: a business is in the business of making money. It produces products and/or services in the support of that goal. If you think otherwise, you're fooling yourself.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Think about this: a business is in the business of making money. It produces products and/or services in the support of that goal. If you think otherwise, you're fooling yourself.

Now what fallacy is this one? Post hoc ergo propter hoc? A business in the business is making money, that's how business generally works today: making money is a necessity for business. Which doesn't mean this business is in business because its primary goal, its raison d'être is making money. Think of NASA, again.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Simple as this may seem, it is very difficult to calculate the value of your risk at any time, so there is still a lot of guessing in this model.

This is interesting, considering this node's context-> a single bad command

Clearly NASA isn't always looking to the Balance Sheet and the Profit and Loss account or the shareholders, but if it doesn't do what Congress wants and can't demonstrate its continued usefulness then it doesn't get money. No money no engineers, no spacecraft, no space exploration. So in a sense it is a business, selling its services to the people of the USA, although hopefully the money is secondary to the principles and aims of the engineers.

How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist.
Robot Tourist, by Ten Benson

• I do not agree that the point of business is to make money. Money is a measurement tool. It does not make sense to exist simply to be measured. The point (from my distorted point of view) of business is to provide goods and or services that improve life, or provide the perception of an improved life, for people. If a company is good at that, then they do well for a long time(with natural cycles of highs and lows that reflect change). The moment an organization starts making money for the sake of making money, the organization is relatively lost. And yes, that goes for financial institutions as well.
• IT can enable an organization in its efforts to find new ways of improving life, or delivering old ways with less expense. IT is not always used in the above mentioned pursuit, and often suffers because of it.

The neat thing about NASA is that it drives change, and a good percentage of that change adds value to life. I would venture to guess that if NASA changed it's goal to making money, it would loose it's value in less than 6 months, even if there was a fantastic business model and plan in place. NASA does good stuff because it's goal is to learn and apply. Most good business is the same. Money is just a measure of how well an organization sets, pursues, and measures the values of its goals. If the goal is making money, a circular dependency is generated that is unhealthy for everyone(ENRON, Big Tobacco..as I light up another... :-)). Ok, I am wandering.. time to stop.. but it is fun.

I think you are confusing the goal of making money and the process by which an organization can do that. There are companies who make money using short-term goals. These would be the Enrons of the world. Then, there are companies like Kongo Gumi, the longest running family business ever. Lasted 1498 years.

A business that lasts long-term tends to be a business that looks after its customers. But, it does so because of enlightened self-interest - the best way to guarantee making money next year is to look after your customers this year. Customers, in this case, means "those people who give me money".

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

No offense, but I think you just supported my point. And I don't feel a bit confused. It is the results of the process of making life better that we exchange for money. When the goal becomes the money, the process is short-circuited.

I suspect that this is an interesting divergence of philosophy between us.

That is a good thing.... diversity is strength. Have a good one dragonchild. :-)

...the majority is always wrong, and always the last to know about it...

Take disaster recovery, the black hole of all IT budgets. Everyone says we need disaster recovery, and they do a study which says we have to spend a big chunk of money, and keep spending it year after year, just in case something goes wrong. That’s money that doesn’t go into product research, customer satisfaction, employee raises, etc. It does not further the companies bottom line by a single penny. And management says, how often do we have a problem? and how much was that again? And decide there really doesn’t need to be real disaster recovery, just a plan, and we already have that. But let the system go down and see IT catch the heat for not being prepared, even though there was not budget to make it happen.

There are some businesses that don’t have to make a profit, NASA, the government for example. Everyone else has to a least break even, or they go out of business. The truly successful companies have balanced sowing enough back into their company that they continue to lead their respective field. If they don’t someone will come along and do it faster and cheaper, they will lose market share and go out of business.

It still takes money (or sweat equity) to make money. It’s being wise enough to spend the money you do have prudently, and recognizing what do we NEED versus what would be nice to have and make our life easier. Life is and always will be trade off’s. Lost the budget battle for HP Openview, then learn to live with Nagios or Big Brother. But there is nothing to keep you from doing the best you can, with what you’ve been given, and not sulking because it’s not exactly (or maybe even close) to what you wanted.

Business decisions aren't just what's initially cheaper. There are dozens of factors that need to be weighed in, such as:
• TCO (Total Cost of Ownership)
• Migration costs (If it costs $400 to upgrade a machine the MS way, but 40 hours to retrain each user to Linux . . .)
• Compatibility. (OpenOffice and StarOffice are 99.9% compat with MS Office. Some companies cannot bet on the 0.1% chance)
• Client requirements. (You might lose a contract if you're not seen as using the "right software".)

All sorts of reasons why FOSS isn't chosen in the marketplace that have nothing to do with price of acquisition or technical merits.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

I argued the point you make in the first sentence (good business sense to use OSS) with the plant manager of facility owned by a materials research and development company back in 1999. The debate was good natured, but there was no middle ground to be found between our arguments. After a bit of time, the plant manager smiled and sent me to make the same arguments to the corporate lawyer. I could not for the life of me figure out what that was about until I went and discussed it with the legal eagle. The answer I received from corporate council was "ok if we use this OSS stuff, who would we sue if something went wrong?" This guy was not kidding. I still have to laugh at my own shock. We were spending 10's of thousands on licenses, upgrades and service agreements so we could have someone to blame if something went wrong. Risk analysis apparently indicated that external culpability was worth more than stable working product.

What a bloody waste. We could have spent half of what we did on a few good people and had stable systems...

...the majority is always wrong, and always the last to know about it...

I read a similar NASA case-study a few years back when my employer jumped on the CMM band-wagon.

The folks that where pushing CMM emphasized the benefits including higher quality, lower costs, less reliance on key people, and so forth.

I read the CMM book published by Carnegie Mellon. The book didn't really speak much to the commoditization of "key people" but instead referenced a NASA case study

I considered the NASA case study to be a fair, consistent piece of literature and far more realistic than most of the dogmatic slogans that I associate with CMM.

In conclusion, folks pushing 'process' up the management chain should provide all the information to the execs, not just the rhetoric.

The team-leader said to me: "we can't allow the business to put that kind of pressure on our IT methodologies - leave this with me and don;t do anything." -- and wandered off.

Thanks to the power of Perl and my experience with language processing software in general, I had a working database to Reuters-page translation programme ready in time. Meanwhile the team-leader had gone and got permission from the global head of IT to say no and let the trader lose the $100 million. The value of the IT department's work for a year can't possibly have amounted to that much! Needless to say I lost that position soon after because I didn't fit in (and wouldn't have wanted to!).