This article originally appeared on the BeyeNETWORK.
The other day I was talking to a company about adapting software to their environment. In order to do that, there was a requirement for the manual entry of about 6,000 words and phrases into a master list. I told them that they should get a clerk and enter them. They were aghast at such a proposition. I then told them that I would get a clerk and enter the words. Then we added $25,000 to the price of the project. And – believe it or not – that was just fine with them.
Everyone knows that a clerk costs significantly less than $25,000 to do that kind of work.
This is only a single data point. But times have changed. When I was rising through the ranks as a programmer and database designer, there was a great deal of pride in self-sufficiency. We thought nothing of writing code or doing some data entry in order to get the job done. We took great pride in saying – “we can do it.”
But in today’s world, it seems that there has been a mind shift across the industry. In many places there is no longer an attitude of “we can do it”, there is an attitude of “we can’t do it”. (Admittedly this is not everywhere, but it is wide-spread.)
In the old days we were programmers and developers. Nearly everything that had to be done, we had to do ourselves. There were few software package alternatives in the early days of our profession. Today, the world is one that is dependent on vendors. Where have the programmers gone? Today it is the job of the technician to select and install software, not build software. In many shops it has been years since anyone developed a major project in-house. And with the loss of major in-house development, the attitude of “we can do it” has gone.
With software vendors, the modern approach to technology has caused the need to write software that is universally applicable. This means that when the software vendor writes the product, they must take into consideration every contingency. This cannot really be done, because all contingencies cannot be foreseen. So upon implementing software in his own shop, the technician will be offended when he must modify it to meet his needs.
In particular, the technician seems to be averse about adding keystrokes. It is OK to point and click. But keystrokes – that’s a different subject entirely.
Now if we were talking about massive numbers of keystrokes on a regular basis, I think the technician would have a valid complaint. But for a few keystrokes here and there, what’s the problem? Even for a one time event of adding many keystrokes, what’s the big deal? But the technicians think that it is their job to avoid ALL keystrokes anytime, anywhere. They expect the software to eliminate the need for keystrokes.
And in doing so, the technician has turned into an “I can’t do that” type of person.
What? You want me and my user to do some keystrokes? We can’t do that here!
There is no longer great pride in what we can do; it seems there is great pride in what we can’t do.
And that great pride extends to other arenas.
As an example, consider the classical vendor sales presentation. The vendor visits the company and starts to talk about their software and what it can do for them. The technician’s role in this time honored exercise is merely to listen and select the software vendor after challenging the vendor on every pertinent issue.
Some of these issues are:
- “We have another product that does the same thing.”
- “We can program that. Why do we need the product?”
- “How much memory does it take? What kind of processor does it require?”
- “What kind of performance will it have?”
These questions are legitimate. If the technicians are truly interested in the product, they need to have these questions answered.
But more often than not, these questions are used to challenge the vendor’s software and serve no useful purpose. The technician is falling back into the “we can’t do that” mode.
(Note: the software vendor/technician proposition that has been described is truly independent of the product or the vendor. This scenario happens for almost every software vendor, as a regular part of doing business.)
So times have changed. That’s no surprise. But there are moments when this old fogey wishes these were “the good old days” when people had the “we can do it” attitude.
Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations. Bill can be reached at 303-681-6772.
Editor's Note: More articles, resources and events are available in Bill's BeyeNETWORK Expert Channel. Be sure to visit today!