Cykod Web Development and Consulting Blog

One of the great things about the Web is that the barrier to entry for a new enterprise is incredibly small - all the infrastructure you need to get started is a $300 computer, a $10/year domain name and a sub-$10/mo hosting plan. Your only limitation will be your own ability create something that will generate enough interest (or money) to sustain it.

Compare this phenomenon to almost any other industry - say restaurants or construction - and it's easy to see why there's a lot of innovation on the web. It's easy to go from idea to execution fast and inexpensively.

The Web has no Captcha

Unfortunately, because of the this ease of execution it means that there's not a lot of friction to prevent crap from getting shovelled onto the web. In other industries the need for physical space, goods and capital before launching into a business acts like a Captcha for innovation - forcing you to look long and hard at what you're doing before dropping a bunch of your or your investors' money and going forward with the enterprise. In developing for the web there's no Captcha - you don't really need to prove that your idea is any good to anyone if you can get it built by paying your neighbour's son $500 (You will get what you pay for however)

This is great in many respects, but there are downsides that people often forget. First, there's a lot of competition. If what you want to do isn't all that innovative, then there are going to already be a couple of thousand people doing it, and your chance of being successful is pretty slim. You'll need to be in it for the long-haul and be willing to iterate on your idea with the experience you get from the initial release in order to have any chance whatsoever of being successful. What this means is that, secondly, if your idea doesn't match up with your interests you are going to have a hard time generating the necessary follow-through to keep working on your idea and make it successful.

Just because it's quick & easy to start something on the web doesn't mean it's just as quick to become successful at it. While there are incredible get-rich-quick success stories (like Chatroulette) there are just as many companies that followed a more standard growth path. Amazon, for example took years, loads of funding and a bunch of changes of direction to before approaching profitability.

What this means is that if you have what you think is a great idea but it's not one that matches up with your particular skills and interest, you need to either find a partner with whom it does match up or pick a different idea.

