We had fun talking with the other vendors at the show, most notably Component One and the folks from CapTech.  This is the first time we’ve had a vendor booth at an event like this, so in many ways it was a dry run to get the hang of what it’s like.  We gave away a full copy of Gibraltar Analyst as well as a year’s subscription to Hub at the conference, and got to talk with a lot of people about both Gibraltar and VistaDB.  We got some great real world examples of where VistaDB fits, which is  a big help as we work on the marketing for that going forward.

I presented two sessions -

A Year in the Life of an ISV

If you’re thinking about what it’d be like to ditch your corporate development job or consultant gig and strike to create & market your own product (Or you’re a consultancy looking to create a product to diversify) this presentation shows what to expect on the path from shipping your first version to business success.

This one’s always a little risky at a code camp because, well… there’s no code. But, with the incredible diversity of tracks that were available at Philly Code Camp (13 tracks, over 60 sessions…) I think it’s also good to be able to “take a break”. Next time I might go for the last session of the day to maximize the value of that.

Designing APIs for Others

I covered a range of real world lessons about commercial API development emphasizing the differences between in-house & internal development and great, reusable commercial libraries.

I got some great feedback on this talk, particularly on an example that broke my own rule about samples: I tried to over-simplify it and instead created a “not best practice” sample.   I’ll fix that for next time!

If you saw either presentation, please be sure to fill out the conference evaluation and I’d love to hear your feedback – drop it in the comments below or send it to me directly at kendall.miller@gibraltarsoftware.com.

If you’d be interested in having me come talk at your code camp, .NET Users Group, or event – please reach out and let me know.   I’m always looking for new & better ways to engage with the community.

Technology Lifecycle

Portraying tech as either dead or not is too simplistic to be useful.  Instead, let’s consider a few states:

• New:  Fresh technology still being fleshed out.  This is the leading edge of advancement.
• Mature:  Fully fleshed out and well understood.
• Deprecated:  This technology is planned on being made unsupported or removed in the next environment.
• Dead:  The technology has significant risks, is not supported and can’t be used on the latest environment.

In this model there are a lot of shades of grey between Not Dead and Dead.  If you are building a big, customer critical system you probably want to be using mature technologies.  If you have one of those systems and it’s based on deprecated items you need to put together a strategy to migrate off of it before it goes dead.

WPF: Still the new kid on the block

Many arguments about something being dead are really focusing in on just the first two states:  Is it brand new and still a hotbed of development, or is it mature.  For example, compare WinForms and WPF in .NET.  The former is mature and the latter is still new.  Why would I classify WPF as new, three years after its initial introduction?

• It was significantly updated in .NET 4.0, which shipped just five months ago.
• The ecosystem of controls and other libraries for WPF is still expanding rapidly.

WPF is probably just about to transition to mature.  The ecosystem of controls is now large enough you can quickly develop most applications you might otherwise use WinForms for.  This wasn’t true at the start of 2010, but the last six months has seen an explosion of new libraries from all of the usual players.  Quite probably Microsoft won’t significantly mess with WPF going forward and that’s a good thing:  It means you’ll be able to take what you write today and move it forward to the next few versions of .NET over the next decade without significant rework.  Migration rework doesn’t add value to you or your customer.

WinForms:  All grown up

Now, my friends that do Silverlight or WPF development are probably howling right now that WinForms is long dead & buried.  After all:  Microsoft doesn’t have a legion of developers working on it, and quite literally nothing was done in the last two releases of the .NET framework for it.  But it just doesn’t qualify as either deprecated or dead:

• WinForms on .NET will be supported for a long time, quite likely as long as .NET and Windows are because it’s built on GDI+ which is foundational to Windows.
• WinForms is still being patched for security vulnerabilities and will be supported in the next major version of Windows.

So even though it hasn’t been changed since .NET 2.0, it’s still a completely viable platform to develop even brand new applications on.  The fact is that a new application developed for WinForms will likely be officially supported by Microsoft as long as WPF, certainly through several more major versions of Windows.  We’ve found that a number of our customers at Gibraltar Software and VistaDB are actively developing and starting new projects in WinForms because it’s a very productive environment.  It has a large body of third party controls, the tools & techniques to develop for it are well understood, and in the end that delivers results.

Visual Basic 6: Dead Man Walking

If you want to look at a technology teetering on the edge of death take VB 6.  You can run it on the latest environment (Windows 2008 R2 and Windows 7 both support VB 6, no joke!) but it isn’t being supported or patched even for security problems.  That puts it hovering right between deprecated and dead.  If I had to bet money, VB 6 will still be alive and kicking on Windows 8 but I would definitely not develop any new VB 6 applications and I’d be actively migrating away from them.

People Love a Winner

Developers are just people – and we love winners.  This is the best car, that’s the best language, this is the best database.  There is so much going on in software that it isn’t feasible for any one person to assimilate all of the options available, relate them to a problem at hand and truly sort out the one very best match between them.  Despite this, we’re asked to do that all of the time: so anything that makes our job more complicated we want to fight.  We don’t want two ways to make web applications, two ways to make client user interfaces, etc.

We’d prefer a nice clean line of replacement where new, cooler things replace older stodgy things.  By this logic, WPF replaced WinForms which replaced MFC or something like that.  Silverlight is a little of an odd duck, but sure – put it in the same line now that you can run out of the browser with it.

Get Results the Mature Way

Just because Microsoft doesn’t have an army of developers actively changing it and isn’t beating the drum about it in every press event doesn’t mean you shouldn’t use it.  In fact, look at it another way:  If Microsoft is still rapidly evolving a technology you should really think about whether you want to jump in.  Since its changing you can’t bank on a body of best practices or an ecosystem of third party libraries.  You’re most likely to run into platform defects in design & implementation, and most likely to be heartbroken when the next version of .NET breaks your clever hack or makes it completely irrelevant.

