Extra-Cubicular

How to fix IT

2008-07-19T21:45:00.006-05:00

"But the consumers at home are also our employees at work. And when they arrive at their desks, they bring a new set of expectations that have been shaped by their experiences with the Internet, cell phones, email, mobile hand-held devices and iPods. These and other innovations have changed the way they consume and interact with information."

- Daniela Barbosa in "The Taxonomy Folksonomy Cookbook", available at http://solutions.dowjones.com/cookbook

One thing is certain: if Information Technology departments continue to perpetuate the status quo - if they continue to conduct business in the way they always have - the problems I discussed in my previous post will be exacerbated; the general utility of IT will continue to decline. In order to break the cycle, IT must change from within. As I said before, this is psychology, not technology.

IT must adopt a decentralized approach and architecture.

the act of processing information not the sole purview of IT

Core IT staff focus on providing api's, security, data models and business rules.

Core developers working on corporate-wide applications; ones that will be used by nearly everyone in the organization.

Developers working on specialized apps that require read-write access to the core databases.

Developers working on specialized apps that add or improve on existing data.

Developers working read-only apps, local annotations, and reporting.

Push information processing tasks toward the user.

Utilize department-level programmers. These are the people who are outside of the purview of the official IT department, yet still know how to build basic applications. In any organization of appreciable size, they're already there and they are eager to show what they can do. Allowing them to work will alleviate much of the load on the core developers.

Give users generative tools that will allow them to solve their own problems. Just like the availability of word processors destroyed the notion that typing was something that happened inside of the typing pool, appropriate tools would destroy the notion that programming is something that happens exclusively inside the IT department.

Graft onto existing, known tools. Organizations are run via ad-hoc, user-created spreadsheets and documents. We need to figure out how to use these documents as interfaces into systems, rather than containers of data. For example, if a copy-and-paste operation could be treated as a pointer to a bit of data, a document created through a series of these operations would become a living document that would update itself whenever those data sources changed. Users have caught on to what copy and paste does; they will understand the difference between that and a pointer to live information, given the right training.

Training. We do live in the Information Age and ignorance of the basic tools of such cannot be accepted. In addition to basic computer knowledge and system-specific training, some users need to be trained on high-level information processing issues. Things like:
- How to recognize when a task should be automated.
- What kinds of tasks can be automated.
- How to use the tools available to them to solve their own problems.

Flexible tools & systems.

Ontology is Overrated

Allow for annotations, tagging & user-generated customizations.

Make all data searchable from outside the application.

Allow data to be remixed.

Allow data to be easily extracted.

A few years ago Nicholas Carr wrote "Does IT Matter?". While I feel that the provocative title is somewhat misleading, I have to agree with his conclusions. As it is practiced today, IT is too inwardly-focused, too unwieldy and unresponsive. Most IT departments seem to think that the next multi-million-dollar rollout is going to be the silver-bullet panacea that will fix their problems. That just isn't going to happen. IT's current problems are systemic and to paraphrase Albert Einstein, they won't be solved with the same level of thinking that created them.

What is wrong with IT?

2008-06-14T23:01:00.002-05:00

"History never repeats itself; at best it sometimes rhymes."
- Mark Twain
"Those who cannot remember the past are condemned to repeat it."
- every history teacher that I've ever had

We now stand twenty-five years into the PC revolution, give or take a few. It has fundamentally changed how we work and play, do business and government. It was the platform that enabled the communications upheaval that we call the Internet. Yet, despite everything that has changed, the IT department at your average company has remained fundamentally static. Sure, the machines in the glass cages have quad-coloured logos instead of blue-lettered ones. Sure, the company's desks are populated with devices that can actually process information, rather than mindlessly display green characters. Sure, different technologies are being used, but the mission, mandate and structure of your IT department has remained the same: to be the keepers and providers of all computer-related technology in the company; a centralized point that all information-processing activities flow through.

When computers first entered the business world, they were behemoths that required constant care, feeding and grandmothering in order to limp along. Thus, the IT department was born. The people responsible for the care of the original beasts were, by necessity, very sharp, extremely intelligent and very anal about their children. They had to be. Before lithograph techniques could abstract away logic gates and transistors, every bit meant another wire attached to multiple tubes (later transistors) and every single one of them had to work. Even one malfunction would bring the whole apparatus to a standstill. Thus the requirement for intelligence and thus the drive to keep control of the entire system.

Today, IT departments can only be described as beleaguered. User demands are skyrocketing – exponentially. Organizations are collecting more and more data and the users want that data re-formatted, related, reported, re-purposed, in more locations, on more devices and so forever on. In the face of these demands, the typical response is to circle the wagons. A standard answer of “six months and $50,000” is given to even the most basic requests, in the hopes that those requests will simply go away. In practice, the requests usually do go away, although the requirement that sparked them doesn't.