As a web developer we've been presented with a lot of people's ideas (and been asked to sign one-too-many NDA's), and we've gotten to the point where we're not willing to work on a project if we don't think it has a chance of being successful, even if it's a lucrative project. I'm not just talking about the idea itself, the people behind the idea are much more important - their willingness to continue the project past the first round and put the legwork in to make it successful need to be there for a project to have a chance.

So, if you want to be successful on the Internet, you need to innovate on your strength - the type of project that you build needs to match up with your particular skills, or all the most talented-outsourcing in the world isn't going to help. I'd say there are roughly four different types of Web enterprises out there:

Product-driven, Content-driven, User-driven, Technology-driven

Now there's obviously some overlap between the different types, but these four archetypes are a good start.

1. Product-driven

These are sites whose purpose is to sell something physical. Innovating on a product-driven website means, for the most part, innovating on the product itself. You can obviously dress the site up with bells and whistles and that will help in the short term, but it's the product itself that needs to sell and unless you feel confident that you can provide something unique in the product or the way you sell it, the greatest web site in the world isn't going to help. Furthermore, if you are not excited about the idea spending your time manufacturing product, fulfilling orders and labelling and shipping packages you should stay away (there are ways to streamline this, like fullfillment houses, but if these aren't  problems you want to solve, that should be a warning sign.

2. Content-driven

These are sites that provide generated content to the user - think blogs or newspapers. Functionality is a lot less important than keeping content fresh. The technology running a site like TechCrunch or HuffingtonPost really doesn't matter - it's the attention to fresh and awesome content that drives pageviews and thus advertising revenue on those sites.

3. User-driven

These are sites that exist to allow users to generate content - whether it's a social networking site like Facebook or a communication tool like Twitter.  These will often need to expand functionality to keep up with the demands of users, and spend a good deal of their time responding to users problems, requests and demands. If you aren't excited to interact with your users, you probably shouldn't be doing a user-driven product.

4. Technology-driven

These are sites that people come to because of features of site itself and what you can do on it. Any of your online b2b apps fall into this category, site's that provide E-sourcing solutions, for example, need to have a value proposition that makes them better than using the competition.

So What?

So if you are a Web Developer yourself (like we are), it wouldn't make sense to build yourself a content-driven site if you're not interested in keeping that content up to date. On the other hand building a technology driven site will play into your strengths. You might be tempted to create a user-driven site, but unless the community, monitoring and support aspect appeal to you (hey, not all geeks are people-people), you might want to reconsider.

Now If you're a MBA-type, you probably don't want to create a technology-driven site unless you're going to be able to pay to continue to develop the site once you get the first rounds of feedback. As good as your idea is, you or your developer most likely isn't going to hit a home run on the first swing. Be ready to immerse yourself in the technology of the site for the duration or pick something else.

If you're a passionate quilter, you might not actually be happy building the worlds best quilting community, as that means you'll be dealing with user issues and trolls more than spending time quilting. A product driven site selling quilts or a content driven site that keeps up with the latest advances in quilting technology might be more interesting to you.

If you're a marketer that cares more about innovative ways to sell stuff than actually build stuff, a product driven company is probably a bad idea. SEOMoz and Hubspot both started out as content driven (good for marketers) and then as they gained traction and that ephemeral quality of "Thought Leadership" built themselves products that turned them into technology driven sites.

We would never have built something like GamesForLanguage, a combination of content and technology driven, but heavy on the content part, if we weren't working with two people extremely passionate about developing the content necessary to make the site successful. 

Finding something you're passionate about to drive your startup is really just half the battle, you also need to ensure that the type of company you're building really matches your strengths, otherwise you'll spend all your time innovating on pieces of your business that don't really matter because that's what you'd rather be doing. Innovating on your strength means you'll be building the sort of company you would be happy working in, and since you will be working there a lot.

We've been thinking about the price points for Webiva for a while now, and gotten different advice from different people. Pricing software is a funny thing. The marginal cost of software is negligible compared to the upfront costs.

The perennial free market go to - the invisible hand of supply and demand - makes little sense. Downloadable or SaaS software effectively has an unlimited supply. We must instead fall back onto solely a Price vs. Demand graph, which shows a smooth curve of increasing demand as price decreases.

That idea is, of course, also complete nonsense. As discussion with other entrepreneurs and the excellent book Predictably Irrational demonstrated - the price of a good isn't always correlated negatively with it's demand. Higher cost and perceived value have often have a positive correlation. The first pages of the seminal book Influence: The Psychology of Persuasion tell a story of a assistant who misread their boss's scrawled note to halve the price of some jewelry that wasn't selling and had instead doubled the price. When the boss got back from vacation, she was surprised to see that jewelry that wasn't selling had sold just fine at 2x the price. A higher cost can actually result in a higher demand for your product,  resulting in a feedback loop in the middle of your pricing strategy.

So What's a SaaS provider to do? If you've got competitors, they've most likely already set the "perceived value" price point in your customers mind. You'll most likely need to price it in line with what they are charging. If you're the 'Cadillac' of the space - you'll need to up the price so that people know you're better. If you can make the argument that you're leaner than your competitor, i.e. solve a smaller problem but solve it better, then you can charge less without looking like the dime-store equivalent (See Basecamp). Underpricing your competitor, while it sounds like a good strategy, often begs the question as to why your product costs less (and go ahead and try to explain "0 marginal cost" to people). This is one piece of feedback we've gotten time and time again in discussion with potential customers and other entrepreneurs (This doesn't apply if the space your startup is in has been commoditized - then price is the go to decision maker)

However, of all the pieces of advice I've gotten, there's only been one that's been the most consistent: don't fret too much, you can always change it.

Interestingly enough, I think that's the one piece of advice that I believe is categorically not true. Or only marginally true but with a big asterisk.

True, you have some leeway with pricing, but not as much as you think. The Chargify flareup from Monday made that pretty clear.

Many people (Webiva included) are pretty put off with the changes Chargify made to their pricing announcement (effectively moving us from paying them $0 to $1200 a year) We're put off enough that we're going to extend our open-source Shop module with recurring billing instead of sticking with a recurring provider. We learned our lesson building an important piece of our revenue infrastructure on someone else's beta API. Regardless of what they do next, the cat's out of the bag, they've done it once after all and they can do it again (They did respond quickly in the aftermath, and have added a bootstrapping plan, but for us the decision's been made)