In the end, what are you trying to do?  If you’re focused on getting results and solving real-world problems for customers, stick with mature.  If you want to hang out with the cool kids and be a pioneer have fun with the latest new thing.  Just know that it’s the pioneers that end up on the ground with arrows in their backs.

While there are several positive aspects that can come from this approach, there are several problems that can easily be created that stem from the problem that in most cases the rest of the company really isn’t a customer in the classical sense. Why? Because they lack a true buying choice. Furthermore, it generally isn’t in a company’s overall best interest for their divisions to really be customers of their own organization.

The original motivation for taking these approach is usually to address several issues:

• Division buy-in on costs and priorities: If they are directly paying the bill, they are going to pay for what they want and not ask you for things they aren’t willing to pay for.
• Clear status and communication: The project reporting and communication model is simpler for everyone to get their head around if it’s based on something we’ve very familiar with. Each player can figure out their part.

If you model the relationship between the IT organization and the rest of the company as a service provider – customer relationship, it’s easy to miss the transitive qualities of this: if they are your customer, you are their vendor. The word Vendor casts things in a different light: If you’re a sufficiently large organization you probably have a vendor management office whose sole job is to ensure you pay the least you can for things and fosters competition between vendors. Their job is largely to keep the company from getting too cozy with any one vendor. Are you ready to be just another vendor, like the one that bids annually to supply fresh coffee or office supplies?

Benefits

There are several good things that this model will tend to create.

• Defensible functional requirements: Unreasonable requirements tend to be expensive relative to their value, and the division is more ready to discard them.
• Role Clarity: The Vendor/Customer relationship is relatively easy to understand, and each party can generally determine their role quickly. When there are disputes, there’s a natural framework for resolution.

Challenge One: Buying Choice

It isn’t a long road from treating your internal divisions as customers until they look at you as a vendor. Once they consider you just another vendor (like the one they selected to provide fresh coffee to the office, or office supplies) they’ll want the advantages that come along with being a customer. For example, it’ll seem clear to them that it should be optional to use your services. This will feel very reasonable to upper management – it’s all part of the transitive nature of IT being accountable.  If IT can’t deliver a service at the best price, why not go to another provider?

This will likely start with something that will be difficult to argue against – such as a large software development project, perhaps in a language that your in-house talent isn’t familiar with.  Now, what about hosting for that product?  If you are charging back true costs for your data center to each division, you are unlikely competitively priced with what a division could get from Rackspace or Peer1.  It isn’t necessarily that those companies are more efficient than you are at doing the same thing (indeed, if they are then you should broker your own contract with them) but instead that it isn’t an apples-to-apples comparison.

Challenge Two: Implied Requirements

Whenever an internal IT organization takes on a project, there are a number of implied requirements that affect cost and schedule. Some of these requirements are from the IT organization itself (like technology choices) and others are from the corporation (role of internal staff and contractors, project management and reporting standards, etc.). When a division looks to bid out work to an external source, these requirements are usually unstated because in many cases they aren’t requirements the division has on the solution.

Another way to look at it is that any constraint on the solution that the customer (the division in this case) doesn’t have or care about is an implied requirement and likely a competitive disadvantage when comparing internal IT costs with external costs. In broad strokes, the difference in requirements is that a division’s requirements are almost entirely about outcomes, not methods: They care about the results their users get, not how they are achieved. IT organizations often focus their requirements on how results are achieved (using this technology, in that enterprise architecture, developed with our RUP-based approved process, tracked by our PMO) and they defer to the division the functional requirements.

Local Maxima and Minima

When each division or cost center is free to chose what services they are willing to pay for, they will converge over time on only those services that are good for them. Establishing shared services is generally challenging because each party will want to ensure that everyone is paying their fair share. This is often tricky to define – should it be proportioned by feature usage? Capacity?  This often creates a “first mover disadvantage” scenario where no part of the company wants to be the first to get a new service such as a database server or SharePoint Portal because they’ll be hit with the entire cost of it unless someone else comes along.

Secondarily, upgrading services gets challenging because no drop of rain believes it is responsible for the flood: If you want to upgrade to Exchange 2007 from Exchange 2003, one division can easily say that they don’t believe it’s necessary and thus decline the costs. If you need a larger server to house SharePoint, who is going to get the bill? A game of chicken often gets created where multiple parties all want a service, but no one wants to be the first to ask and risk subsidizing everyone else.

With each cost center pushing to only pay for those things it perceives sufficient direct value to take on, they are making decisions only based on what gives them the best cost or maximum value. This isn’t likely to align with providing the overall lowest costs for the company. For example, three separate departments could easily decide to implement their own direct attach storage for disk because none of them feels they can justify the cost of a SAN, however together it would be less expensive to construct and maintain a central SAN environment with SAN backup.

There are some straightforward exceptions to this problem where shared services are generally easy to get consensus on and cost out. Typically these are raw infrastructure services such as email or file storage where there are clear units of measure that allow for proportional billing (mailboxes and gigabytes used, for example).

An Alternative: Clients, not Customers

If the Customer/Vendor model isn’t the overall best approach for a company, what alternative model can provide the benefits without the unintended consequences? How about a term that’s between User (which has accumulated a substantially negative connotation) and Customer – Client. A quick trip to the dictionary shows that a client is any person or group that is the party for which professional services are rendered, which fits reasonably enough.

As your clients, they still are entitled to a great deal, just like customers would be. As the client of the project, they:

