Link: http://gettingreal.37signals.com/ch02_Build_Less.php

Underdo your competition

Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they're spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It's an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can't think ahead, they can only think behind. They don't lead, they follow.

If you want to build a company that follows, you might as well put down this book now.

So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.

We'll cover the concept of less throughout this book, but for starters, less means:

Less features
Less options/preferences
Less people and corporate structure
Less meetings and abstractions
Less promises

Something else that might be worthy of adding to 37Signals essay...

One of the suggestions I would add to the essay is:

“Keep less data”

Keeping a lot of data is a pain. Indexing, partitioning, tuning, backup and recovery – everything is more painful when you have terabytes instead of gigabytes. And when it comes to cleaning data out, it always causes endless debates on how long to keep the data (3 month? 7 years?) and different life-cycle options (move to “old data” system? archiving? how to purge? What is the process?).
What’s more, a lot of the time customers would really prefer we won’t keep the data. Maybe its privacy concerns (when we keep a lot of search history) or difficulty in generating meaningful reports or just plain confusion caused by all those old projects floating around.
Google taught us that all the data should be stored forever. But perhaps your business can win by keeping less data.

Pages: 1 · 2

Link: http://oradbdev.mathiasmagnusson.com/2010/01/the-case-for-case.html

By Mathias Magnusson, November 2009

The CASE keyword was introduced in 8i (9i for PL*SQL) and essentially replaces DECODE. I confess to never liking decode, though it is powerful, it is also ugly and sometimes close to unreadable. Case introduces a few things decode cannot do, but it makes it more accessible to those who write SQL occasionally.

In this document we will look closer at the keyword CASE in SQL. While it often is treated just as a
readable replacement for decode, it has a few more uses. Readability is a feature in itself, but the most misunderstood part of case among developers is how flexible it is.

This article will only look at the basic use and not try to dig into every aspect of it. Thus it is geared more towards the intermediate SQL user than to the experts.

A case for CASE

Link: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::NO::P11_QUESTION_ID:54226589195717#PAGETOP

Interesting running thread on Asktom.oracle.com regarding datamasking. I provided my two cents into the picture.

Does Oracle provide a package or function for data masking ? For example, in a
development environment, for data protection purposes, the information of the table
customer needs to be masked.

create table customer (last_name varchar2(25), first_name varchar2(25), address
varchar2(25));
insert into customer values('Doe', 'John', '10 someroad st');

In the production environment, if we do a select on customer, the result would be without
any surprise:

select *
from customer;

LAST_NAME FIRST_NAME ADDRESS
-------------- -------------- --------------------
Doe John 10 someroad st

In the development environment, the same information needs to be masked for something
like:

LAST_NAME FIRST_NAME ADDRESS
-------------- -------------- --------------------
Ahd Uiea 55 xxxx ue

It doesn't really need to make sense, it doesn't need to be readable. Just needs to be
masked. Does Oracle supply anything for that purpose at all ? I tried to find but didn't
have much success. I found a third party software that will do the job. If you want to, I
can post its name here.

Thanks Tom and happy 2006.

Gleisson Henrique

and we said...

No, we can "hide" the information (Oracle 9i provides for row hiding and Oracle 10g
provided for row and/or column hiding)

But data obfuscation - no, it cannot do that. You actually need to physically obscure
the data itself prior to storage (and it had better be a one way obfuscation). Think
about things like indexes and such.

Don't forget, as soon as you start obscuring data, you start to loose the natural
distribution of data. Do not be surprised when your obfuscated system behaves entirely
differently from your "clear text" system - clustering factors, data lengths,
distributions of values - all will be radically different.

I'll post to see if anyone has a suggestion on a tool to use sparingly on names/addresses
and the like.

Link: http://venturehacks.com/articles/minimum-viable-product

I recently say down with Venture Hacks for an interview. Part one is up on their site today, in text, audio and slide format. Here are some topics and excerpts of what we covered, edited lightly for how I wish I'd said it at the time. To hear full audio and a complete transcript, click through to Venture Hacks.

Is "release early, release often" enough?
The issue there is, if you just follow the release early, release often mantra, you find yourself running around in circles, because you ship code, you get some feedback from people, you do a focus group.

Customers say,”Give me feature X,” “Give me feature Y,” and sometimes you do what they want, maybe sometimes you’re going to do what you want, and then they get mad at you. Pretty soon you’re chasing your own tail a little bit because you’re not operating against a clear, long-term vision of what you’re trying to accomplish.

