Underdo your competitionConventional 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 featuresLess options/preferencesLess people and corporate structureLess meetings and abstractionsLess promisesSomething 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. more »

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 areadable 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. more »

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 stIn the development environment, the same information needs to be masked for something like:LAST_NAME FIRST_NAME ADDRESS-------------- -------------- --------------------Ahd Uiea 55 xxxx ueIt 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 more »

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. more »

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 feedbackIn 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 debt with a successful product than a failed product. However, it's just not fair to present only one side of the argument! more »