• Determine success & failure: Your project isn’t successful just because it follows the corporate processes or works on the corporate approved IT infrastructure; those are the constraints on how you solve problems that are immaterial to your client. Success is determined by whether you achieved the goals the client created. That may mean you need to do some extra communication to make sure your client knows that their goals were met, even if that’s not in the standard process.
• Decide if it’s worth the price: In the end, the problem may just not be worth solving.  Many things can be done but the cost in time and distraction exceeds the value.

Unlike a customer, since you’re part of the same organization you can share with the client your insight into the costs and risks of the project in a way that no vendor ever could.  In the end this creates the best partnership that delivers long lasting results.

A final note

If you don’t treat your users as clients, odds are very good they will eventually get themselves a buying choice. When they do, they won’t chose you. Don’t let it come to that, it isn’t ultimately in their interest, your interest, or your company’s interest.

When you want to create a product that just works, you need to get all of the details right – from packaging through to maintenance and upkeep.  It’s not one thing that’s important, it’s all the things.  We are often engaged by senior management within a client when things aren’t working, and there’s conflicting opinions on why.  Usually along the path technology is being blamed: Not enough, not the latest thing, not someone’s favorite thing, not working.  As we dig into the situation, rarely is the technology the dominant factor:  More often, it’s how the technology is being integrated with the people and processes that all have to work together.

One of the first things we have to do in these engagements is to establish the real facts on the ground:  What exactly are the problems in the system, who’s doing what with it, how many times.  It comes down to establishing metrics to make sure time and attention are paid to the parts that make the biggest difference in the outcome.  Armed with these facts in a form the business can consume it’s possible to create plans of action that deliver virtually regardless of budget.

So let’s make this easier

The biggest trick is then getting the facts you need on an ongoing basis, easily, and in a form that the business can consume.  For over a decade we’ve been building instrumentation right into the systems we’ve worked on.  We’ve created a variety of toolkits to make this easier over the years, refining them as technology and our experience has changed.

About 18 months ago we decided it was time to really invest down this path.  We believe in routinely capturing key computer metrics along with whatever logging the application can do on its own.  We won’t do a project without using a great logging system that includes a strategy for managing runtime exceptions.   Now that we’re collecting all this data, we need to have a way of managing the raw data and turning it into valuable business data.

The challenge is that businesses don’t get up in the morning and say “what our customers want us to do is have great internal tools”, so you’re nearly always doing this on the cheap:  Borrowing time from development projects internally to cobble together various free or cheap solutions.  Frankly, we got tired of having to create new solutions with each client out of the margins of each project.  So, we pooled our best thinking from all of the work we’ve done (including a previous product that we did license to our clients over the past decade called CLAS) and started creating Gibraltar.

Rock Solid from Initial Release

With Gibraltar we wanted much more than a log system.  Of course, it had to be a log system too – and a really easy to use one that could work with each of our client applications.  More than that, it had to:

• Automatically capture all of the performance metrics we wanted.
• Integrate with existing logging available on the platform, including whatever a client might already be doing (like custom in-house options)
• Be absolutely, positively, for sure safe to run in production no matter what.   That means it can’t ever use too much disk space or disk throughput or block the application.
• Not use more than 5% of the performance of the app
• Include all of the tools necessary to get data from where it was collected to the people that could get value out of it
• Include the ability to look at the detailed session data up to high level analysis:  What’s the error rate?  What’s it correlate to?  Are we doing better or worse in this version?

From this initial sketch into everything we wanted, we’ve spent 18 months including four beta periods (from 2-4 months each) to refine the vision with real customers and real scenarios.  It was essential to us that this not be just a tool for techies but be ready for use by people with a wide range of skills.  It had to be pretty and just do what you wanted, when you wanted it to.

We’ve added a lot of capabilities along the way:  It can generate print-ready reports about application reliability that can communicate with senior management, you can define all kinds of custom metrics to easily track how your application is used and by whom.  We ran a number of betas to be sure that we had hit every goal we have above.  We’re happy to report that Gibraltar is in use within large deployments of custom applications, commercial applications, and small deployments right down to our corporate web site.

This tool isn’t for everyone – Our clients are nearly all Windows shops, and if they do any custom development it’s almost invariably in .NET, so that’s what we’ve targeted.   But, if you’re interested in easily getting real data on not just infrastructure (how well the application is running) but whether or not it just works, have we got an easy path for you.  You can see a quick demo video of how it works technically at Gibraltar Software.

You also don’t have to take my word for it at all, you can hear what one of our beta users did with it, which is really a more compelling story than what we might say.

I think you’ll find that our work sweating a lot of little details, from the exact design of the API and making sure the documentation was complete to rewriting our own licensing system to be very IT Admin friendly.  If we didn’t get a detail right, we want to know.  And the great news is that we’ve just begun:  We’re obsessed with the little things, and you can bet we’ll keep listening and watching to make it better.  Of course, this is made a lot easier because we’re using Gibraltar to monitor itself, and a select group of our users is sending that information back to us so we can make sure it just works in the field for real people.

It’s easy to start your journey

If you do development for Microsoft .NET, I’d encourage you to go over and download our commercial release of Gibraltar.  You’ll get great documentation, a free agent you can use like a flight recorder “black box” in every application you create, and a trial for a tool that will make you seem wise beyond your years.  And if you pay us the ultimate honor and purchase a permanent license, I can assure you that you won’t find anyone more committed to your satisfaction than we are.

If all this sounds a little off kilter from reality, perhaps a few hard numbers would help:

Quoting Computer World, who asked “Do Business Desktop PCs have a future?”:

While desktop PCs account for the bulk of personal computers sold to enterprises, the gap in laptop sales to enterprises is closing. Of 168 million PCs sold worldwide to professional organizations in 2008, about 95 million were desktops and 73 million were laptops. That’s compared to 94.6 million desktops and 47.3 million laptops that shipped in 2006.