This has left users to get on as best as they can. In the face of unresponsive IT departments, users create ad-hoc documents and spreadsheets and plug in vital corporate data. They have to copy and paste information between multiple applications. They create and set up “rogue” bits of infrastructure – programs, databases, servers. They co-opt database fields intended comments for other data. Entire careers are spent moving chunks of data from information silo to another; the digital equivalent of manual labour. It doesn't take long for an organization's users and its IT department to be enclosed in two different, yet intersecting spheres of data.

To be fair, the blame for this situation cannot be placed solely at the feet of IT. Computer knowledge is the only domain I know of where people are actually proud of their own illiteracy. Supporting these users - dealing with those who seemingly refuse to learn the tools they use on a daily basis - puts IT staff on the defensive.

The history of computing has cycled between open, generative systems and closed, locked-down controlled environments. Until very recently, the enterprise world has defined the state of the art, but that is no longer the case. The freewheeling cowboy-coders that brought us Web 2.0 have shown us a better way of handling information – one that is closer aligned to how that information is used. To paraphrase Bruce Schneier, information-handling is a critical task that is intertwined throughout all of our lives, and it is one that is too important to be pushed away and left in the hands of a small circle of experts. IT must make a fundamental change that goes beyond switching tools or services. This is psychology, not technology. For an IT department to be worthy of the title, it must go beyond being stewards of systems and take a holistic view of how information is used throughout the entire organization.

Killer Apps and the Semantic Web

2008-04-27T23:35:00.000-05:00

Regarding the killer app for the semantic web – I think that it's a mistake to look for one. The semantic web is a 'foundational' technology – a building block. It is highly generative, but doesn't provide much value until something is built with it. The layperson will look at and ask “What use is it?” - a sentiment that I heard expressed in reference to both personal computers and the Internet in their early days.

I hope that a killer semantic app doesn't emerge. If one does, that app will dictate the style and flavour of the first generation of semantic web applications. One huge success will spawn hundreds of imitators, but they will only be imitators. Only after those imitators fail (and/or coalesce) will other ways of using semantic web technology be considered (a pattern that I've seen repeated many times).

Rather than a single 'killer app', the semantic web first needs to permeate existing applications and systems. This will form a primordial ooze of rdf data that will allow a 'semantic ecosystem' to emerge. The value promised by the semantic web is predicated by a mass of available semantic data. If that mass of data doesn't appear, or if access to it is tightly controlled by restrictive policies, the semantic web will be hamstrung and won't likely have much of an impact. Fortunately the age of openness is upon us and the exponential value of open api's and data is readily apparent, so I don't think that this will be a problem.

Email Sucks

2007-11-11T18:22:00.001-06:00

Email sucks. It's an information black hole. Information goes in, but doesn't come out.

OK - here's an example of what I'm talking about:

From: MyBoss
To: Peon Programmer
Subject: project update

I looked over the site and I am impressed by the progress you have made. Please make the following changes:
1. Increase the font size of the text boxes.
2. Change the background color of the second page to blue.

Pty H. Boss

Now suppose that I don't get around to making these changes when I get this email. A few days later I go searching for project revisions. Here's a small portion of what I see:

+ Today
[ 11/11/2007 ] Check out this video!!!
[ 11/11/2007 ] Weekly meeting update
[ 11/11/2007 ] Developer Den Newsletter
[ 11/11/2007 ] Today's Specials at the Hardware Hut
[ 11/11/2007 ] U free for lunch?
+ Yesterday
[ 11/10/2007 ] HTML Hacker's Missive for 11/10/2007
[ 11/10/2007 ] Company News
[ 11/10/2007 ] Group meeting today at 3:00
[ 11/10/2007 ] Shipment # 947104 is in

... and that's assuming that my spam filter is 100% accurate. This is a rather contrived example - in reality each day's list is easily five to ten times as long and we're all tracking multiple projects and situations instead of just one.

Email has become the default method of information transmission because it is expedient and ubiquitous. However email seems to be the point where information looses it's context - where a bit of information looses it's connections to other bits of information that gives it relevance. All of these chunks of disconnected data are then presented to the user in a homogeneous mishmash of spaggetitized factoids.

Everyone's inbox is chock-full of data, but none of it is accessible as information. Stand back an arms' length from your inbox. What can it tell you about a specific project or situation? Pick a message at random. How does that message relate to any of the others? These questions cannot be answered but through manual means. This information to do so is there, but it is obscured.

We need a new messaging paradigm - one that takes into account relevance and context. RSS is a good start, but when you have the 37 Signals guys still picking email over RSS, it shows that RSS still has a ways to go. Hopefully things will change soon.

