Here's another Blazingly Obvious issue which stems in part from reality and another part from the TechNation podcast episode i commented on in my previous post: it is not enough to look at the problem at hand, you have to understand the system of which the problem is a part.
Case in point: One of my Favorite Customers called me about 90 minutes ago. Their banking transfer program had gone and locked itself. Again. No money, no fun, but a lot of stress. I'd spent half of last week's thursday there helping them to fix what was essentially not their fault. Nor the fault of the bank, or the poor bank system techie on the other side of the line. It was just that the software had bugged, which caused the passwords to go out of synch, thus locking my customer's banking access account (it would have been nice if the program had actually gone the length to actually inform that *this* was the problem -- now i had to use Wireshark to sniff the transaction from the wire and talk the techie through a bunch of TCP :) Yesterday my customer got new passcodes. Money flowed and there was much rejoicing. Today, the buck stopped. When i arrived at our customer's office, my contact person was having a tangibly tense communication with another banking techie. With much frustration, she entered those passcodes again and *poof*, the system worked. What nobody at the bank, or the office, had thought of was that there is another installation of the transfer client installed on a server, which is scheduled to run each morning to get yesterday's transactions. We deduced that it was this bit that caused the account to lock and my customer asked me to disable it since nobody knew how it should work and the bank techie just pointed fingers at the software developer company. But why throw away a useful, albeit broken thing, when you can fix it? By the way the software itself was operating, it had looked to thew customer like it was something of a central installation to the whole office; fix the problem at one station and you have it fied everywhere. Not so. Those same passcodes needed to be entered in each installation of the software. The problem was that neither my customer nor the banking techie knew where those passcodes needed to be punched. But with some calm breathing and considerate reasoning, we found where the on-server passcodes should go... and presto, normality was restored. Lesson: don't throw away a thing because it doesn't work. And if the system doesn't work even if you fixed the broken bit, maybe you haven't fixed the right broken bit just yet!Tuesday, 22 December 2009
Feasile, viable, desirable
I just had a flash of enlightenment, having listened to the TechNation podcast edition of the Grand Challenges summit panel (Rick Miller, at 19:07--20:38). The three pillars, if you wish, of any Thing to succeed -- a Thing being an idea, a movement or an actual physical item -- are these:
Feasibility
Can we do it? This is an engineering question. Is it technically possible to create this Thing, even in a lab. Engineering education traditionally focuses focuses on more or less solely this pillar, ignoring the following one:
Viability
Should we do it? Is this Thing really Worth Doing at this space and time? For this Market? This is a question for the Entrepreneur.
Desirability
Will anybody want your Thing? Will they care? Will they be excited about it? Really be moved and shaken to the "I. Want. That." level?
These three attributes need to happen simultaneously for the Thing to Happen. I believe the iPhone and the Grameen Bank serve as pretty good examples. But i also believe our schools do not focus enough on throwing light on each of these three pillars, and i do know i haven't always been very observant of them.
Here are my two cents (approx US$0.03). If you focus on any one of the three pillars, you are a geek. If you consider only two of them, you are a dreamer. But if you can take all three into account, you will be successful.
Friday, 18 December 2009
Subscribe to:
Posts (Atom)