Now, as with any statistics there’s two ways to look at these numbers:

1. Laptops have grown tremendously in their total percentage of the market, and that growth rate has them on track to take over the world.
2. The majority of the growth in computer sales is coming in the form of laptops.

The gazelles are taking the first road.  And why not?  People love to assume the disruptive is true, it’s a lot more interesting.  Before you charge down that road, consider what seems likely.  There are a few problems with the first conclusion:

• Two data points don’t make a pattern: If you follow the trend back farther, the sales of PC desktops has held up consistently, but laptop sales go up and down.  This would seem to indicate that the most likely interpretations of the data are that either the overall market is expanding (for example by people having two systems) or that this is a momentary, periodic surge in laptop purchases.
• Past large growth rarely projects forward: Just because there was a large growth in one year (either in absolute or percentage turns) doesn’t mean it will repeat at all.  It’s just as likely that the next year pattern will be flat or even retreat.

So before you see the first twitch and assume it signals a migration of the whole herd, step back and think through the underlying facts.  Is this really the first sign of a monumental shift?  Or just another twitch of the needle?  Then look at your own situation.

Now, we have a few laptops, but we have more hard core desktops – the laptops are used for on the road presentations or working at Starbucks for fun.  Of course, we’re developers so we’re in the category of users that are always excluded from the norm.  But what’s not to love about a desktop?  For the same money they will always be faster and more capable than a laptop because they don’t have the burden of being small or extra power efficient.  Even if you buy into the idea that everything will be run through the web so computers are just glorified terminals…  Something still has to compose all of those web pages and make it all come together, and web apps can burn a surprising amount of processor and RAM locally.

In the end, I think we’re seeing a lot of folks buying second computers or getting additional laptops for other uses that complement their primary work computer experience.  Additionally, there are folks in emerging markets that need what laptops offer (self-contained, reliable power) more than performance but this reflects an increase in the overall market, not a shift in the existing market.

• If you take a piece of wood and don’t sand the surface smooth it won’t take a stain evenly.
• If you let glue creep out of the joint and get on the wood, the stain won’t look right in that spot.
• A piece of dust on the surface will get magnified by each layer of varnish.

Each layer depends on what’s underneath it.  Any flaw in a lower layer will tend to get magnified and distorted by layers above it.

Whenever I get involved in enterprise architecture I get reminded of this analogy because I often run into irrational exuberance that you can add a layer to an existing system and paint over the flaws underneath.  I was involved in a few projects like that early in my career:  It was too hard to talk directly to the mainframe from the web server so you put a layer in front of that.  There was already a C++ layer doing a DCE RPC gateway, but that was also too hard to program against for large use so we added a COM interface to the DCE RPC gateway.  We made some prototypes and validated the concepts and charged in full bore, only to run into big delays and teething problems near the end of the project trying to get everything polished up and suitable for production.

The problem is that at each turn you may be making the developer’s short term life easier by giving them an interface more natural to their preferred programming environment but since it just builds on the layers underneath it will end up with all of the limitations they have – and they can show up in the most surprising places.  For example, we ran into problems where certain input would cause failures which we ultimately discovered was caused by % being used as an insertion marker in a gateway library several layers underneath what we were doing – so at best it would drop the % and the following character, but at worst you’d get back a random data element if you managed to create a valid insertion name.

Layering issues are particularly problematic because they tend to be data sensitive and highly situational depending on how the various layers interact.  This means that it’s very difficult to design a comprehensive test plan:  The system can act as if it’s nondeterministic, making it infeasible to state with certainty that the various modes of the software have been demonstrated by a test plan.  At best, you can say that it worked for the exact test inputs it was given.  When you do have a problem in production, the multiple technologies in multiple layers can make it particularly hard to debug because it requires a lot of chairs around the table to hit all of the possible players.

Are you decorating?  Or covering up the problem?

Whenever you’re part of a team proposing adding a new layer over an existing system to fix its problems or adapt it to a new situation, you should be suspicious.  Is this really the right path to make the API look right?  Or are you temporarily covering over a problem?  If it’s the latter, it’ll just show through later – and now you have two problems to deal with not one.

There are good occasions to add a new layer:

• To smooth technology upgrades: When you are shifting technologies, say from COM to .NET, you may want to create a custom layer as a new standardized interoperability adapter which will let you separate the upgrade problem into phases and handle them independently.
• To support multiple technologies: Sometimes you need to support multiple types of clients – varying either by environment (say Java and .NET) or major architecture (say Client/Server and Web sites).

And a few suspect ones:

• Mitigate architecture risk: To isolate a new subsystem architecture from the main codebase. We’ve heard this one before – you want to try out something new and iffy, like say Entity Framework.  To contain the risk, you want to introduce a layer between it and the rest of the platform so if it all goes bad you can easily swap it out.
• Impedance Mismatch: You need to interact with something, but just don’t like the way it works. Perhaps it throws around ADO.NET recordsets and you prefer to work with strongly typed objects.

If you find yourself in one of the suspect scenarios, you should seriously question whether the work you’d do to create and validate a layer is really forward progress or just yak shaving.  Before you go down the path, you should seriously estimate:

• Fixing the underlying problems: If the underlying layer(s) aren’t doing what you need, what would it take to get them changed (in the technology they’re currently in) so you could work without adding another layer? That puts the responsibility where it belongs, and keeps complexity under control. Do a full estimate of this approach.
• Make a parallel layer: If you ignore the powerful aversion to creating duplicate routes to the same data, what if you created an alternate path to the underlying information. It may be that you bypass all of the layers or just some of the layers (such as down to the stored procedures that call the database). While this creates duplication, it lets each platform work in their own optimal way and allows for deterministic testing.
• Using the existing layer as it is: It’s easy to overstate the impact of reusing a known system with issues. There’s a natural tendency to not realize that you’re comparing a well understood but flawed system with an unknown solution with unknown problems. Trading known problems for unknown problems makes everyone happy at the start of a project, but creates significant project risk downstream.