History-based authentication

2007-03-17T15:49:00.000-05:00

Well, after reading Saul Griffith's column “Who wants to be an Inventor” in the latest Make magazine, I got inspired. Here's an idea that has been echoing around in my head for quite some time. Enjoy, critique, criticize – it's all good.

Digital authentication schemes are currently based on four things: what the user knows, what the user has, what the user does, or what the user is. Yet there is something else we can use: the user's history (I couldn't think up a catchy “what the user ...” saying for this one). We use our interpersonal histories to recognize each other in our day-to-day relationships. Imagine talking to someone who looked and acted exactly like a good friend, but had no knowledge of any of your previously-shared experiences. Authentication based on history has become a Hollywood staple – usually when some malevolent lifeform has taken over someone else's body. How does the hero find out if someone is friend or foe? By asking about their history.

Enough theatrics. Here's how it works:

When the user's account is set up, the server generates a block of strings. Each string is a series of random characters sufficiently large enough to be difficult to guess, and the block is long enough to protect a suitable number of the user's sessions. The server stores this block, and the user receives a copy as well.
The first time the user attempts to authenticate, the server randomly selects one position out of that user's block and requests that position from the applicant. The applicant's client looks in the user's block and sends the string residing in that position to the server. If the string supplied by the applicant matches the string held by the server, the applicant is let in. The server then generates another string and sends it to the user. The user's client replaces the previously requested string with the newly-generated one, and acknowledges. The server then performs the same replacement, and notes the position that was used.
The next time the user attempts to authenticate, the server requests two strings from the applicant: the one at the position used in that user's previous session and another one chosen at random that has not been used before. Upon successful authentication, the strings in both positions, in both the user's block and the server's block, are changed to random ones generated by the server.
From then on, when a user attempts to authenticate, the server requests two strings from the applicant: one that was used in the user's previous session (this will actually be the string generated during the user's last session) and another string that has not been used yet. Each position is changed upon successful authentication.
If the strings supplied by the applicant do not match the strings stored by the server, access is denied. The account should then be locked and steps should be taken to authenticate the user through manual means (telephone call, ID check ...)
When each position has been used, the server can either:
1. Forget which positions have been used and start the process over again, using the same block of strings. (least secure, but easiest)
2. Re-start the process by using the same block of strings in the same order. This would require the server to remember the order in which the strings are used.
3. Re-initialize by creating another block of strings and sending the block to the client.

The chief advantage of this scheme is that it gets stronger the more often it is used and the more places it is used in. Regular password-based authentication gets weaker with more use and more locations because every login represents an opportunity for the user's password to slip into someone else's hands. For example, suppose a user's home computer had become compromised with a keylogging trojan. Once that user logs into a password-protected web site, that account is compromised. Both the legitimate user and the intruder are then able to access that account. Then we can only hope that the intruder moves on before doing too much damage, the user changes the password, or the server detects simultaneous logins and acts on it.

However, if this scheme was in place the damage would be prevented, or at least mitigated. Suppose that some nefarious individual managed to obtain a user's login credentials, including a complete copy of the user's string block. One of two scenarios would occur: if the user logs in before the intruder does, the legitimate string block is updated, rendering the intruder's copy obsolete and useless (remember that the server will ask for the string given out in the user's previous session). If the intruder logs in before the user does, he will be able to access that account until the legitimate user comes back. At that time the account will be frozen, and the user's login credentials will have to be re-established (after manual authentication checks are done, of course)

This scheme actually performs two tasks – authentication based on information previously exchanged, and it detects compromised accounts. It would be best used as an extra layer of security, run in the background after a regular password check, to create a two-factor authentication scheme.

The primary disadvantage of this scheme is that it gives the user another security credential to manage. The user's block of strings would have to be stored somewhere (encrypted, of course) and would have to move around with the user. A USB key would be the natural choice, but that comes with a host of it's own problems (lost, stolen, file corruption). However, when compared to other two-factor authentication schemes out there, this one is nearly as secure as a SecureID token, but without the hardware expenses, and better than fingerprint or facial recognition, which are unreliable.

2007-02-25T13:35:00.000-06:00

Entrepreneurs and system designers are both admonished to ensure that their creations address a specific need. "See a need, fill a need" as Bigweld would say. Yet this vision of development needs to be compared to the two greatest revolutions in information-handling of our time: the personal computer and the Internet. Initially, neither of them addressed a specific need. Let me re-state that: when they came into prominence both were solutions in search of a problem, and were described by many as such. However both of them gave users the tools they needed to solve their own problems.

The rest, as they say, is history.

Architecture and Politics

