IT Just Doesn't Matter!

No, this isn't a reprise of Nicholas Carr's controversial but revenue-earning published treatise that "IT doesn't Matter"...although I suppose it is in a far grander and abstract sense. It's actually a reprise of a Bill Murray line from the movie Meatballs.

Murray, a summer camp counselor in the movie, is trying to inspire a rag tag collection of youths that, if I recall correctly, have either just lost or expect to lose a challenge to a rival camp. Murray, in a rant that starts out calmly enough, sings the truth about all challenges in life. The point is that everything we do is just another step through the collections of experiences that make our lives what they are. It's not worth worrying about losing a sporting event in summer camp because in the end, it just doesn't matter. At the end of the speech, Murray is screaming the words "it just doesn't matter" over and over again. Total silliness, and yet spot on.

Another way to think of this is to understand that we cannot fear failure. It's hardly a new concept. For decades, MAD Magazine's Alfred E. Neuman has been saying, "What? Me Worry?" and of course there's the old adage, "If at first you don't succeed, try, try again," and it's funnier cousin, "If at first you don't succeed, you're about average." Perhaps William Saroyan put it the most eloquently when he said:

We gain more wisdom from failure than we do success.

My own personal quote about this:

Failure is an event, success is a destiny.

-----

I just got back from hauling my family out on an emergency trip to visit a friend five states away from where I am. It was a long two-day drive out and another two days back, with just a day in between to spend some time. He has taken terminally ill, and the thought of losing him when he is relatively young both saddens and angers me. It is not fair and it is too soon.

But it certainly puts things in perspective.

I gripe about incompetent supervisors, soulless corporations, and incompetent software development practitioners on this blog, all in the name of trying to make life better for those that live in the code. My hope is that we don't have to while away too much time working unjustified overtime; that is, overtime executed by the programmers to compensate for mistakes sometimes their own but mostly of management.

Perhaps in the end, though, it just doesn't matter. Here are some lessons I've heard before, but that have been emphasized in the last few days.

Life is Short
You know, I have heard this so many times that I think the words have lost their power. You almost have to get hit in the head by the sledgehammer of life to appreciate it. Barring a miracle, I'm told my friend may be leaving in his early 50's. He will be survived by an eight-year-old daughter. It's just to damned soon; he will miss a lot of amazing parts of her life. So perhaps getting organizations, most of which have the inertia of a battleship, to change course, is folly. Maybe all those cynical bastards on the Joel On Software forums who always tell people, "Don't fix that rotten situation, just bloody leave," might be right. I know this isn't always true, but if you're meeting resistance from top, remember that life is short.

Life is not Fair
Everyone says this. Everyone knows it. But once again, what's happening to my friend is downright rotten and really bringing the point home. He suffers while Ken Lay got a quick out. He is a good man, intelligent and congenial to all. I do not know him to have ever wronged someone. But we are surrounded by unethical nincompoops who take enduring enjoyment of life's spoils. I am wary to say that my friend was not wealthy, for wealth is not just about money, and my friend has lived a grand life and knows love. But the cretins I write of have also achieved diverse riches often while on the backs of others. Life is not fair, and it's short too. There are times when good men need to be a little selfish if they want to keep the fires burning as long as the other bastards. US citizens don't like it when they hear about their troops dying at the hands of cowardly guerilla tactics, but the US special forces also employ guerilla tactics. It's not necessarily cowardly; when the odds are against you, sometimes it's the only option you have to survive. Tactics and strategies aren't good or evil; it's about the cause and the way they're applied. Building relationships with the indigenous population to get information, or using laser targeting to bring stronger ordance against a fortified position to protect your own troops is smart. For any terrorists that think I'm giving them a pass, sorry, suicide bombing a marketplace full of people that have nothing to do with your war is stupid and cowardly.