Put down the shovel and back away

When you create a new layer on top of existing layers you are often digging your project into trouble, both now and downstream.  In addition to problems with each layer creating a leaky abstraction, deploying and supporting these highly layered systems is extraordinarily challenging.  It becomes prohibitively expensive to make changes in lower layers because of the high chance of unexpected side effects showing up as defects in dependent applications.  More often than not, each layer has to be held static with any changes accommodated by creating new queries or items at each layer to be served in parallel with the older methods.

Before you go ahead, be sure you look at the total lifecycle cost of that decision, including support and maintenance.   Have a good or bad experience with putting up some software wallpaper?  Let us know in the comments!

I know it’s very uncool to admit – IE is only available on Windows, isn’t the most standards compliant, it has a bad reputation for security and there aren’t 1000 cool addins for it. And oh yeah, it’s from Microsoft – aren’t they evil?

But here’s the thing: From day one, it was the practical choice. Not because it was distributed with Windows, but because it worked. Worked as in it was easy to keep upgraded (thank Windows Update for that) it could do anything we needed it to (and yes, that used ActiveX) and it supported integrated authentication – so users could just point their web browser at our company sites and not get any login prompts, just get access to all the resources they needed.

Not only that, but IE was really forgiving. The thing that many people miss is that at the end of the day it isn’t about being standards compliant per se, it’s about the web browser just working. Put another way, while you want to develop using something really strict, when it comes time to hand it over to your users do what I meant, not what I said is best. Frankly, I was amazed at how tolerant IE was of HTML errors. In the end, do you think that users would say Thank you for not doing what I meant because it would have meant breaking the rule that you can’t wrap a div with an href? Most users I know would just rather it displayed the page.

Is the pace of IE development slower than Firefox or other browsers? Well, yes – but again, so what: businesses really don’t like change, change costs money. Change means retesting applications, and for what? It has to give them something to justify that cost. It isn’t like IE won’t remain a viable tool for browsing the Internet for some time. Remember, these are the same companies that are still (justifiably) writing applications in VB6, an environment that its creator has been trying hard to kill for 8 years.

So it makes a lot of sense that when it came to IE 8, Microsoft focused on what IE users really wanted. It isn’t standards compliance for its own sake, it was:

1. Make it as fast as possible for how people browse the web today.
2. Fix as many of the quirks in standards interpretation as feasible that make it easy to develop good sites for IE.
3. Do what you can to make it hard to have a rash of new security problems.
4. Don’t break any site that works today.

If you want a good feel for just how hard this problem is, Joel Spolsky did a great (but long) writeup.

So I’m writing this in IE 8 – and it is just what Microsoft promised, it hits all of the points above and is certainly a solid improvement over IE 7. Microsoft made a great call in focusing not on Javascript performance but looking at the totality of what affects the apparent browsing performance for users and addressing that. It feels nice and fast, and I haven’t encountered anything that’s broken.

But it’s no longer my default browser. While I’ve been trying to love it, I just can’t get there. I switched over to Chrome when it went into release and haven’t looked back. On the surface of it, this is a bit crazy:

• Many sites don’t work quite right with Chrome. I’ve gotten halfway through a shopping cart with Chrome and had the buttons not work to go next. Things don’t align right… Virtually every web app we use at eSymmetrix had to be patched to work with Chrome. Even WordPress seems to work better with IE than Chrome in some ways.
• Google is getting evil. They’re doing things Microsoft never could get away with. For example, every Google thing installs its own Google Updater service. It doesn’t ask if it can, I can’t find any way to get rid of them through uninstall.. they’re just there. I have no idea if they’ve ever updated Chrome because they’ve never asked. You can be sure that if Microsoft this they’d be in court faster than you can say Slashdot.
• It’s not really stable. About every other day I get the admittedly cute Aw Snap! page where Chrome just isn’t quite happy.

But it doesn’t matter, I still dramatically prefer it to the other three browsers on my computer. Why?

• It’s fast.
• I love the automatic 9 recent site dashboard with preview. I love how it handles browsing history.
• The document inspector is great for web development, so I use it all the time when developing web pages and style sheets.
• It’s the future.

It’s the last point that’s really got my interest. It’s the future. Why? Because while it really doesn’t matter right now, the approach Chrome uses for Javascript is going to rewrite the face of the web.

That’s just Crazy Talk

Right now Chrome has around 1.5% of the total browser market share. That’s nothing – about what Opera and Netscape have put together, much less than Safari at 8%. On the other hand, IE 6 and IE 7 each have the market share of all the rest put together (more or less). So statistically, Chrome is completely irrelevant – and it’s had a lot of time to get to that point in market share. IE 8 cot to that point of market share pretty much as soon as it was released.

So what justifies it being the future? Because the V8 Javascript compiler is a game changer. Not on its own, it’s a piece of the puzzle. Four things have to come together:

1. Universal high bandwidth: Enough to move say 3mb in 5 seconds reliably.
2. A compiler that converts Javascript into machine code within 50% of the performance of compiled Java or .NET.
3. A standard Javascript library that can function as a GUI Toolkit on par with .NET WinForms or Cocoa.
4. A visual Integrated Development Environment (IDE) that can bring it all together with a good debugger for browser and server.