2006-12-20T00:13:00.000-06:00

Mitch Kapor (wikipedia bio) is famous for saying "Architecture is Politics". I never really understood what he meant until now.

In today's organizations, information is the currency of power. System architecture determines who can access what data, how, where and when. That is politics. It is embedded into the design process itself. Every system begins it's life as a document that specifies what that system will do and how it will do it. Great effort is expended at this point in an attempt to 'cover all the bases'; forecast all possible ways the system will be used. The underlying assumption is that the ones doing the designing are the only ones who will determine how that system will be used. That concentrates the decision-making and access to information in the hands of a few, and that is politics.

This approach comes with many problems, not the least of which is that the capabilities of the system are limited to the imagination of it's designers. No team, regardless of the abilities and brilliance of it's members, can predict all the ways a particular system, or the data it contains, could be used. Current development methodologies demand that they try, and when they fail, the system becomes a limiting factor to it's users rather than an enabler.

A core principle of Web 2.0 is "Harnessing Collective Intelligence". This needs to become a core principle of corporate applications as well. Everyone in a typical organization, from delivery boy to president, has information that could be potentially useful. Capturing and processing all of this information would be a major strategic advantage for that organization.

The Virtual Window

2006-11-27T19:53:00.000-06:00

What if … video conferencing was as simple as talking to a neighbor?

The virtual window is an interface-less video conferencing system. The goal of this project is to simplify video conferencing by stripping it down to the bare essentials - only what is needed to move video and audio from one spot to another. Two stations – back to back – each one continuously displaying what the other is recording. No selections to make, no sessions to start, just walk up to it and start talking. The user's natural actions become the interface to the system. When the station isn't being used it acts like a webcam, providing a window into another space.

This should be set up in some sort of common area – like a hallway. The combination of simplicity and accessibility would allow for more collaboration and better communication. The virtual window effect would also create a feeling of closeness between the two sites.

More on the Semantic Web

2006-11-02T04:10:00.000-06:00

I'd like to expand on my last post. Consider the following:

Or this:

And compare it to this:

The first two examples are pretty easy to interpret because they stick to conventional methods of representing data. This is done through a number of ways: proximity, position, shape, color, etc. In the first example, each dollar figure is associated with a unique year and quarter, simply because of it's position in the spreadsheet. The icons in the second diagram are associated with their labels through proximity - we can easily see that the computer in the upper right has an address of 10.0.0.2, and is not a router.

The third picture is tougher. All we can really say is that it is list of alpha-numeric strings with one highlighted. What does the highlight mean? What is the significance of the numbers? There is no way to tell because there is no context available to give relevance.

These examples illustrate the difference between data and information. Our brains look at the first two diagrams and immediately recognize a spreadsheet and a network diagram. It is our own familiarity with these methods of representing data that allows us to extract information from what is actually a grouping of letters, numbers and symbols on a page. Without that familiarity, the first two diagrams would be as incomprehensible as the third.

This is why I'm so exited about the Semantic Web. I see it as a way to give data true meaning, independent of human conventions. Nowadays, data within a system is represented according to conventions known only to that particular system itself. Any exceptions to this are far and few in between. One system's representation of a telephone number will not be recognized by another. In fact, a telephone number wouldn't even be recognized as such, just as a sequence of numbers.

Now - what if a system could truly understand the data that is was processing? What if all of the atomic bits of data floating around an organization - part, invoice, job and all kinds of other numbers, names, addresses - could actually be recognized for what they are? This is what the Semantic Web does - it identifies data as information. It's a foundational building block that could take us beyond the simple storage, transport and presentation of data to true understanding of what that data means.

The Semantic Web - Wow!

2006-10-31T22:44:00.000-06:00

Well, I discovered the Semantic Web this past weekend. I was amazed to see how well it dovetailed into my thought patterns as of late. While the information I found was specifically geared to the Web and globe-spanning networks, I can see huge potential for it to be implemented inside the average corporate network.

Considering user-created spreadsheets, the data they contain, and the separation between them and corporate databases: what if you used RDF (wikipedia link) to link them? A spreadsheet naturally provides very definite delineations (ie. cells) and contains very definite, processable information (sales figures, measurement readings, part numbers, etc). If there was some way to map spreadsheet cells to database fields, they could update each other. As I understand it, this is what RDF was designed to do.

Of course, this could be extended far beyond simple spreadsheets. RDF is billed as a method of "saying anything about anything", so it should be able to cover the whole gamut of places information can hide in your average organization. The Semantic Web seems to be the ultimate in middleware - perfect for the world of disparate systems. I guess if Tim Berners-Lee is working on the same problems that I am thinking about, I shall consider myself to be in fine company.