The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.

So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

Solving the chicken-and-egg platform problem
Developers don’t want to develop unless there are customers who are there to buy their products, and customers don’t want to come on the platform unless developers are there selling them something useful.

What we did is we took early adopter developers and we told them a story about how IMVU was going to take over the world and be this really powerful product for mainstream customers ... and we gave them an economic incentive that said, the earlier you get on board with the platform, the bigger your take is going to be for derivative products that get created down the road.

We shipped a product that had almost no customers — certainly no mainstream customers — but, because we had told that story effectively and we really understood those early adopter developers, we got a ton of them on the platform developing. They felt like they were in the middle of a gold rush, despite the fact that there was really no evidence to support that belief yet.

Starting with just a landing page

What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

What we would have found out if we were doing that experiment is 0% of people would have clicked through, which means it doesn’t matter what is on the second page.

The first page is so bad, not because it is badly designed, but because the features are wrong that you don’t need to go through the effort of building out the product. So we wished we had done that, and we did make that mistake really

Overcoming the fear of the false negative

As long as you’re not afraid of the false negative, that is, if you don’t get discouraged because you’ve built your first paper prototype of it and shown it to people and nobody wanted it. That can’t mean that like you give up because,”Oh, forget it, we’ll never make it.” You’ve got to say, "OK, well then let’s iterate some more.”

If you keep iterating at it, you keep making it a little bit more sophisticated, at a certain point after you’ve been through 10 iterations, that you still got no uptake whatsoever, and the feedback you’re getting from customers is still a yawn, you might say to yourself,”You know what? We’re not moving in the right direction. In fact, we’re past the point of minimum viable product. This just isn’t a viable product.”

Read the rest of the interview at Venture Hacks.

Link: http://adhdocddba.blogspot.com/2010/01/why-being-agile-without-long-range.html

...Cary sent me another link recently - this one is a blog post by Jason Cohen titled 'Releasing early is not always good? Heresy!'. I like it because it captures what I see as the shortcomings of the Agile philosophy but I won't attempt to summarize this one. (I'd like to get a little sleep tonight) Instead I'll reference a few of my favorite points and let you read the original on your own.

Take a look at the section describing the general line of reasoning behind the Agile methodology and notice the difference in scale between the bullet points that follow. Think about it. While it is certainly possible to address bugs or rewrite an interface in a month, can you really address the root cause of a scalability problem in the same amount of time? Or fix a flawed architecture? These bullet items are not equal yet some Agile proponents treat them as if they are. Some components in a design need to be flexible and are expected to change many times over in the early design period. But replacing the architecture is a whole different magnitude from changing a screen or fixing a bug, and user feedback shouldn't be driving the architecture or data model anyway. Some components of an application should be transparent to the user and those components should be designed based on the long term goals of the application. True, you don't want to build the architecture now for future processing needs, but you can develop a plan for extensibility that will minimize disruption when those extensions are needed.

Perhaps the most important point Mr. Cohen makes is that great designs aren't built by consensus. If you get a group of people together with different viewpoints and skills, the result is likely to be average at best. Someone may suggest a truly groundbreaking idea but the more cautious team members are likely to push for less risk, while others will push for more resources in a different area and by the time all the compromises are added, the result is a lowest common denominator type of solution. (Congress attempting to pass the healthcare bill is a great example of design by committee with a less than optimal result) Great design needs to begin with a vision to provide a useful tool for the end user. There needs to be a plan with a desired destination and someone needs to make sure that the iterations keep the momentum moving in the right direction. Otherwise, you just end up nowhere very fast and that's not the kind of talk anyone wants to generate among their customers.

Posted by Robyn at 12:47 AM

Excerpt from article

Items against Agile

• The best ideas aren't built by consensus
• Apple doesn't ask customers what they want
• You're misinterpreting the 80/20 rule
• Mock-ups are faster than code iterations, without some of the drawbacks
• Releasing too early can ruin your reputation
• Ignoring architecture creates waste
• Untrue: "The worst thing you can do is built an unnecessary feature."
• Customers are notoriously bad at providing feedback

In the end, of course it's better to have more feedback than less, better to be more agile than less, and better to have technical debate with a successful product than a failed product. However, it's just not fair to present only one side of the argument!