We already have the first one. It takes about 6 mbps throughput – cable modem speed – to move 3MB of data in 5 seconds. Chrome brings in the second one (and actually bests that by some margin). Now we need the third and fourth.

Up until now the third item has been held back by the general problem that Javascript was slow enough that the overhead of having a common API (full of things you didn’t need for any single situation) was infeasible. Writing something broadly reusable is about an order of magnitude harder than writing it to handle a specific scenario, and ends up doing a number of things you don’t need to do because someone might need it. That overhead isn’t acceptable with the historical performance of Javascript, but if it’s compiled down to native code then it becomes a small, inconsequential optimization.

So now that there’s an environment that can run it, we need a general UI toolkit and the IDE to develop with so we’re putting our time and attention into creating features for our users, not how to make a menu that dynamically expands and highlights. The IDE needs to provide an end user experience like developing for WinForms or WPF in Visual Studio – clean, easy, visual, without surprises.

Microsoft was right – today it isn’t about Javascript performance. But if we’re lucky, tomorrow will be – and we’ll be able to develop much better, stronger applications for the web without resorting to Flash, Silverlight, or very expensive development and testing cycles.

So with my natural preference for hard core engineering I’d like to report that the best software comes from a group of driven software engineers. Technically, that may be true – a big group of engineers can make a very technically sophisticated product. But, really great products? Well, that requires a lot more than just technical excellence.

I think this is the backstory behind Vista’s successes and failures. We’ve been using Vista is our corporate OS since January of 2008, not long after it was widely available. It’s worked very well for us – even better since SP1. But again, we’re engineers: half of our systems are 64 bit, and we use high end hardware so we were very good candidates.

A Whole Lotta Polish

Last weekend I installed Windows 7. Now, even though I generally love new toys I haven’t been chomping at the bit to try out Windows 7 because Vista is working great for me, and we’ve had a lot of deadlines I didn’t want to risk. But, with the release of build 7100 last week, I couldn’t resist.

What’s the big difference between Windows 7 and Windows Vista? Polish. A whole lotta non-engineering polish. I was using the media center capabilities last night and noticing all of the little things that are completely irrelevant from an engineering / functional standpoint. These same things make all the difference in how you perceive the quality of the product and, more importantly the quality of the experience in using the product.

Is Build 7100 without issues? No – there are some optimization issues that I’ve run into, but they’re likely known already within Microsoft and they have months to refine them. The big picture is that the risky, time consuming design details are all there. I haven’t even turned off UAC yet, and I couldn’t live with that under Vista for more than two hours.

Now, it may be that if you’re creating the next version of SQL Server that this fundamentally human element of intuitive adjustment and polish isn’t as necessary. SQL Server could be all about hard core specifications, tests, and optimization. That’s reasonable when the human to product interface is either through a standard you can’t affect (e.g. T-SQL) or is confined to highly technical specialists.

Goes to Eleven

When you’re creating an application, you aren’t going to find the polish by reading a functional specification. You also aren’t going to get it just by using any particular development methodology – Agile, Waterfall, whatever. What you have to be willing to do is go beyond the written functional and system specification and look carefully at each aspect of the human – computer interface in your product.

This dedication requires a few things:

1. Access to a User Experience (UX) / Human Computer Interface (HCI) specialist. These folks are experts not for facts and figures or things you can read in a book but their experience and practiced eye that lets them pick out the key details that make all the difference.
2. Dedication to making it better: At each turn, and in very difficult moments, you’re going to have to repeatedly look at what you have and what you’ve done and say OK, how do we make this better. Take the case that we can leap beyond this, what would that look like?

Done right, this experience can be tortuous to engineers because it’s about iterating through hard to quantify, experimentally determined states without objective metrics to guide your process. You will see the results of your work – but as the sound of distant thunder as your users either rave more and more for what you’ve done or just accept meekly what you give them. Engineers are used to tweaking a knob and seeing the needle move in a quick, quantifiable way.

If you want to get a sense of what happens when people think deeply about how to create software that interacts well with people, read the Microsoft document on how to write an error dialog for Vista. This is 28 pages on how to do a good error message and why. Warnings? another 12 pages. Even if you’re a hard core engineer, some of the Vista User Experience Guidelines is a great read to understand why it takes many iterations and at least equal measure of instinct and intellect.

Fighting the Good Fight

The challenge with pushing for breakthroughs in the user experience with your product is that it doesn’t fit well into traditional engineering problem solving techniques. That may be why some of the most successful organizations at it have a strong command & control personality (like Apple) that emphasizing an individual making an intuitive judgment to decide what’s best. Trying to apply traditional engineering approaches will generally stifle and drive away the very talent that excels at solving these problems. Just ask Google. Their well respected expert on design and usability quit this year, saying:

I’m thankful for the opportunity I had to work at Google. I learned more than I thought I would…. But I won’t miss a design philosophy that lives or dies strictly by the sword of data.

The full text is an interesting read. Probably the most poignant example was testing what shade of blue should be used in a specific scenario. This is a good example of trusting your judgment, but don’t try to explain it. It’s a fundamentally human, intuitive leap and you might be able to rationalize it, but that doesn’t mean you can really explain it.

The best part is that if Microsoft is finally getting the message that it isn’t enough to just complete on business and engineering requirements but instead you have to battle for the hearts and minds of the people that use products it’s only good for everyone. Just like Linux has pushed Microsoft to be faster at evolving Windows (and creating more low cost licensing options), this may push players that are known for great design to have to up their game as well. I can’t wait.

Seriously people

First, Apple makes some of the finest hardware you can possibly buy.  If you compare it nose to nose with hardware that’s actually built to the same standards then it really doesn’t represent a significant price premium.  Compare a Macintosh Pro with an equivalent Dell workstation – the cost is within 5%.  It’s amazing that Apple can afford the extra engineering of an OS with that little premium.  