Money is not Evil
My friend was not a millionaire by any means, but he did well enough, and he made some good decisions. He invested his earnings into a fine home, which he will bequeath to his surviving family. He has a pension they can use. He bought a life insurance policy. He will be leaving behind a wife and daughter, and some step sons. We are often taught to think of money as an object of evil or superficiality. My own mother tells me, "We should love people and use things, but instead it seems most of us love things and use people." She is right but like strategy and tactics, money is not good or evil. Money is a tool; in the hands of a good person, it can do great things. Even in the hands of a bad person it can do great things. From Stephen Ambrose's Nothing Like it in the World, I learned that the businessmen behind the transcontinental railroad were likely those that could be accused of "loving money". They were some downright corrupt bastards. But the transcontinental was borne of ideas from great men like Abraham Lincoln, Grenville Dodge, and Theodore Judas. Lincoln, Dodge, and Judas are regarded in the book as ethical men and long-term thinkers; the kinds of men that made America great. But they could not have built the transcontinental without the help of some downright corrupt bastards. Good men should be a little selfish sometimes and take a lesson from Issac Asimov's Foundation:

Don't let your morals get in the way of doing what's right

When software developers have to choose between career options, of course the best advice is to look at more than just the money. However, there's no dishonor in taking the bigger piece of pie if it's not doing anyone any harm, and you might be able to do more good.

Lessons Learned
With regard to software development, remember:

• Life is short: You have a family you are responsible for. Giving extra hours to a soulless corporation will ultimately be less satisfying than giving them to your family. You don't know when your diety will tell you, "Put down that keyboard. Don't bother collecting your shit. It's time to go."
• Life is not fair: There is a place for honor in this world, but it is best reserved for friends. Corporations, especially public ones, have too many stakeholders that don't care about human life. And your competitors, those hacks that leave their clients in a bind to jump to contracts featuring new languages or higher pay, well, unfortunately many of them have reputations for being productive because they cheat by writing shit code that they don't have to maintain. It may seem loathe to do, but sometimes you have may have to do the same. Just try to make it a better quality hack than the other guy's. Somewhere down the line another developer will appreciate it.
• Money is not evil: You might make the mortgage, but you'll never be a philanthropist that opens a cancer research center if you work for a company that thinks making software is easy.

The Free Guide to Corporate Cost Cutting

All right. I've had enough about this cost-cutting business. I've seen it cycle back and forth through my 20 year IT career, and I'm giving free advice here for anyone that cares. Although it's going to sound like a rant, there might be a couple crumbs of usable information. If anyone finds it valuable, you don't even have to credit me...just do something right in your organization to help your people and we'll call it even.

Reduction in Force

The human resources favorite since the early-1990's. Don't hold your discipline, diet and exercise plan accountable; chop off an arm to lose weight fast. If that doesn't work, try chopping off a leg. Plus, the press loves seeing employees get pounded. Company stock always rises after layoffs.

Although layoffs are generally derided by critics, I'm actually not as down on them as I used to be. Political correctness has changed the employment landscape such that you can't easily fire people for things like incompetence...now you can only fire them for really egregiously wrong things like offending someone's politics or hurting their feelings. And whatever you do, don't release someone that's a minority! Kicking out the elderly is apparently ok.

It's no secret: the companies today use the economy as an excuse to release marginal performers. I'm ok with that, as a part of the evolution of business tactics. In fact, bring on a boom and recession every other year. You need some time to evaluate people and figure out who your sinkers, swimmers, and floaters are. If the organization doesn't have the guts to call it on the sinkers after six to twelve months, then the layoffs are the next window of opportunity. Just be careful to hunt down the truth in the proceedings; you don't want to keep a swimmer that's really just a sloppy hack that's good at politics; analyze the train wrecks they've left behind them.

Sundry Cuts

If I cut pencils out of our budget, I'll save (number of employees X $.35)!

Cutting menial items out of your budget can save money. But it can have effects in other areas. There is a price of doing business. If you are not willing to pay it, don't do business. If you cut in too many ways, you risk looking unprofessional to your clients. Even if that lack of professionalism is superficial, the appearance of impropriety can have effects just as damaging as the actual impropriety. Consider the value of first impressions.

I once had to tell guests that we didn't have coffee cups for a meeting they were attending because of cost cutting. That's damned embarrassing.