2006-10-19T00:07:00.000-05:00

I've been thinking about this post for months, and I've started it probably three times. I've always stopped because I just can't get it right. Well, in the interests of moving on, I'll just spit it out.

The scope of tasks performed by IS departments do not match the usage patterns of information in the organization.

What I mean is this: IT departments are so concerned with business as usual - maintaining the network, tending to corporate apps, generating new ones - that they haven't realized that their organizations are driven by ad-hoc spreadsheets, lists and documents that their users create for themselves and use on a daily basis. These expedient documents exist in a domain totally separate from the officially sanctioned world of the corporate IT department. They replicate and extend much of the information contained within official corporate apps, but the process of getting the information into them is entirely manual. And of course, time-consuming and error-prone. Going further, there is a lot of very useful date tied up in those documents, but there's no way of pulling it into the corporate infrastructure and using it.

Information silos. We're all busy churning out information silos.

Information silos redux

2006-09-30T14:11:00.000-05:00

Well I thought that I invented the concept. Guess not.

Note to self: Google first,then post.

Information silos

2006-08-17T13:17:00.000-05:00

The information landscape at most companies is dotted with information silos.

What is an information silo? It is a structure that contains the data, processing and interface for a particular system. They are built to address a specific need, such as track sales, customers or inventory, and usually do that task very well. However, there are three problems with information silos:

They are limited to what they have been designed to do.
Their use is limited to their built-in interfaces.
They do not interoperate with other systems.

The recurring theme is that an information silo is limited by the imagination and abilities of its designers – it cannot surpass the vision of its creators. A data system is not like a building or a bridge – it need to be flexible. Users may want a different interface or require additional functionality than what was planned for. The data contained in an information silo may be needed in other applications or systems.

Users can usually cope with data silos by copying data from one application and pasting it into another. This is inefficient and covers up shortcomings of the original design.

Programming is no longer an esoteric skill

2006-08-07T17:38:00.000-05:00

es·o·ter·ic (adj.)

Intended for, or understood by only a particular group.
Of or relating to that which is known by a restricted number of people

Unintended consequences and unforeseen ramifications are absolutely fascinating. One that has caught my attention lately is how the craft of computer programming has been transformed from something arcane into nearly-common knowledge. The skills that used to be the exclusive domain of the hardcore geek can now be acquired by anyone with a passing interest.

During the first generation of computers, programming was synonymous with assembling. Hard-wired logic circuits gave way to stored-procedure computers and the discipline of computer programming was born. The size, cost and complexity of these computers limited their deployment to large companies, government departments and other institutions. Unless you worked for a large organization that had the resources and need for one of the original behemoths, learning how to program was an avenue that simply wasn't available to you.

The personal computer revolution of the early 80's changed that. The physical availability and utility of desktop-sized computers drove the demand for programmers. However the difficulty of programming these cantankerous machines limited the skill to the gifted and truly dedicated. Learning how to program usually meant spending much time and effort, not to mention money on books and courses.

The explosion of the Internet has further demolished the barrier of entry to a speed bump. In retrospect, it's easy to see how and why this happened, but I don't remember anyone talking along these lines ten years ago. The first denizens of the Internet were the tech people, including legions of programmers, and they talked about what they were passionate about - technology. First in newsgroups and IRC, then on web-based forums, portals and blogs. Requests for help, discussions (and arguments!) about the relative strengths of particular languages, conversations regarding algorithms and techniques, how-to articles and tutorials, accessible documentation - all of this incessant chatter has resulted in the creation of a huge body of knowledge, much of it related to programming. Search engines index this information and serve it up to the user on a virtual silver platter, on demand. Today, if someone wants to learn how to program, he doesn't have to go to university for four years, he can teach himself by reading tutorials, referencing documentation, participating in forums and practicing on his own.

In some ways, programming knowledge has mirrored that of the Open Source movement - it's a skill that has moved from the cathedral to the bazaar. What used to be restricted to a few is now available to all. However, I believe that the culture of the computer industry has been slow to catch on to this. For the most part, we still want to operate as if the members of the inner circle, commonly referred to as "the I.T. department", are the only ones that can be entrusted with the keys to the digital kingdom, and we operate as if we are the only ones possessing knowledge of how things are done. Witness the rise of what I call 'departmental programmers' - people haven't been trained as programmers, don't have formal degrees, aren't members of an I.T. department, yet are out there creating web apps, Access databases, extensive VBA macros - tools that their co-workers want, need and can't get out of their highly centralized I.T. infrastructure. The emergence of this role is a direct, yet unforeseen, result of the programming information that has been made available via the Internet.