Here's the thing: I personally don't think there's anything wrong with a company changing their pricing. We were put off, but that doesn't mean I blame them. They, better than anyone else, know what they need to do to survive and thrive as a startup. Most likely their previous model just wasn't generating revenue in a sustainable form. The sudden change, however, and lack of grandfathering in existing users, makes it strikingly clear what's theirs and what's yours.

There are difficulties changing your pricing at any end of the spectrum:

• Increase your pricing suddenly and you infuriate your existing users.
• Decrease it suddenly and your existing users will feel like chumps for having paid more.
• Start it low, keep it low for existing users and hike it for new users, and your new users may be aware of the previous price point and ask themselves, "is this really worth that much more than it used to be?"
• Change it either way, and existing customers will automatically be forced re-evaluate your company's value proposition and may decide they no longer need you for that price.

Once your price is set, you've set a jumping off point in your users' minds. This is something that can act as a benefit - Apple, for example, plays the price point game very intentionally and quite perfectly  - but if you don't take this into consideration when pricing your startup's product you're going end up annoying a lot of people and angering your early adopter base, whom you most need to be Earlyvangelist's about your product. Ballpark your pricing strategy correctly, otherwise you might end up with metaphorical Internet torches and pitchforks running up the hill.

Note: this post takes the iterative nature of software development for granted. As a consultant on dozens upon dozens of Web projects, I take it for granted. If you have had great experiences in complicated projects that go from specification to completion without change, I've never met you but I would love to as you sound like a mythically perfect client.

So you've got to get a project done that needs outside help. Whether it's for a corporate site or your next change-the-world idea, the normal sequence of events from this step is probably:

1. Write up a Specification
2. Put out a Request for Proposal
3. Look over the responses
4. Of the responses from reputable looking companies, pick the cheapest

Number four might get more complicated if you are working with companies you already have a relationship with, but the bottom line usually comes down to finding the right balance of price and security. How much are you willing to wager on your project's success to get a cheaper price.

Now let's take a look at this from the perspective of the consultant. I assume most consultants work off a standard hourly rate, estimate the number of hours and other costs (software, hardware, etc) and come up with a quote.

For inexperienced consultants, the number of estimated hours is usually a vast underestimate of the actual time it takes to complete the project. For experienced consultants, it's usually a significant overestimate of the time.