I had a friend at another company tell me the company would no longer reimburse airport parking fees. That's damned embarrassing too. Look, cut by asking the employees to find more competitive parking rates, perhaps, but they're traveling for you, so cover the travel costs. Those travel expenses are legitimate 100% business deductions. Can you say the same about expensive bottles of wine at the executive lunches? (If you answered "yes" to that last question, you're a cheating ratbastard! US tax code limits meal and entertainment deductions to 50%, unless given as a documented form of employee reward).

Costs you can cut:

• Extravagances like vanity, which pay for expensive end tables in the organization's lobbies, golf trips where clients aren't involved, and ridiculous marketing projects like endorsing a sports team that has nothing to do with your business and clients (think EDS and bike racing, or EDS and herding cats, or EDS and stupid logo changes, or EDS and a marketing brochure that actually offended EDS employees).


• Extravagances like favoritism, through which a cost control measure only applies to the grunts and not to leadership. Of course, that never happens in your company, because you don't just preach "leadership by example," you practice it too...right? Right? Bueller?


• Extravagances like cronyism, in which large swaths of staffs turn over because one key guy comes in. It's not wrong to bring in fresh blood or known resources, but they should be vetted by more than just the head crony. Sometimes a crony might be an upgrade for a position, but sometimes talented and experienced indigenous staff get carelessly discarded in the process. And typically, cronies don't come for less money than what they made in their previous positions.

Cutting insignificant things saves the organization insignificant money. Go for the things that are costing real money and compromising morale every day.

Tools

Engineers, developers, and accountants don't need fancy tools to get things done. They've done without them for years.

People that have been in business for a while know this: payroll is a profit killer. Don't believe me? Ask leaders in any business as small as a restaurant or as big as General Motors. Hence, "reduction in force" being the number one cost-cutting maneuver.

But only an idiot thinks a company can survive without workers. That's why leaders always pay lip service to publicizing people as one of their pillars of strength.

So if you can do nothing else, make the employees you have more efficient. Yes, an automated testing tool will cost money and require time to set up. Yes, computer aided design means having some powerful workstations and some expensive software. But the right tools make your staff more efficient, a cost-cutting act of its own although sometimes difficult to quantify or measure.

But it's not just about making it easier for one person to do a job that used to require several. It's reducing the errors now that cost money to fix later. It's about making people downstream in the process both more efficient and happier because the output passed from the group before them is better.

Education

Let's cut training. It's expensive and our people don't need more skills to do the existing work; they already know how to do that.

The first casualties during a cost-cutting phase always seem to be training and testing. In the same vein as Tools, above, training is a way to keep your workforce current. Automakers don't build cars the same way today that they did two decades ago, and those that do are about to die. You must be competitive to survive, and this means keeping up with advances in engineering, continuous improvement, project management, software, human resources, compliance, law, accounting, and the business of your industry. If you aren't willing to pay the price of doing business, get out.

It's true training costs money. But contrary to what some leaders believe, it's less expensive than churning employees. Churning as I see it is the practice of not training your staff, burning them out, then replacing them with cheap college graduates who have been exposed to new skill sets and methodologies, of course at lower salaries. But turnover as a strategy doesn't take into account the cost of lost experience and relationships within the organization. Training can be a cheaper strategy because it can be measured as a set cost instead of a strategy in which there are superficial gains but dangerous, unexpected, and more difficult to measure intangibles and side effects.

Business Analysis and Testing

We need to get something done and it has to be done by a certain time. Let's set a deadline without doing research first on what's involved.

This point has more to do with business process than cost-cutting, but as I noted above, testing and training are typically given the short shrift on projects even when cost-cutting isn't a focus.

Why does this continue to be a mistake organizations make time and again? Karl Weigers in More about Software Requirements, lists this as the first cosmic truth about requirements:

If you don't get the requirements right, it doesn't matter how well you execute the rest of the project.

Weigers isn't sharing a trade secret here. Anyone that's been through the pain of a project that was subject to poor requirements definition knows this.

I'm not going to bitch any more here about the folly of not giving business analysis its due. But instead, here's another quote from another writer, George Santayana. You don't have to pay it any heed, writers are idiots anyway.

Those who cannot learn from history are doomed to repeat it.

Executive Salary

Says the rabble: Why give so much money to one guy? The company could save a half a million dollars if the CEO didn't have such a high salary.

Despite this blog's rants against misguided management, I have ambivalent thoughts about executive salaries. It's easy to point fingers at the top guy's compensation and say it's a point for cost-cutting. But it isn't always a logical point. For a truly large company whose economies of scale are in the multiple billions of dollars, re-distributing the $500,000 salary of the CEO to the thousands of employees would represent only a small adjustment to them. It's a convenient scapegoat. If it could be reduced, sure, that's a nice gesture that can be taken by those that practice silly things like leadership by example, but it's going to have a limited effect on the final numbers.

A good and sensible leader that has made proven decisions to secure a company's viability (not just ridden the wave during good economic times) , is worth a competitive salary. I think in most cases, this is a part of the cost of doing business (although I would caution executives from getting too heady about this. If you believe you can outsource a software developer to a cheaper but comparably educated one in another country, allow too that you could you swap out an executive for a cheap and perhaps even better educated foreign PhD in business).

A more appropriate subject to cost-cutting is compensation for failed executives. Political correctness once again rears its ugly head here: HR departments are expected to provide some severance for terminated employees. Superficially, this appears to be a policy of humane intentions, to provide some relief to the separated. However, it's probably also the recommended approach in HR circles to prevent lawsuits. The stories of substantial payments to executives that left their companies in worse repair than when they got there are all over the headlines. This is ludicrous. It's not as if those executives weren't paid well when they were running the show. Some of the golden parachutes would have paid the facilities maintenance staff's salaries for years. Why would you pay so much to a person that made messes instead of giving it to the people that clean up messes?

Caveat: let's be careful not to vilify executives that, in contrast to a fair weather CEO, may have made reasonable decisions but had nothing to do with greater economic forces that affected all businesses.

Employee Salaries

Everyone must share in the sacrifices made to maintain the solvency of the company and prevent additional layoffs.

As a survivor of this tactic, I can appreciate its intentions. Everyone takes a pay cut, so there is no appearance of inequity.

But if this is done, do it universally across the organization. When you say everyone, you should mean everyone. If one department takes the hit, how does it affect morale when other divisions don't? And in past years, when the other divisions weren't doing as well and the affected department was sustaining them, did they also get cuts? Despite good intentions, is a nasty precedent being set?

It's also probably better to take an even percentage across the board. The companies I've seen do it use a graduated scale so that higher earners take a larger percentage cut. This is a cost-cut, but some would say it's also taxation without representation. It means, assuming your company is a meritocracy (a huge assumption, I will concede), that the people awarded higher salary increases sustain a proportionally higher sacrifice than those that did not earn the same increases. Suddenly the appearance of equitability has a few cracks in it.

Cost-cutting is Reality

Cost-cutting is a reality of life. It is neither good nor bad, and everyone should be trying to do it all the time, not just in recessions. But some ways of doing things are probably better than others. Good luck.

The Truth

The truth is an important thing when you want to get to the bottom of something and having the truth is the most important part of making decisions. This isn't just about programming but everything in life. The problem is that the truth is often at odds with tact.

Things to remember about the truth:

Sometimes, the truth will make people laugh.
Sometimes, the truth will hurt.
Sometimes, the truth will set you free.
But always, the truth will piss someone off.

Best is the Enemy of Good

Continuous Improvement
It was encouraging to me that my company decided to host a continuous improvement activity for the development group in our IT shop. If you've never done one of these before, it's related to process improvement and such things as LEAN and Six Sigma.

What I didn't understand before the activity was that LEAN is not about solving the root of the problem, it's about trying to streamline and make more efficient all the peripheral things in the total process. For example, in our workshop we identified that some of the production support load we get is from misdirected requests that should have gone to a different group. So we're taking steps to better educate users and other support personnel so they can reduce this source of inefficiency.

However, I asked about the fact that the real source of production support loads is often poorly built software, and it was accepted by the session consultant that indeed, LEAN does not always address the root problem. The example he used was from when he worked with a group that performed drilling on a designated area. Improved productivity could have been had by using a faster drill or technique, but that was not what LEAN was about. It was instead about all the particulars of the process leading to, during, and following the drilling, and removing wasteful elements in these phases of the total effort.

Another Adage
Anyway, improvement is good in any space, so I'll take what we get out of it even if it means the software we're using is still seriously flawed.

One of the interesting things emphasized during the workshop, however, was:

Don't let best be the enemy of good

This was meant to keep us from succumbing to paralysis by analysis. I've heard this same sentiment in another quote from Patton:

A good plan now is better than a great plan ten minutes from now

I can't disagree with the gist of those platitudes, but there is a fundamental problem facing most software teams that try to use that quote for enlightenment. What if the battle they're fighting isn't between good and best, but good and mediocre or poor? My version of the quote is therefore:

Best is the enemy of good, but don't confuse good with
mediocre

Remember: making software is easy, but making it right is hard! It is too easy to lower your standards and say "good enough." But as complicated as software is, the truth is that "good enough" is probably "bad enough" since corporate software is often poorly designed and poorly tested. Even if it is good enough, chances are you'll have to change it, and good enough can quickly become not-so-good.

Project Management - Friend or Foe?

The concept of project management is becoming more popular, thanks in part to the efforts of the Project Management Institute and some institutional desire to better organize and control projects. The concept isn't new, but classically the project manager in corporate projects was someone that was either part of the delivery team and was expected to manage everyone or was a manager that may have had supervisory control over the project team.

The official position of project manager (PM) as it has been explained to me is one in which the PM may not have managerial control of project subordinates and must use persuasion and communication to keep the project on track and the team members delivering. The contemporary PMI definitions make the PM responsible for several project guidance and reporting deliverables, and providing these represents actual overhead costs. Although some will say the effort involved in being a PM is not enough to justify it as a full-time role, I would argue that it could be, depending on the project and complexity.

Resource Management
In my past experience with PM work, one of the things I've struggled with is when members of the team are expected to materially participate in the PM duties. If your projects are anything like the ones I've been on, then you're familiar with the corporate American tendency to want things as fast as possible. Especially with software, it shouldn't take long because software is just a bunch of typing and how hard can that be?

But as the blog has noted before, software is only easy if you want to produce garbage. It requires real focus and a mental investment to create effective software, and when the programmers have to also spend time delivering project management deliverables, the programmers are forced to spend less time on analysis, design, construction, and testing efforts. That often leads to frustration for both the developers and the PM.

It is not wrong to expect some developer input in PM deliverables, but certainly this is overhead that needs to be considered lest the staff feel they are once again forced to work unpaid overtime to produce something other than actual product.

PMs versus Developers, Users, and Analysts
The overhead of PM work distributed among the team can at least be managed. There's a more serious disconnect that can happen when it comes to the subject of determining project quality. Scott Ambler's written a little about this in his blog at Dr. Dobbs Journal.

To summarize, Amber ran a survey that included questions about how project members define IT projects a success. Although the survey sample was modest (Ambler got roughly 600 responses) some of the results alarmed him. He found that:

"It appears that project managers are more interested in delivering on time and on budget than delivering when the system is ready."

He conceded that the sample size didn't include more business stakeholders and so the statistics might need to be taken with a grain of salt, but the general thought does make sense. The goals of the PMI would certainly stress "on time and on budget" as measurable goals. Software quality, on the other hand, is harder to measure. Because of that, it's also hard to estimate the effort needed to reach it in planning phases. The concept of quality is also subjective and that doesn't help matters.

Maybe Software isn't a Project
Here's another idea. Software is a living document. It changes over time and as long as people are using it and maintaining it, it's never done. Does that sound like something you can harness with a beginning, middle, and end?

George Stepanek, the author of Software Project Secrets (Apress ISBN10: 1-59059-550-5), notes that the formal project management methodology is not a good match for software development. Static phases like initiation, planning, and concluding are more a match for traditional waterfall software methodologies than newer "agile" methodologies. Although I'm not as down on waterfall as most are (all waterfall did was win WWII, send a man to the moon, and get the space shuttle into space, among other things), there's no denying that regardless of approach, software is a series of iterative feedback loops between developers and users that extends far beyond a stated project period.

Software Management and Project Management Must Coexist
Neither software nor project management are going away anytime soon. Software has become a part of our everyday lives and project management adds appreciable value in helping to "divide and conquer" the body of work corporations do. But developers and project managers have to continue to understand the disconnects between traditional project approaches and software development and also make strides in measuring software quality. If this does not happen, then the industry will continue to be filled with projects that are only successful on the surface. It will continue to be a place that graces a few with bonuses while leaving behind train wrecks for others to clean up in the late hours.

A Tale of Two Tenets

I'm at a crucial moment in a developing project. Once again I've been tasked with planning changes to shaky software for a high-profile project with an expected due date that was set before developers were consulted. I am looking at our list of change requests and some are downright scary.

The Best Kind of Programming is Refactoring
On one side I'm trying to use this opportunity to continuously improve the existing code base and would like to apply another refactoring pass to follow-up a previous refactoring.

I consider the refactoring performed last year a success. It consolidated an embedded SQL script that was hard-coded and spread through about five different parts of the application. The refactoring was fairly simple, consolidated the code into one object, and has been working great in production since we installed it. I don't think we've seen even one defect come from it. It allowed us to perform some complicated logic, including recursion, for a later project request in a much more controlled fashion (modifying one object instead of five or more).

But it could still be improved. It consolidated the embedded SQL but didn't move it to the most central place such logic could be: on the server in an Oracle PL/SQL package. If it was on the server, its functionality would be reusable not only by the client software but also by other PL/SQL procedures. With this new project, I'm considering making this refactoring part of the applicable change request, but I'm very conflicted about it.

If it ain't Broke, don't Fix It
In an earlier post I said that writers say "The best kind of writing is re-writing," and that perhaps "the best kind of programming is refactoring." I still feel those are valid statements and that disciplined, regular refactorings are a good thing. However, I'm also under pressures to deliver this project in a timely fashion. So what else is new?

Here's the dilemma. I have to decide how I can effect the required functionality change. Do I add the new code object at the client object level, and have it integrate with the existing recently refactored business object, or do I start it with the logic at the PL/SQL level?

Building the new object's guts at the PL/SQL level seems to make sense and is essentially doing what I did not do with last year's object. But the new object will need to communicate with the existing one, and that means I have to also refactor the existing object. That adds overhead to the project for a benefit whose value to the organization I can't quantify yet. In addition, this refactoring would have a few challenges.

I'm sure PL/SQL can handle the logic demands, but I'm unsure if the way I'm currently performing dataset management in the client will translate cleanly to the PL/SQL. The objects's internal data grids will need to be replaced with cursors or work tables and those perform differently than the client's grids technology. And some of the more complicated functionality in the current object may need to be adjusted for the paradigm shift. So I have concerns that moving the logic to the PL/SQL layer isn't just a rote migration. There will also be a translation effort that introduces some risk.

It now becomes a battle of "The best kind of programming is refactoring" versus "If it ain't broke don't fix it." Of course, that's the whole point of refactoring, as McConnell notes in Code Complete. "Refactoring refers to changes in working code..."

On the other hand, "If it ain't broke, don't fix it," says that you might be better off spending time on other improvements. The old saying has some merit with regard to stability, but it can also be perceived as a philosophy of complacency. Fortunately, I don't think complacency is the problem here since the current object is already the product of a recent refactoring and is performing well.

Conclusion
I don't want to work unnecessary overtime. I did it on the last project and it went on for a year and a half and represented a sizable sacrifice on my part that I'm fairly certain was unmatched by anyone else and certainly not by the compensation. So I will probably keep the code at the client level, but still encapsulated in a business object; this will save us the effort involved in the additional refactoring pass of the existing object. The new business objects will be able to communicate with it and I don't foresee significant performance problems. If we need to, we can attack the logic migration at a later time when such refactorings are not subject to the project's time constraints.

Is that the right decision? You could argue either way, but a few points from McConnell's refactoring checklist bear emphasis here:

• Are you keeping each refactoring small? A complete move of the logic would bear a proportionate amount of risk and regression testing, so I think electing to postpone a full refactoring does help. I could certainly still peel off outer bits and at least start the process, leaving the rest still in the client.
• Have you considered the riskiness of the specific refactoring and adjusted your approach accordingly? See above.
• Does the change enhance the program's internal quality rather than degrade it? A bit trickier to answer. I don't think refactoring the entire object would have a significant effect on performance or readability, but does give us more options in future solution designs. As I said above, perhaps not valuable enough to entertain at this time.

The battle between fixing something versus cobbling more crappy code onto a crappy foundation is an endless one for most developers, but especially for that group that has to maintain code for shops that aren't involved in commercial software development. Developers in commercial software shops can afford to be purists; developers subject to corporate sensibilities (or insensibilities) have to reconcile that their leaders are revering time to market over software quality. Many of them don't even understand the concept of software quality, and perhaps they don't need to if their business is not software. But at some point someone does and has to fight the battles I've described here. Whether the guys at the top understand it or not, software quality does affect the company's costs and efficiencies.

InformationWeek's IT Salary Survey

InformationWeek and ComputerWorld both run annual salary surveys for IT. InformationWeek's was just published in the 28-Apr-08 issue. I like to read these because they have some interesting things to say, but you have to be careful about treating them as the truth. There was a famous thread a year ago at the JoelOnSoftware.com forums titled "How much do you make?" and it ran for weeks and got cross-linked by lots of sites. It's interesting to see how different it was from the InformationWeek survey.

Statistics
First, you have to be careful about the demographics of the survey. InformationWeek says there are 3.8 million IT workers, but less then 10,000 responded to the survey. Not exactly a confidence-inspiring sample size.

The gist of the InformationWeek survey was that salaries were down a bit, as were bonuses. There were some interesting trends noted, that hiring is actually up in the lower salary ranges for positions like help desk work.

The JoelOnSoftware.com thread was filled with people saying they were making a healthy six figures, but that forum is going to be skewed toward experienced developers rather than a mix of all IT professions from infrastructure roles to management. Interestingly, many of the more well-off programmers at the JoS forums hail from New York banking shops.

Unsettling but Perhaps not Surprising News
Hot on the heels of my training class, the thing I really didn't like to read in the InformationWeek survey was that training continues to be a second-class citizen in the realm of IT benefits. I've said it before, if you don't invest in your people it will come back to haunt you.

But then again, maybe that random sampling of 10 thousand people just had it bad. In ComputerWorld's annual rankings of the top 100 companies to work for, education is still a serious benefit for those employers. Good luck getting into one of those companies if you're not already there though.

We don't have Time to do it Right the First Time and We have even less Time for Training
Why doesn't corporate America want to pay for training? One of my theories says it isn't about cheapness, though that is a factor. I still think it's impatience. It takes a long time to get a person trained and productive in a completely new technology stack. It's not impossible, but it certainly seems slower than signing a contractor on that already has the needed skills.

If what the InformationWeek survey says is a real trend though, then perhaps Nicholas Carr was only half right: it's not just that IT doesn't matter - people don't either. Companies can apply the software as a service model to people too. Just pick up some free agent off the waiver wire and dump him when you're done; no training or benefit expense headaches necessary.

But we have this already don't we, between onshore and offshore contracting? And people as a service doesn't work often. It never works as advertised. How many Oracle or SAP ERP implementations have incurred cost overruns? How many have left people happy? That generic out-of-the-box approach leaves a lot to be desired, doesn't it?

Your best bet is to get good people, train them in your business and also help upkeep their skills. It's like the difference between washing your car yourself versus paying someone else to do it. Will that contractor put as much time into detailing your vehicle as you would? Would he or she know the quirks about not using abrasive polishing agents on your custom chrome wheels? Maybe, but if you did it yourself, you'd go the extra mile and you'd also know what parts of the car to be careful around, like that loose handle or that spot that needs rust protection. There will always be differences between companies and how they operate. Who would understand your business better than people that have a stake in its survival and who support it every day?

Amid these salary survey discussions, something to remember is that paying for good people isn't just a cost; it's the cost of doing business.