Tom Petrocelli's take on technology. Tom is the author of the book "Data Protection and Information Lifecycle Management" and a natural technology curmudgeon. This blog represents only my own views and not those of my employer, Enterprise Strategy Group. Frankly, mine are more amusing.

Friday, May 28, 2010

The Great Untruths

There is a difference between a lie and an untruth. Neither is true but a lie is intentional. So, when I say that something is an untruth instead of a lie I am making a value judgment. The assumption is that someone did not tell the truth but didn’t know that it was not true. Instead, they were ignorant, got too excited/upset/scared or are parroting back what might be another untruth or lie.

A lot of products fail (and some fail dramatically) because of untruths. If an untruth slips in during a crucial phase of development a very bad decision will be made and bad product will emerge.

Here’s some of my favorites.

Everyone Wants This!

You hear this from sales and marketing people a lot. Someone comes back from a trade show or customer visits and hears about a feature that “everyone” wants. There are a couple of untruths rolled into one here.

First off, who is everyone? I can’t tell you how many times it turns out that “everyone” is one person. After hearing it one time, the sales and marketing team feels compelled to ask others about it. They usually get a “Sure. That sounds good” type response. It’s really a sample size of one with all other responses coming from a poisoned well.

More importantly, people often want a great many things that they aren’t willing to pay for. There is a difference between wanting something and needing it enough to turn over money out of a limited budget. This is why there are a lot more Ford Focuses on the road than Lamborghinis. Everyone wants a Lamborghinis, just not enough to pay for it.

Finally, customers don’t often know what they want or even need. Instead, they have problems that need solving. Asking a customer “Do you need this feature?” will get you to the untruth. Asking “What do you need to accomplish your goals” will get you to what they really need to do and might be willing to spend money on.

We Can Do That Too (Version 1)

Someone (Sales, Marketing, a customer perhaps) comes to the development team with a request in the middle of a project. This is commonly called scope creep. We’ve all seen it because it happens all the time. Sometimes, it’s no big deal. Other times it kills products. You can’t just add things without ramifications.

Scope creep kills products in two ways. One, it loads products up with a ton of features that make it bloated. In the end, by trying to please everyone you please no one. You also trash your margins.

Often when faced with these requests Engineering will say “Yes! We can add that.” This is an untruth. Technical folks are, by nature, builders, makers, and fixers. It’s in the DNA. Pride comes from the ability to create something that people will say “Awesome!” to. The last thing they want to say is “We can’t do that.” So they say yes but neglect to mention that they lack the resources or even the expertise to accomplish it. Look out for the techie that says “No problem. We can do that” without first doing some analysis. You will not find out until much later that they are trying to figure out how to do something that they simply cannot do.

We Can Do That Too (Version 2)

Another flavor of “We Can Do That Too” untruth is timeline reboot. Like the new Star Trek movie. If the technical team knows that they have the expertise and resources they will instantly say yes to a new request. Wonderful! However, what they don’t tell you is that they don’t have the time. You find that out when you sit down to review a project and realize that the technical team just assumed that the timelines were extended. The real request is “Can we add this without changing the timeline?” The untruth is saying yes to that knowing that is what is meant.

I can already hear the response – good project management will head this off at the pass. That assumes that the technical folks ever communicated the new timelines to the project manager. I can’t tell you how many times I’ve seen technical teams develop a new timeline in their heads and never mention it to anyone. Their intention was always to stick to the old timelines but when it becomes apparent they couldn’t they extended it and added a touch of collective amnesia.

Who hasn’t heard “The trade show is in two weeks?! How come no one told me that?” Of course you did but they need to save face. It’s about pride again.

We Can Fix This

About the worst thing that can happen in the middle of product development is the realization that something is terribly wrong. You hit a technical snag that was completely unexpected. Unfortunately, some problems are too big or costly to fix. But that’s not the bad part.

The great untruth is believing you can fix the unfixable. There are just some problems that are insurmountable and this is when you shut down the project. A lot of technical folks don’t know when something is unfixable. The assume that with enough time they will come up with a solution. Before you know it every last drop of resource in the company is engaged in trying to find a solution to an intractable problem. The idea of cutting one’s losses is rejected, more out of pride than anything else. This is when you have to swallow your pride and stop fooling yourself. Then you can find a real solution like buying the technology from someone who has figured it out. Or perhaps dropping the feature that wasn’t going to generate much revenue anyway.