In the former case (and I've been guilty of this) the estimate is based on a best-case-scenario that fails to account for the risks of the project. It's a if-everything-goes-right number. Developers are a cocky bunch and tend to see the world through rose-colored glasses right up until the first bug. In the real world rarely does everything go right, and if the project is done at too low of a number, disaster will ensue.

The consultant will be motivated to triage features on the project because once they have gone over the number of hours estimated, they will essentially be losing money for every additional hour of work time. Since all good software development is iterative, it is a given that there will be new requests from the client based on feedback from prototypes that weren't part of the spec, but are ESSENTIAL to the project being useful when it's all said and done. These will be refused or re-quoted and features that are no longer necessary, but are in the Spec, will be added-in.

Barring a mid-project renegotiation, one of two things will happen: first the project might degrade into an acrimonious battle of wills back and forth as both the developer and client becomes less and less flexible, the former trying to do the minimum as outlined exactly in the spec while the latter holding the developer to features that have no reason to exist except for their presence in the original spec. Alternatively and much more seldom, the developer will eat the costs of the additional time to provide a quality product and a happy client. While this looks like a win from the client's perspective, future projects from the client will either be turned down or vastly overestimated to prevent a repeat. Any changes to the system will need to be done by a new party (and remember, software is iterative so there will be changes), bringing a whole new set of risks into the mix.

Experienced consultants, i.e. ones who have gone through this disaster-cycle a couple of times, will see risks and dangers hiding in every crack of the specification and will base their estimate on Murphy's law, making sure their ass is covered for any eventuality. What consultant, after all, wants to lose money on a project? The risks on the consultant's side: finicky client, non-payment, etc, are just as real on the consultant's side as the clients side.

To sum up, as it stands now, someone who needs a project done has two options:

1. Underpay an inexperienced consultant and count on their goodwill professionalism to complete the project.
2. Overpay an experienced consultant

Neither of those two options should sound particularly good, so what's the solution?

Most projects, from a risk/completion versus time standpoint operate something like this:

The risk is enormous at the start of the project. It falls quickly, however, as any developer worth their salt will try to solve the projects unknowns first and foremost. If you are building real-time stock viewer, you don't build a whole website, membership and payment system before you figure out how to get and the real-time data. Thus a couple weeks into a project, a lot of risk as already fallen by the wayside. Things will either be able to work the way anticipated, or they won't. If you pay a developer hourly for the first couple of weeks, you'll be able to remove a tremendous amount of risk from the process and won't force the developer to quote a number that covers that risk. Since you don't win if the developer underquotes the project (see above), why should you lose if they overquote it?

What if, as an alternative to asking for a quote in response to an RFP, you asked potential consultants for their hourly rate and an estimate on the number of man-hours each of the chunks of the project might take along with a confidence measure of each of those chunks?

While these early estimates will be a little all over the board, you should see some convergence on the number of hours from the reputable shops and you should be able to pick out the outliers on both ends to stay away from.

Now pick a firm on the same criteria you would have originally, but make sure to request a number of smaller milestones with working prototypes. Each of these milestones, coming in at a specific date represents a certain amount of developer time. If the developer is ahead of schedule, they can add features to the milestone, if they are behind schedule then features will need to be removed, but the date for a working prototype is the sticking point.

Provided that you have workable milestones, you, as a client, will have a much better idea of how the project is progressing, and, since you are paying hourly, can iterate on changes as necessary to get the best outcome for the project. If the developer can't deliver the first milestone, it's better to know that immediately and get out of the arrangement as early as possible rather than hang onto that sinking ship all the way down to the bottom of the ocean.

At first glance it might appear that you've shifted the risk of the project from yourself to the developer, but the truth is that the risk was always on you. If the project was under-quoted, you're set up for failure (again, see above), while if it was over-quoted, you'll never see that money back (do you think a consultant who was forced to quote a flat-fee will invoice for less?)

While I've plugged it in other posts, the first few chapters of Head First Software Development from Oreilly gives a great overview of why you should do iterative software development and is very readable by anyone interested in software consulting, not just developers. If you are in charge of hiring or managing software consultants I'd very much recommend you spend a couple hours on it.

So, like I said, you don't want a fixed quote for that project. A fixed quote is heartbreak on a stack of paper. You want a great developer with an estimate, an hourly rate and a number of measurable milestones to take you to that happy place in the ether where software is delivered on budget and on time.

When developing a web app, your app's capabilities are far more important than it's features. Aren't they the same thing? Not in my mind: a capability is something you can do with the product while a feature is something a product can do.

Capabilities are awesome. Features for features sake suck.

The first iPhone was a hit because even though it lacked in the feature department (No 3G, MMS, etc) it let people do things with their phone they couldn't or wouldn't have before. Same with the first iPod. In what has to be one of the funniest-in-retrospect single line reviews of the first iPod, alpha-geek CmdrTaco, the creator of Slashdot wrote:

No wireless. Less space than a nomad. Lame.

He couldn't have been more wrong. We as geeks tend to focus on the features because we think they are important to us, but the truth is that we are users too; what we can achieve with something is orders of magnitude more important than what the product itself can do.

The good news is that there seems to be a strong trend in software development to focus less on features first and rather on user stories.

On of the nice things about user story driven design is that you say "A user should be able to do YYY" and then figure out the simplest way to make that happen.

Feature driven design might say "we should have a web 2.0 interface" and so you spend two weeks creating the perfect developer framework for whatever web 2.0 means - and then the minute you try to add in an additional capability into the site you realize your framework doesn't support what you want to do. It's true at launch time you will get to check the checkbox "Web 2.0" on the back of the metaphorical box but all you really ended up with is code that will need to be supported but isn't at all essential to your users.

Microsoft word is the starkest example of this I've seen. The hell that the Microsoft programmers must go through supporting all the features that no one uses must be a very dark place indeed. I need my word processor to have a very limited set of capabilities:

1. Let me coherently format and style text
2. Let me share documents with other people
3. Let me spell check my work so I don't look like an idot.
4. Let me print my work.

After that anything else that gets added in is a feature I probably won't use. OpenOffice and Google Docs are slowly supplanting Word because they make the user experience better than Word (I'm counting not having to shell out $500 for useless features as part of that user experience) The first version I used of OpenOffice was awesome because it had, right there in the File menu a "Export as PDF". This was a feature - but it made the sharing of documents so much easier that it greatly added to the "sharing" capability - I could email a document and be sure it would look that same way on the person on the other end of tube's computer.