Second, Vista works great.   It’s running on many more systems than Mac OS is, and with volume comes a range of new problems.  The total amount of money I’ve spent on desktop antivirus software in 10 years of administering PCs?  $0.  The total number of virus problems I’ve had? 0.  My parents managed to get into trouble with one virus and Windows XP – but installing the (free) Microsoft Defender cleared it right up never to return.

As with nearly all marketing, this is a battle of perception:  Apple has done a great job of defending their brand at every turn.  This is part of their corporate ethos.  Along with a few other tenants it ensures they are a much loved but niche player:

• Only do something you can do uniquely well.
• Don’t extend into markets that might ask you to compromise your values.
• Cultivate the mystique:  Don’t show what’s behind the curtains.

Microsoft on the other hand has tenants that ensure they’ll be a volume player, but an unloved one:

• Play to win the most market share in any market you can.
• Build your ecosystem by making it easy for others to add value to it.
• Cultivate the engineers:  Provide overwhelming amounts of documentation and approaches.

The fact is, many people don’t need a top end piece of hardware like a Mac.  On the other hand, many people want a computer that’s just a tool, not a piece of art.  To them, the nearly infinite diversity and low cost of entry are essential.

I’m a People person.  I’m Good with People!

The computing needs of the average corporation and the average individual are very far apart.  To companies, computers are tools – like the desk, phone, and copier.  Very important, very powerful – tools.  They aren’t there to make you feel great or enable you to create a cool video of your vacation in France.  My partner really summed it up one day when he commented that the Mac was a really personal computer - it worked hard to create a personal connection.  

Corporations on the other hand want slow paced evolution, massive support for legacy applications and hardware (these guys are still running dot matrix printers off parallel ports) and to control costs.  They also philosophically want to have all the keys to the computers – just like they do for the buildings and offices they own.  PC’s are just end points on the large mesh that is the corporate IT network.  It’s very impersonal.

Microsoft makes a great deal of money providing businesses with the tools they need to have the computers work for them, and Apple makes a great deal of money creating computers that people love.  Either of these goals would be compromised by trying to do both.

Vista Goggles

Folks that have been in the Windows ecosystem a long time probably recognize that you could take the first year of press about Vista and substitute “Windows 2000″ and find the same article written 8 years earlier.  Vista is a surprisingly large and tricky step forwards on a number of fronts, whereas Windows XP was a visual redress of Windows 2000.  

Almost like an SAT test:

Windows 7 is to Windows Vista as

Windows XP is to Windows 2000.  

Like Windows XP, the story on Windows 7 is making virtually no architecture changes and instead just tuning for the long haul.  That’s a great thing, because there’s a lot that works very well with Vista, and now it’ll work even better with Windows 7.

The humorous thing is to read now about how people are thinking about moving to Vista once 7 ships because, well, they don’t want to move to an OS that was just released.  It’s as if Vista has been aging like a fine cheese on the shelf so the very same binary code that once was toxic is now just what the doctor ordered.  To a slight degree this is true:  Vista SP1 did address some issues that affected some people, and more importantly hardware now is dramatically faster than it was two years ago (as it will be two years from now…) so what once was aggressive is now commonplace.  The same was true of Windows 2000 when it shipped.  Requiring 64MB of RAM?  That’s just crazy talk!  Only certain video cards worked reasonably with it, and video drivers to a while to stabilize.  That sounds very familiar…

In the end, it really comes back to Perception.  Probably the biggest mistake Microsoft did was not push the OEM’s that make the computers to build machines that could responsibly run the new operating system, and be clear that meant hardware 3D video cards and plenty of memory.  And oh yeah, stop putting aftermarket firewalls, antivirus, Google Desktop, and all kinds of other things on them that are ill optimized.  At my last company we got in the habit of routinely wiping each new Dell that came in and reinstalling the OS from the Dell restore CD – because that got rid of all the noise.  It was surprising how much better that worked.  Is that Microsoft’s fault?  Not directly, but they certainly could have found a way to encourage the ecosystem to forgo some profit for usability.  But that’s just not in their corporate DNA.

With any luck, the big story for Windows 7 will be that Microsoft pushes back against their channel, even being willing to risk it by leaving Windows XP out there for folks that don’t want to play by the Windows 7 rules.  It’s hard to put up barriers when you’re a legal monopoly, so find ways to use incentives to do it right instead of punishment for doing it wrong.  And keep up the ads, because perception does matter in the long run.

Who knows, it may push Apple to get better too.  Just once when my iPod updates itself to enhance stability and performance I’d love to know what exactly was unstable or slow…

The prevailing wisdom appears to be:

• Google is the world’s best technology company.  Anything they solve they are the best at, and if you aren’t doing it their way you’re a dinosaur.
• Client / Server is dead.  All new applications will be web applications, most likely delivered as a service.

We visit a lot of companies, both prospects and clients.  Here’s what we’ve actually seen over the past two years:

• Outside of search, Google doesn’t have their act together.  Pretty much everything else is an academic experiment.  There’s nothing wrong with experiments, but there’s a big distance from there to running your business.
• Business are run on Client / Server.  They’re still creating new apps this way – they may use newer technologies like WPF to do it, but if it is core to making the business work, it’s usually not a web app.

With a name like Google, it’s got to be good!

Our own internal experience mirrors this.  We use Exchange and Outlook for email so I can’t say a lot directly about Gmail, however it’s clear from Google’s reactions to recent outages that their perspective doesn’t fit the enterprise because it doesn’t take into account the premium companies place on predictability and communication.  Predictability meaning that things are consistent – you get a consistent experience so your users can get their jobs done.  Businesses are change averse for good reason:  Users will adapt even to crazy problems and discover the patterns that work to get their jobs done.  When the patterns keep changing, they get frustrated.  On the communication front, businesses prize feedback on knowing the true scope of a problem and how long it may take to get it resolved.  