I’ve seen this happen with businesses too. Some businesses face a problem they can’t handle no matter how much time, effort, or money they put into it. They destroy all the value in the business in a quixotic quest to find a way out. Sometimes, the only way out is by the door. What’s especially bad about this situation is that opportunities to scrape something out of the business by changing direction, selling the business or divesting of some it its assets are lost. Here’s to tilting at windmills.

Everyone Else Already Has This

I always leave my favorite to the last. This is by far my favorite untruth. To justify more resources, a new feature, or an accelerated timeline someone will declare that you are behind the curve and this is a feature that everyone already has.

The truth is more likely that they have only made announcements. They might even be working on it. It is even possible that one company has an early version of it. Rarely is there a critical feature that no one anticipated that everyone but you has. Everyone does not have this feature yet. Freaking out over it will only cause you pain.

This type of hysteria can derail a development effort. It results in a lot of time and money going into an early feature that no one is ready to deal with yet. Not you and not your customers. The trade off is almost always dropping something that your customers really do need for something that is new. Listening to competitor’s press releases can be dangerous to your product health.

I want to stress again that no one does these things on purpose. Pride and fear are at the root of these untruths. They are powerful emotions. When the emotions are genuine they can make nothing seem like something. It can even be hard to ask questions about the validity of untruths. The people uttering them believe them and will feel like they are being attacked if you question their perceptions.

If you suspect an untruth here’s a tip: ask for time to look into it. Don’t make a decision right away. Ask sales or marketing to generate a revenue estimate for the new feature or a competitive analysis so that you “can be prepared for launch.” Ask the technical team for a revised project plan so that you can better plan your launch. Let them discover their own untruth and they will be less likely to react emotionally.

Whatever it takes, don’t let the untruth guide you.

Monday, May 17, 2010

Building Castles in the Clouds

Despite my best intentions, I keep having conversations about cloud computing. This probably means it's almost in the mainstream. As both of my faithful readers know, I've been a bit critical of cloud computing. Not so much the idea of cloud computing itself. It's more about everyone piling onto the concept even where it is inappropriate. I also find the discussion of private versus public clouds mostly irrelevant. That's a business decision related to how you want to cost out IT. It has nothing to do with technology.

Having had a bit of time to think about it, here's what I think it is and isn't about. In a nutshell:

  • It's about running enterprise applications, wholly or in part , somewhere out in the IT infrastructure. You don't care where so long as it's somewhere appropriate. From a software perspective, it means instantiating application objects but not caring where that happens so long as it meets the needs of the object.

  • It's about metered usage, either as a service or in-house. Paying for only what you use is very attractive.

  • It's about better application resource utilization. You save money when you don't overbuy. Another way to look at it is that you align resources to how critical something in the application space is.

  • It's about flexibility. Being able to run application objects anywhere in the infrastructure means less dependence on certain assets. Makes for better availability and more cost savings.

  • Public versus private cloud arguments are only valid or relevant when talking about how you pay for IT. If it is in your best interest to convert a CAPEX to a variable expense, by all means go for the public cloud. The same is true when thinking of personnel costs. You might not have the expertise to run a private cloud so you either hire or go outside. These are classic outsourcing decisions.

  • Often, a cloud uses a virtualized hardware environment (storage, servers, and networks). but it doesn't have to. The virtual application space is what matters. That's why we have middleware.

The last point is key. While virtualized servers and storage provide a great environment for running a cloud, it's not necessary. It's the middleware environment that matters. For example, a lot of what we think of as cloud computing is achievable using existing Java 2 Enterprise Edition (J2EE) technology. J2EE environments, such as JBOSS, perform all the tasks needed to build a cloud. It handles:

  • Persistence

  • Coherency

  • Distribution

  • Synchronization

  • Object Caching and Reuse

J2EE allows you to instantiate objects on any physical server running the J2EE application server. It doesn't matter if that server is virtual or not. While that might be a good idea, it's not necessary to make a cloud.

One look at Google's cloud SDK tells the story. You import a library of Java objects that interact with the Google cloud and voila! Your application objects are running in their cloud. You could conceivably run some objects in their cloud and others in-house. It's not that easy of course but pretty close. Google provides all the infrastructure that you need to instantiate and manage application objects elsewhere. How they do it is unimportant.

The ultimate cloud would be virtual everything of course. That way you get maximum alignment and utilization. Virtual servers using virtualized/federated storage, with middleware that provides a virtual application space would meet the needs of a cloud nicely.

But in the end, it's the software that counts. The application is what it is really all about.