The poster boys for the "less features" community are 37Signals' applications - BaseCamp, HighRise and Backpack in each case they dramatically underfeatured any of the other project management / CRM / intranet suites out there but had all the capabilities that people needed. They also added the capability of "usable by moms and/or CEO's" because their products were so simple and built-on standard web user interface concepts. That's a capability that you don't ever get by adding features - it's something you only get by having solid UX coherency and a lack of confusing and overwhelming features.

If capabilities are so great, then why do we as programmers tend to spend our times focused on features?

Reason one: features are fun. I love coding in new whiz-bang features and I'd bet other developers are the same way. It means I get to walk over to another developer on the project and say "Did you see the sweet new realtime Ajax notification panel I put in?" and they say "Cool" and I feel like I earned my nerd points for the day. Unfortunately if that notification panel doesn't do anything besides add in some eye-candy it's not a win. It's going to be a weight on the codebase that will need to be carried along without adding in real value.

Reason two: far to often project descriptions are in terms of features rather than user stories. Features are easier to describe, more concrete and more estimatable than user stories. This is something that's easily solved though by making sure every feature relates back to a user story. If each feature you're adding in relates back to a user story (e.g. "Sally B. User should be able to login even if she forgot her password" = "Password Reset Feature") then the creepy features won't get in there.

For a great analysis of user stories and how use them to drive your development process I recommend "Head first software Development" from the wildly entertaining O'Reilly "Head First" serious (yes I just called a set of computer books wildly entertaining - once you've read one of the series you'll understand) Despite the title, it's by no means a basic book on programming but actually a great read on the higher level processes involved in making great software.

Remember, focus on capabilities driven by user stories, letting the features generate from the stories and everything will be ok. By the way, did I show you the cool new totally user-driven HTML5 websockets event mash-up stuff I'm working on?

Until I published this blog post I didn't actually believe that twitter was going to destroy our country, unfortunately now I do.

If that last sentence doesn't make sense, let me explain by way of anecdote: I remember having a conversation with a former schoolmate a few years ago at a reunion that went something like this...

Me: Are you still into Dave Matthews as much as you used to be?
Him: Dave Matthews, Naw, I never liked them all that much.
Me: What - that's all you talked about senior year - you literally wouldn't shut up about them.
Him: I think you have me confused with someone else.

Now, assuming my increasingly disappointing memory hadn't failed me - I'm pretty sure he was the obnoxious, over the top DMB fan I remember. Of course a decade plus later, I can't be 100% sure it was him - it really might have been someone else.