Our professional culture has not yet come to grips with the fact that our precious knowledge has escaped our grasp, and is permeating through the unwashed masses we know as 'users'. We don't want to believe that the value of our skills has decreased, as if the laws of supply and demand don't apply in the cerebral realm. Yet we are going to have to contend with these facts, and change because of them. I believe this will be one of the great challenges our industry will grapple with in the next five years.

The value of knowledge is proportional to the effort it takes to acquire it.

Enterprise 2.0

2006-08-07T16:00:00.000-05:00

I've got a series of posts running around my head that I'm going to call Enterprise 2.0. In short, I believe that the way information is handled and delivered must change in some subtle, yet fundamental ways. I'll identify the converging trends that spur these changes and the unacceptable conditions that currently exist. These posts will pertain mostly to I.T. professionals working in formalized computer departments, but the concepts will apply throughout the computer industry - from the single-person home office to globe-spanning networks. I will be calling for changes in approach and culture, but I believe that they would yield significant benefits for the organization to implement them.
Ladies and gentlemen: Enterprise 2.0

Automated cash counting in retail

2006-07-30T13:31:00.000-05:00

I have often read about how Wal-mart is a leader in the use of information in its day-to-day operations. I was surprised (and a little shocked) to see yesterday a checkout clerk manually counting change in a cash drawer. This struck me that this is a time-consuming, error-prone task that would greatly benfit from being automated. Change counting devices are used by banks and casinos, so they must be accurate. Instead of manually counting out the coins in the drawer, the clerks could dump their cash drawers into a machine where they would be automatically counted and sorted. Each dump would be tied to a specific clerk and shift. The store could protect itself from inaccurate counts by correlating to the sales tracking system. In the event of a discrepancy, the coins could be run through the machine again, or counted manually.

Software names that must DIE.

2005-12-27T20:28:00.000-06:00

Alright all you programmers out there - there are a couple of application naming patterns that simply have to be killed off. Swiftly. And Without Mercy.

1. Yet Another {software type}
Puh-lease. This kind of name was clever (maybe) the first thirty times. We're years past that point. If you're smart enough to learn how to program and put together an application that someone other than yourself may be interested in, then for the love of all that's holy, please put some thought into a name that's original yet descriptive.

2. {program name}'s Not {another, more popular program name}
This is simply an pathetic attempt at software name-dropping. If you feel compelled to point out, in your program's actual name, that it isn't another program, it's going to be pretty obvious to us mere mortals (everyone not on the development team), that they're going to be functionally identical. Not only do you need to put more thought into your application's name, perhaps you need to think up an application of your very own as well.

3. Any title that includes the programmer's name.
Look, I know that coding is far from glamorous. Finishing off that database access class rarely coincides with thunderous applause, knowledge of design patterns seldom earns the adulation of the crowd, and hot women that swoon for those who can crank out database-backed web sites are far and few in between (if any of them read this, EMAIL ME). Face it, a programmer can realistically only desperately hope for a couple minutes of fame, rather than fifteen. But straining for those few minutes by naming your program after yourself is really, really, sad.

4. Programs that start with “K” or “G”
Don't, don't, don't get me started.

5. Names without any vowels (sometimes appended to 'lib')
Perhaps 'libmxyzptlk' makes sense and is easy for you to remember, but it sure isn't for the rest of us. When someone is shoulder-surfing and asks “What's that application that you are using?”, it's a lot easier to answer if the name can be formed by a human tongue.

Thoughts and ruminations on Google Base

2005-11-20T21:55:00.000-06:00

According it's home page, Google Base "is a place where you can add all types of information that we'll host and make searchable online." Hmmm – that sounds like the Internet itself. What's to differentiate it from plain old web page?

The most fundamental difference is the structure and format of the information itself. The smallest atomic unit of the web is an HTML document, which can contain one or more units of information (whether those units be products, messages or paragraphs). Google Base is much more granular – each information unit is itself itemized. Each item in Google Base can also be described in terms of labels and attributes. Web pages can be described, via the meta tag and in the HTML itself, but Google Base formalizes the approach for doing so.

Google Base is a very 'low level' service. In fact, it's barely a service at all. Evidence of it's rawness are everywhere. Browsing through the 'products' link leads to a page that expects the user to specify the product type with a single dropdown list. However as a platform, a foundation upon which to build new services and applications, it's potential is immense. Most web applications have a searchable database at their core. The lowest mark that Google Base can shoot for would be to become a great place to prototype and launch new network services. The greatest would be to unleash a tidal wave of Internet applications that shift even more of our day-to-day activities onto the Web.

Google Base is a foundation, but to become more than that, additional building blocks are going to have to be added. Given Google's past history, it is reasonable to assume that they will soon release tools that will allow people to build upon it. A good first step would be facilities to set up a customized search box, or perhaps an AJAX-powered grid view of your items.

