|
1. The answer "not yet supported" is much better than "no longer
supported".
Keeping your software and hardware packages current is beneficial to
your business because your options improve. "No longer supported" means
you haven't a chance in hell of getting what you need. This goes for
patching, too. Be early, not necessarily first, to patch your software
and systems. No, I'm not really concerned about the hackers and script
kiddies when I say that. I'm just thinking about how much shorter the
outage is when the support guy tells you at 3AM, "Dude, I can't help you
until you install Sol9_Recommended and the following driver revisions."
Keep everything up to date, it's cheaper and it works better, generally.
2. The answer "that's not supported" is also better than "no longer
supported".
Now you don't have to wonder. You know you can't use this tool for the
job and you're not going to be stranded in the future. Resist the
temptation to get someone to stretch the package into compliance. Custom
software delivered in this way is even worse than hearing "that's not
supported".
3. Backwards compatibility reduces cost and alleviates risk.
When the package says "Solaris 2.8 and up", "WinNT 4 and up" or "OS X
10.3.4 and up", it's a safe bet that the product has improved, is
maintained and has adapted to changing business and security needs.
Yep, it brings baggage, complexity and mistakes forward. The code will
look like 10 week old ground beef. As Spolsky says, that's the result of
the code being useful and used.
It will still be cheaper to own and operate than substituting it for
tiny, fresh, immature and limited functionality code which carries no
history with it. All that new package can do is grow to be something as
ugly as the backward compatible code or it can wither on the vine.
4. Again with the backwards compatibility thing.
What's wrong with Java?
With .Net?
You write code. You depend on a runtime environment. Both Java and .Net
architectures can easily support backwards compatibility but you'll find
that they often don't. As an author, your investment of time (and your
business) can be squandered in a heartbeat because the function you
import from the version X runtime isn't available in version Y.
If you invest in technologies built with no concern for compatibility,
you're letting someone else run your business.
It doesn't have to be this way and, otherwise, these are excellent
environments. By the way, how many different Java runtimes are nested
under application paths on your desktop? I bet there are at least 2 if
your machine is built for business and is running software released for
business in the last 6 years. That half Gig of disk space is lost just
because of lack of runtime version backward compatibility. Just thought
you'd like to know that, really.
And for the .Netters out there, what happened when your .Net 1.1 code
was dumped into your .Net 2.0 compiler? How many pizzas died in the
ritualistic sacrifice before you got it compiled again? And did you
suddenly have new bugs? New regression failures?
A Hoover couldn't suck any harder, could it?
5. Don't let software vendors drive your business.
Upgrades are to be expected. Yes, it ought to cost you money. Your tool
vendor shouldn't have the ability to destroy your investment by
destroying its path forward, though. To date,millions of lines of (good
as well as bad) VB code are stuck in time, unable to move forward to any
.Net language and away from COM. Come to think of it, .Net itself hasn't
yet been able to get the COM monkey off its back. (Hint: look at your
Visual Studio IDE. It's still based on COM. Wonder when they'll get that
fixed?)
6. If it's a Unix tool and it doesn't say OS X is supported, don't ask.
Too many Unix product vendors will let you see exactly what they're
thinking when you do ask. It's a mental dialog and it goes like this:
"Apple? Well, that's Unix underneath, right? We're a Unix product,
right? Then we must be compatible!!"
Don't trust it. OS X is, indeed, Unix underneath. It's a Unix variant
and a damned good one, in fact. But that doesn't mean it's X11 out of
the box. It doesn't mean that the file system works like any other Unix
offering. That vendor has missed something and it will be because he
made the assumption that OS X is nothing more than any other Unix
variant. It's just not that simple.
7. You may freely interchange any particular flavor of Linux for "Apple"
or "OS X" in item 6.
8. If the vendor won't meet with the technicians alone and insists on having an
authorized check signer at the demo, cancel the meeting with that vendor.
I'm stone cold on this one. You're an IT vendor and the money guy has to
bring the checkbook to your show? You're telling me you can't compete on
your technical merits and that you want us to pay for your form of
entertainment.
Tell you what: book a venue and get Ticketron to sell the tickets. I'll
consider paying $50 for mezzanine seats, okay?
It's hard to believe but there's an enterprise disk vendor, and we all
know it's name, who still sells its stuff this way. Who knows if it's
any good? Who got to evaluate it objectively?
Certainly wasn't me and it makes me suspicious.
9. Best Practices aren't always.
A better way of looking at this, I think, is that Best Practices need to
be periodically challenged once in a while to make sure they're not just
Common Practices and that those Best Practices support a real need. That
goes for Standards, too.
At no time is spilling the phrase "Best Practice" from your lips an
acceptable substitute for thinking.
10. You're always making an assumption.
Will you catch it?
My boss, on the eve of the iPhone's release, asked his crew whether we
thought the iPhone would impact the business. He said nothing else.
Most of us failed the test, including me. For the record, my answer was
smarmy. I just want a phone which works like a phone. The cameras are
useless to me, etc., but I understand someone else might find them
useful. It's definitely clear that the ideas of entertainment and a cell
phone are separate functions in my mind, things I don't value as the
result of convergence. It's also obvious that, yeah, they can challenge
the RIM Blackberry stranglehold in the same way the Apple ][ broke the
mainframe's lock on business.
Others in the group took similar personal, internal lines of response
about what the iPhone represented...but only one guy really got it.
He thought like a consumer. Yeah, the damned thing is stupid, it has no
business plan built around it (and Apple doesn't need one yet, for
Pete's sake!), and it's serviced/hampered by yet another uncooperative
set of technologies managed by an American cell phone company.
HOWEVER, when all those young people buy this thing, they're not just
going to demand improvements from the cell carrier. They're going to
demand features from Apple. They're going to demand features, software,
entertainment and educational content be compatible with their nifty,
noisy little brick and they'll demand it from us over the web!
Whew! I'm glad that guy works for us! He saved us from our assumptions.
Bonus: "Opinions" and "Consensus" are masks.
Don't depend on them.
Servers and software are the results of science delivered to a place
where opinions can be formed, not the other way around.
Science has no room for opinion. Science is about performing a test
based on an educated guess, recording the results and testing many more
times while still recording the results. Good science is about taking
your test to the masses and letting them duplicate the tests. When
everyone is done, they can bring their results together.
The validation of the science is if everyone's tests match and the
results are, therefore, achieved repeatably. If they get your results,
you're on to something there!
Note that really well done science resists interpretting the results if
reducing the data becomes a contest between opinions. This creates a
useful filter between what you really know and what you think you know.
Everyone else who tested can use this filter too. Pretty cool stuff, man!
Computer operations, being heavily dependent on scientific method just
to exist, do not leave room for opinions unless the test matrix is
incomplete and, therefore, the results are inconsistent, non-repeatable,
subjective.
The next time you're in an IT meeting and a course of action is decided
upon by the majority of opinions, the consensus, and not any solid,
repeatably obtainable results remind yourself that you're taking action
based on guesswork. Account for that. Be honest to yourself and the
business by admitting that fact. It's the struggle to get good,
repeatable results which can make problem resolution so tough in IT and
it only gets tougher if you forget you're working with opinions, not facts.
|