If only we hadn't gone to high-school in the bad old days before everyone tweeted, facebook'd (or now buzz'd I guess) their every daily minutia and fleeting opinion, I could have nailed that kid to his over-the-top-pyschofan opinions. What would he have done then? We'll since the "deny it" option had flown the coop he would have been left with two choices:

a. Stay consistent with his opinion from years ago in high-school
b. Cop to his former obsession but admit he has moved on.

The obvious choice would be b - he clearly doesn't feel the same way about the band as he used to - but unfortunately we as human beings have a hard time being inconsistent. We find it repulsive. Hobgoblins notwithstanding, our hatred of inconsistency in our actions and beliefs is explained by a well known theory called Cognitive Dissonance. I've seen a friend stick to provably false "facts" they've written about on Facebook simply because they don't want to be seen as inconsistent.

"The person whose beliefs, words and deeds don't match is seen as confused, two-faced, even mentally ill. On the other side, a high degree of consistency is normally associated with personal and intellectual strength." (p.53, Influence, Cialdini, 2001)

If you can recall back to the 2004 election, one of the prime strikes against senator Kerry (ok, besides his wooden demeanor) was that he was a flip-flopper. This fact was contrasted with GW "stay-the-course" Bush. While in the abstract we might prefer our politicians to be able to take new evidence into consideration and change their minds, in reality we prefer them not to change their minds to often (Remember Doonesbury's reader-chosen characterization of Bill Clinton?) 

If I can get you to make a commitment (that is, to take a stand, to go on the record), I will have set the stage for your automatic and ill-considered consistency with that earlier commitment. (p.59, Influence, Cialdini, 2001)

What is microblogging but an easily-posted, bite-sized, on-the-record commitment? For many of us it's no longer enough to have opinions - we now need to scream them to the entire world. This effectively carves those originally transient opinions into stone and makes us less likely to consider evidence contrary to our stated positions on policy, politics, or whatever.

Since micro-blogging is so accessible - people now post just about anything from just about anywhere - it creates a particularly dangerous combination: a medium that encourages us to make a public commitment based on something we often have only experienced shallowly & fleetingly.  It's less important to a politician that your 100 followers know you "Stand with [Candidate]", than the fact that you made the commitment to post that in first place (and are now more susceptible to requests for money and help.)

By taking public positions too early (sometimes years early - e.g. "OMG [Politician Name Here] is the greatest [s]he'll be prez in 2012!!!!!" ) we deny ourselves the chance to take in more evidence before settling on a final position for possibly important decisions,  reducing what should be lively well-reasoned debates into dogmatic fear-mongering flinging of FUD to maintain our committed positions against any opposition.

To get back to the divide and destroy our country thing - clearly I wouldn't title a public blog post that way unless I wholly believed the thesis, so now I'm going to have to spend the rest of 2010 railing on the evils of microblogging. Oh well, should be fun. 

Think before your tweet because you will end up thinking what you tweet.

Some thoughts on property and the direction we're moving in the twenty-tens. It's not completely insane that sometime in the not to distant future a parent will hear their progeny ask a question like:

"Dad, what does it mean to buy something?"

and the following conversation might ensue:

Dad: "Well Billy, it's like licensing something, but you can do whatever you want with it"
Child: "But that's crazy, no company would ever let someone do WHATEVER they want with their product"
Dad: "Actually it used to happen all the time, you would buy something, and then you could do what you wanted - use it, disassemble it, loan it, even sell it again"
Child: "But isn't that completely anti-capitalist? It you could sell stuff you didn't need anymore then how would companies make money. Why would be people keep buying new stuff if the old stuff worked just as well?"
Dad: "I don't know it used to just work itself out...You know free market and all that"
Child: "Dad are you a Commie? Do I need to call the thought police?"

Ok, that last piece was a little over the top, but the rest isn't all that far from where we are now.

Anything that's delivered in a digital form is already licensed and not sold. Music, Movies, Video Games, Books.

Physical goods are moving in that direction too, helped by embedded microcontrollers and software. You can't take ownership of a computer without accepting a whole bunch of restrictions on what you can do, but it gets worse. Want to sell ink cartridges for someone elses printer? Get slapped with a DMCA lawsuit for reverse engineering their faux-DRM. Want to sell an unlicensed game on console? Same thing.

Intellectual Property rights are slowly encroching into all walks of life. Want to post a video of yourself dancing like an idiot to a pop song? Good luck.

Pretty soon baseball bats will come shrink-wrapped with End User License Agreements allowing them to sue you if you use their bat in an unauthorized manner.

Combine the licensing phenomen with the credit phenomenon, and suddenly we don't actually own anything. That house you bought? Technically the bank owns it, and you owe them more than it's worth. That car? Actually, you traded in your last car for less than it was worth to upgrade to this years model, so technically you own less than 0% of that too.

Ownership just isn't for the little people anymore. It's so 2009.

This never quite made it out of the backlog back in October, but I thought the implications of a case discussed on Volokh a couple of months ago were pretty staggering. To highlight the article's quote of the ruling (significantly chopped down):

The Fourth Amendment protects our homes from unreasonable searches and seizures, requiring that, absent special circumstances, the government obtain a search warrant based on probable cause before entering. This is strong privacy protection for homes and the items within them in the physical world.

When a person uses the Internet, however, the user’s actions are no longer in his or her physical home; in fact he or she is not truly acting in private space at all. The user is generally accessing the Internet with a network account and computer storage owned by an ISP like Comcast or NetZero. All materials stored online, whether they are e-mails or remotely stored documents, are physically stored on servers owned by an ISP. When we send an e-mail or instant message from the comfort of our own homes to a friend across town the message travels from our computer to computers owned by a third party, the ISP, before being delivered to the intended recipient. Thus, “private” information is actually being held by third-party private companies.

...[snip]...

Thus subscribers are, or should be, aware that their personal information and the contents of their online communications are accessible to the ISP and its employees and can be shared with the government under the appropriate circumstances. Much of the reluctance to apply traditional notions of third party disclosure to the e-mail context seems to stem from a fundamental misunderstanding of the lack of privacy we all have in our e-mails. Some people seem to think that they are as private as letters, phone calls, or journal entries. The blunt fact is, they are not.

This is a pretty significant statement - what it means is that if you transmit over a public line (read: the internet) anything that could be read by a third party, you shouldn't have an expectation of privacy about it. In essence, this is what the tinfoil-hats have been saying all along,  and the only solution is to encrypt-encrypt-encrypt. Why? Because if you encrypt your transmissions and storage then suddenly you do have an expectation of privacy.

If the government wanted to read an encrypted email that was encrypted against your own private key, then following the above logic - even if it was stored on a third party server - they would need to get a warrant and they couldn't just read what they wanted.

Now one of the problems here is that the data would need to be encrypted in a way only accessible to you along each step of it's journey: sending, transmission, reception, storage and retrieval, otherwise since the ISP could have logs of any of those steps, your expectation of privacy would fly back out the window. 

The good news - the securing transmission part is getting easier. While very few people outside of the enterprise use certificates to encode and sign their emails (unless they like wearing the aforementioned metal-headpieces), a good portion of the email being sent is starting to be transported via SSL.  What this means is that if you only leave the ISP the transmission part, and host your own email servers, then your expectation of privacy would hopefully return since you're not relying on a third-party for reception, storage and retrieval.

The bad news - until Google releases a GMail appliance, there's no way to use an ISP for other services and be protected. Now while the 4th amendment only applies to governmental search and seizure, this has further implications for private enterprise moving to SaaS models. If the court has stated that you never should have had any legal expectation of privacy about any of your data in the first place then you need to be very dilligent in reading your terms of service. Could you sue a SaaS provider if they released some valuable statistics about your data to a competitor? Most likely their ToS doesn't explicitly mention all meta-data and derived data, so I don't know, but until it gets decided in court, I wouldn't throw out all those servers and cloudify all your business needs just yet. 

It's easy as a small web shop to imagine that everyone has by now completely integrated all their separate parts into one seamless, magical ESB - after all if we can do it with almost no budget, a larger company that can throw million of dollars at the problem should be able to do it as well. This is obviously an opinion that greatly discounts how difficult corporate inertia is too change - one client of a e-procurement system I worked on is just finally finishing integrating the system into their processes, 3 years after it was finished. But more than just corporate inertia, legacy systems and huge installed user bases make it extremely difficult to smoothly and completely integrate different pieces of a company's computer systems together - for example completely tying a website to a company's the back-end system.

We recently got back from a two-week vacation in Germany, and having been given some excellent advice from my father that international data roaming charges are exorbitant, I signed up for AT&T's "international data-roaming plan" for about $20/month which gets you 20 MB of emergency-email-checking and where-the-heck-are-we-GPS'ing on my phone while we traveled around the country. At least that's what I thought I did - when I got back I and opened my AT&T phone bill it said I owed them a whole lot money. That can't be right I thought, so I logged onto the website and verified that the international data-roaming plan was on the phone and read the fine print (expecting to see something like "except in southern Bavaria") - but no, everything looked hunky-dory.

I called up and talked to what turned out to be a amazingly friendly AT&T customer service representative that issued an apology immediately and said that the data roaming had been added the wrong phone - Martha and I share a family-plan for our business phones. I immediately assumed she had misspoken so I asked:

Me: Oh, so I added the data-roaming to the wrong phone?
AT&T Rep: No sir, we did.
Me: Wait, how is that possible, I did it on the website.
AT&T Rep: I'm not sure, it's billed correctly but someone here added it to the wrong phone.

They immediately issued a credit but the fact that something like this could happen speaks to a larger issue - AT&T most likely hasn't completely integrated the various parts of their wireless operation. I can only engage in wild, over-the-top speculation - but I'd guess that anything you do on their nice, modern website probably gets printed out on an old-school line printer fed with special printer paper, put in a small metal cylinder and then delivered via pneumatic tubes to the 9th floor, the "Account Modification and Liquidation Department" where a overworked, chain-smoking employee in a non-descript gray suit sitting at a small wooden desk manually enters the change request into a completely different system running on an old mainframe via a green phosphorescent terminal interface (In fact, in my head AT&T corporate looks and operates exactly like the office building in the Hudsucker Proxy )

As a small company, not having to deal with legacy systems and huge installed user bases is one of the reasons that we can do a lot more with a lot less. We don't have millions of users demanding certain existing functionality or hundreds of employees entrenched in their ways. We have the ability to be a lot more agile and a lot more competitive by working of a new technology picked specifically for the task rather than dealing with a system built on COBOL because it was the only language available at the time.

For another example let's take my name - I'm pretty sure it's Pascal Rettig - and I'm pretty sure that I usually spell it correctly. What is surprising however, is the amount of mail that shows up at our door addressed to "Pascal Retting." People really like to put in an extra "N" into my last name and there's nothing I can do to stop them.

It's enough of a problem that I always verify the spelling of my last name when I set up some service over the phone, but invariably a good portion of the time the first bill will show up and there it will be: "Pascal Retting."

What this means is that just like the AT&T snafu above - people are taking my information, entering it into a computer (unless their typing is just an IM to a friend), and then at some point along the line it's getting retyped in by someone who makes the inadvertant subconscious addition.

When National Grid acquired energy provider Keyspan in our area, the name on my account suddenly changed from Pascal Rettig to Pascal Retting (I can't be 100% sure that's exactly when it happened but it's there now). What that means to me is that during the acquisition, at some point, someone re-typed in my name, and by inference a couple of million other customers names into a new computer system. That is insane. It speaks to a corporate culture playing serious catchup in the digital age - a liability for them but an opportunity for small businesses not encumbered by the shakles of human error and inefficiency to make their mark. That being said, having a few million to throw at a project probably doesn't hurt.