I now see Google Base as a kind of "primordial goo" for the next generation of Internet applications. Maybe we'll call them Web 2.5 or 3.0 or something. I can also see a kind of double entendre in the name – base from database ( which it is) and base as in an underlying element. We'll have to see what crawls out of it.

Fighting Phishers

2005-10-12T20:10:00.000-05:00

Introduction
The practice commonly known as ‘phishing’ continues to be a significant problem to consumers and online businesses alike. It causes tangible financial loss to its victims and damages brands and reputations. Many solutions have been proposed and implemented, ranging from customer education initiatives to dedicated email monitoring and response centers. While the latest data from the Anti-Phishing Working Group suggests that phishing may have plateaued for now, it still remains a major issue.
This post proposes to combat phishing by giving companies a simple method to allow their customers to easily and reliably identify authentic email messages. The advantage of this system is that it requires less technological expertise of the end users than current message identification techniques, and the additional load on the implementing organization is minimal.
Problem
A ‘phish’ is an email message that is sent to someone in order to entice them to reveal personal details, which can then be used to defraud the user or sold to someone who will. These messages purport to be from an online company, commonly Paypal or other financial institution. The ‘phishes’ are carefully crafted to be realistic and believable, usually modeled after authentic messages and containing graphics taken from the company’s web site. It will usually contain a link to a web site that looks legitimate, but sends the customer’s data to a con artist rather than to the company.
Analysis
The phishing problem is really one of mistaken identity. The identity in question is that of the sender of the email message. When a message claims to be from someone and has their graphics embedded in the message, in the mind of the consumer, it is reasonable to assume that the message is authentic.
Solution
An organization can protect itself and it’s customers from phishing with this easy method: it must first provide a method to obtain and store a passphrase from each of its clients that wants to participate. In most cases, this would involve a small addition to the section of the web site that stores and updates the customer’s account details. The passphrase itself would have to be one that the customer will recognize in the future. Thereafter the organization would then customize its outgoing email to include the user’s own passphrase in the text of any messages is sent out to its participating customers. The presence of the passphrase would uniquely and reliably identify the organization to the customer, since presumably only the two of them would know what it is.
Strengths
The simplicity of this method is its greatest strength. Customers only need to check an incoming message for the presence of their own passphrase in order to verify its authenticity. This is far simpler for the customer than current URL validation techniques that are currently recommended.
This procedure is similar to the username/password authentication scheme that consumers are already familiar with, except that it works in reverse, authenticating an organization to a consumer. Normally it would be unreasonable to expect consumers to manage and remember email passphrases for all of the web sites they deal with, in addition to all of the user names and passwords they have to remember now. The difference here is that a password needs to be memorized, while a passphrase only needs to be recognized. Seeing their own passphrase printed in an email message would provide a memory cue and would help consumers to recognize their own. It is easier for one to see a passphrase and accept or reject it than to remember a password without any hints at all.
This method has the added benefit of having minimal implementation requirements. A small addition to the account management section of the website would allow customers to set, view and change their own passphrases. Most large organizations are already processing outgoing email messages to include the customer’s name; adding their passphrase as well would be a simple extension of this process.
Weaknesses
The biggest weakness to this method is that the passphrases will be transmitted across the Internet in unencrypted form in email messages sent out to the users. If a phisher somehow gained the ability to sniff an organization’s outgoing email traffic, she could potentially construct a database of user names, addresses and passphrases. This would give her the ability to bypass this method and assemble convincing phishes. To mount this type of attack, the phisher would have to gain physical access to the network, or remote access to a host on the network of either the implementing organization or its network provider. Standard network security practices at the implementing organization and their telecom provider will mitigate the risk of this happening.
Conclusion
The procedure outlined in this post gives online organizations a proactive method by which they can fight back against the phishers. In and of itself, it will not totally eradicate phishing, but if implemented properly, it would make mounting a phishing attack exponentially more difficult and expensive. When compared to reactive approaches, such as web site takedowns and mass email monitoring, it offers far greater efficacy for far less effort.

A Communications system for large, outdoor events

2005-10-11T23:54:00.000-05:00

This past summer, I took my family to a fireworks show. It was held at a local park and the viewing audience was spread over a large area. The fireworks started about 20 minutes late and proceeded in fits and starts. At one point we left, thinking that the show was over, only to see the fireworks start up again after we had left. We heard a number of weeks later that the reason for the interruption was that debris was falling on the spectators and the launch point had to be moved.

The crux of this problem was a communications issue. The show organizers had information they wanted to disseminate (the fireworks will start in 10 minutes, the show will be delayed for 20 minutes), but lacked the facilities for doing so. Their audience was too large, too geographically dispersed and too transient. A loudspeaker was set up, but only a small fraction of the crowd could hear it.