SalesForce learned this a few years ago and in response introduced Trust.Salesforce.Com, which went a long way to getting companies what they wanted to be comfortable with an outsourced critical solution.   If you operate a SaaS, you would do well to model after this.   Now, it isn’t necessarily bad that Google doesn’t do anything like this for Gmail – it just means it isn’t a solution for a large set of businesses.  

The thing we use the most internally from Google is Google Analytics.  It’s very pretty and easy to use, however we’ve noticed a lot of “what’s broken today?” experiences with it, enough that we can’t recommend it to anyone.  Two of the sites we monitor appear to be chronically under counted by Google Analytics, and we can’t figure out why.  And like most things Google – you’re on self support.  Now, there are paid options however unlike email we haven’t been able to find a strong paid competitor that is actively competing with Google.  It feels like most have left the field of battle, or are exorbitantly expensive (and aimed at large enterprises).

After much early on talk about how Google Docs was going to make Office obsolete, it simply hasn’t come to pass – and Microsoft continues to sell a lot of copies of Office.  It turns out that making a great word processor and spreadsheet is a very hard problem to do through the web.  Now, you might take the perspective that Microsoft’s announcement that they are going to offer lightweight web versions of Office 14 applications as being an admission that the old model is bankrupt, but it really points to an increase in reach:  Reaching many users that wouldn’t have been purchasing the product before.  Casual home users that wouldn’t purchase a “real” copy of office may find what they want in Google Docs, and would also be happy with a lightweight feature set of Office.

In Google’s defense, the products are worth what you’re paying for them:  Free.  But, you have to ask yourself:  If it wasn’t for the Google brand, would you give them the time of day?  For search, absolutely.  Finding an address and getting a street view?  Bring it on.  But don’t feel bad for depending on traditional software next time you want to buy a copy of Office, Photoshop, or use Outlook for your email.

It’s all SaaS These Days

Make no mistake, web applications, SaaS and Cloud Computing are all here to stay.  However, that doesn’t mean that there isn’t a lot going on in Client \ Server as well.  The key question to consider is how many applications you would have made, but done in another technology are being built as a web app instead?  There certainly are some, but for the most part web applications are creating entirely new spaces and solving problems that weren’t being solved before instead of replacing entrenched problems.  

Take document management:  On the surface this feels like a problem that should go entirely web and not look back because the web is very good when the readers to editors ratio is very high.  That said, the big document management companies still have very robust, integrated traditional offerings as well as their web portals.  You do have people using web document management solutions (like SharePoint) that never had document management before, which is a case of expanding the size of the market not replacing an alternative option.

When you are running your business, you have a set of requirements that are often best suited by a traditional client application:

• Users need advanced capabilities:  Once you stray out of the basics, it is invariably harder to provide features through web technologies than traditional technologies.  Tools are improving and making it better, but the cost per feature is lower in a modern client development environment than through a browser.  This is particularly true since you can put a browser in your app to enable things that it does really well – like show HTML content – you just let it do and keep the tricky stuff – like that big set of coordinated data entry fields – in your traditional app.
• Users are doing a lot:  One thing that is easy to lose perspective on is that when you run a client/server application every computer is bringing power to the party.  You often don’t need that strong a central server because the real action is happening out on the clients, and every new client that logs in is bringing their own muscle with them.  In the web, it’s all on the server. Not only that, but you’re rendering things in a less efficient way due to the stateless nature and limited protocols available for data exchange.
• Users need access to diverse data:  With web technologies it’s straightforward to manage information once you’ve brought it into the cloud, but it’s tricky to provide end users with fast casual access to a range of data in a range of formats.  In many businesses data is coming in pieces from many sources and being assembled to produce a coherent output.  This isn’t easy to do in any environment, and it’s one thing that the modern PC operating system, particularly Windows, has gotten very good at.  You can double click a file and almost always get it to open into a good viewer.  You can preview files, drag and drop from one program into another or a file into a program.  All of this is intuitive and fast for users that aren’t fitting into a pre-packaged user scenario.  

There are counter balancing effects:

• Transient user community:  The more far flung your people are, the more work it is to keep them up to date.  The more transient that user community is, the higher a barrier installation is.  This is the leading reason why you want to make something a web app:  It just isn’t worth the deployment effort to do it any other way.
• Diverse user community:  If you want to service Linux, Windows, and the Mac then web technologies are the lowest common denominator, it’s just the way it is.

What we’re seeing in the field fits into this:  People are creating a lot of new, lightweight web apps to solve point problems they probably wouldn’t have solved through technology before.  But they’re also still heavily investing in traditional applications.  

As a development team, it’s easy to get caught up thinking that Effort is the same as Value – just because something was a lot of work it must have a commensurate value.  The fact is, that there’s just no evidence that effort and value are correlated.  On the web, if you want to create a great looking and functioning generalized tool you’re signing up for a lot of effort.  And the value may be there – it could be that you’re going to reach a whole set of new users that otherwise wouldn’t use an application at all.  On the other hand, it could be that users perceive no extra value for it being in the web so all the extra work you put into creating the graphics, testing in five browsers, establishing identity, and the dozen other things you wouldn’t have needed to worry about if you were just running on the desktop netted you nothing.

So if you’re a business wondering how to approach that next application you need, don’t be afraid to get one that isn’t all wrapped up in Web 2.0 goodness.  In the end, it’s all about making the solution work for you and your users.