What organizers of temporary shows and festivals need is a communications system that:

is scalable and flexible enough to cover a large but well-defined area.

does not degrade the message as it is propagated

is easy to set up and tear down
as cheap to obtain, set up and run as possible

There is a solution that fits these requirements. A low-power FM transmitter, tuned to an unused frequency, could be used to broadcast announcements. People in the crowd could then listen to the announcements using their own FM radios.

Coverage

FM transmitters routinely broadcast their signals over city-sized areas so covering an area the size of a typical outdoor event wouldn't be a problem. If short-range transmitters have to be used (to comply with licensing requirements, for example) a system of repeaters could be implemented.

Cost

In today's technological landscape, FM radio is positively ancient. It is cheap and plentiful, and there are many people that know the technology very well. I can buy a basic transmitter for $40 and receivers for as low as one dollar. A primary advantage of this plan is that it takes advantage of a resource that already has a very high penetration rate: portable FM radios. You would be hard pressed to find a household in North America that didn't have at least one, and for those that don't, they can be purchased for about a buck at many discount stores.

Ease of Use

Setting the system up would be a matter of unpacking and powering the transmitter and antenna. Repeaters may have to be set up. After that, it's a matter of what is going to be broadcast. It could be as simple as someone picking up a microphone and saying what needs to be said, or it could be a full-fledged radio broadcast (perhaps via a tie-in with a local station).

Licensing

All radio transmitters over a certain size are regulated and licensed, so a temporary license would have to be obtained in order to comply with legal obligations.

Familiarization

Perhaps the biggest obstacle to this scheme would be the public's lack of familiarization with it. People are simply not used to taking their radios to an event to hear announcements. Any plan to implement this system would have to include some way of explaining it to the pubic, most likely included in the advertising for the event itself. The frequency that will be utilized at the event should be considered vital information, along with date, time and location. As with any user-familiarization issue, it would take time and repetition to get the public accustomed to this.

Tech Cycles - Exploration

2005-06-15T22:36:00.000-05:00

{see Tech Cycles - Intro for some background}
The technology cycle starts with a scientific breakthrough in a research lab, or perhaps with the germination of an idea in an inventor's head. This is where discoveries are made, new knowledge is gained and ground is broken. The knowledge required to participate at this stage is specialized and esoteric. The work done is risky and may seem impractical. There is much trial and error involved, and it is inherently inefficient and expensive.

At this phase, it is unlikely that the final direction and scope of the technology can be estimated with any accuracy. Consider the oft-quoted line: "I think there is a world market for maybe five computers". This was from Thomas J. Watson, founder of IBM. His intelligence, acumen and vision was impeccable and unquestionable. The fact that he mis-judged the technology that would eventually power his own company shows how difficult it can be make accurate predictions at this stage.

It should be noted that there may be few, if any, practical applications visible at this stage. The creative process is not deterministic or linear. While there may be little short-term benefit, every organization needs some operations in this phase in order to ensure long-term viability. Those that do not will be supplanted by those that do. A suitable environment is needed for creativity to flourish, and when an organization focuses solely on the bottom line, that environment is extinguished. I believe that the focus on cost-cutting in North American companies has largely killed off creativity and innovation in favor of 'getting things done'. While that may look good on the balance sheets for a while, true progress doesn't happen by doing things the same old way, all of the time. Innovation isn't efficient - but it is critical.

Tech Cycles - Intro

2005-06-15T22:02:00.000-05:00

It seems to me that technology generally progresses through seven distinct phases as part of an overall cycle. The boundaries between these phases aren't clearly delineated - it's more like a gradual progression from one phase to the next . The phases are exploration, pioneering, settling, industrialization, streamlining, plundering and nostalgia. Each phase comes with it's own set of challenges and it is important for us to know where and what kind of innovation is required at each phase.

Welcome

2005-06-12T21:53:00.000-05:00

Hello and welcome here. This blog is all about ideas, thoughts and observations. I will be posting mine here and opening them up to criticism and comments from the world. I do not intend to do news commentary, (lots of other places to get that from) nor do I want to start making predictions. Instead, I want to explore potential and possibilities, to ask the question "What if ... ?". I hope that through this process I will come into contact with forward-thinking people that I can converse with and learn from.
So - if you've ever lost sleep because your mind was whirling around a new idea, if you've ever thought "There must be a better way" and then went out and found it, if your urge to create is more than a desire, but an unstoppable psychological compulsion, then you're my kind of people. Please stay tuned, leave comments or contact me if you wish.

Again, welcome here. More to come ...