Archive for the ‘Software’ Category

Why Didn’t it Take Off? Pathology of a Floundering Web 2.0 Startup

May 25, 2008

Tipjoy is a web startup for tipping web authors/personalities funded by Y Combinator. It went live in February to decent press coverage. The concept is simple—if you see something you like tip the author by either clicking on participating author’s link, using the Tipjoy bookmarklet or going to the Tipjoy site and entering the URL.

It’s a good idea and the founders have worked hard to overcome a number of the inherent problems with small money transfers. However, there’s one little problem remaining. It’s not generating revenue.

On the main page of Tipjoy the technically savvy, but perhaps not as financially savvy, authors post their latest statistics:

 $2,519.01 (red arrow) is not a large sum of money. Compound that with the time period indicated by the blue arrow. Elsewhere in the site founders explain that they charge a 3% transaction fee. In other words they pulled in $75.57 over 4 months. Nice. Probably doesn’t even cover hosting fees.

Of course this isn’t the full story. There is likely between a few hundred up to a few thousand dollars sitting in accounts either waiting to be given out as tips or claimed by the tip recipients. With money markets at around 2.5% that may represent another $20 in interest. Thrilling.

It appears the failure to generate revenue has had it’s costs. The founders haven’t blogged for nearly a month—and previous postings are uninspiring to say the least. It seems that around the end of March the founders attention wandered from the site—after less that 2 months live! How many successful businesses ever got it right in that short of time? <Right now imagine a typical rant about generation Y’s failure to follow through>

 OK, now clear those thoughts. Generation bashing is never fair. Let’s look at the site itself.

 First, what’s right.

  1. Design: It’s an easy to understand, easy to use site. The color scheme is clear and inviting.

  2. Concept: The idea is simple and the implementation is straightforward.

  3. Technology: Excellently implemented. The site isn’t foundering through lack of technical expertise.

  4. Ease of use: It took about 15 seconds to sign up. Try it.

 So what went wrong wrong? Let’s disassemble it a bit:

Product: In my opinion the product stinks. No, not the idea. The idea is great. Not the implementation. It’s a solid web site. But the product. Let me illustrate. As you may know I live in Tennessee and it gets hot in the summer. A few years ago a deer got hit by a car along the road I drive to work. After a few days of that mid-summer heat that thing could be smelled from nearly a mile away. Some people may take from that experience that deer stink. Well, not all deer. Rotten deer. This product is rotten.

Tipping is a very abstract “product”. “Social well being” is probably as close as it gets. One evening my wife and I dined at our local Olive Garden and by bad luck ended up with a barely competent–if that–waiter. Luckily the lady serving tables near us was very good and bailed him out a couple times. Understandably his tip was very small. But on the way out the door I slipped her a couple bucks. She felt good and I felt good.

Replicating that experience on-line is difficult. Tipjoy is notably lacking in that regard. The main page is made up of a bunch of (dry) statistics. Hello, this isn’t Microsoft Excel! What are they trying to sell—business analytics?? Where’s the sidebar advertising how your Tipjoy data can be added to your Facebook/Myspace site? Where’s the banner that says “Show your girlfriend you really like her latest Facebook post?”. Where’s the “attach a message to the tip” feature? Tipjoy is a social site—it must market itself as a social service. It must integrate into life, or life will continue to pass by outside of it.

Advertising: People have to know about a site in order to use it. Tipjoy did enjoy good initial coverage from TechCrunch and other scattered outlets. However, it lacks long-term support. If I were them I’d contact as many bloggers and Myspacers (if that’s what they’re called—I’m getting too old school for that stuff) to include links on their sites. Tipjoy must become integrated into the social framework.

And one last thing. No credit cards? Hey dudes, it’s 2008, Web 2.0. Instead of “Coming Soon” it should say “transaction charge”. Leave the choice to the consumer.

Lesson: To succeed in Web 2.0 your site can not be an optional layer added to people’s lives. It must be inserted directly into the lives of the consumer. Until Tipjoy finds that recipe it can only founder.

Like this article?  Leave me a tip

 Disclaimer: I have no investment in Tipjoy, nor do I have any business relationship with the company. I don’t know the founders personally, but best wishes to them. I have only the greatest respect for anyone who has the guts to start a new company. My analysis may sound harsh, but remember that anyone who gets as far as Tipjoy is clearly a star.

Want the same analysis on your web 2.0 business?   See the about page for details


The Meaning of (Software) Quality

February 14, 2008


I had just finished reading a bedtime story to my young son, but before putting up the book I flipped a few pages to see what was coming up and came across a nice full page COLOR picture. Keep in mind this book is an original 1950 edition of Uncle Arthur’s Bedtime Stories. In 1950 color was not an easy or affordable technology. The color photos were carefully chosen and strategically scattered—one every few chapters. My son and I paused to take a look at the picture before putting the book up.

Color photos are a dime a dozen now.  I get fancier printing on credit card offers. Yet, a slightly grainy 58 year old photo still had the capacity to engage. It was something extra that had been put into the book on purpose to make the book extra special. In short, it had quality.  Quality that was still obvious 58 years later.

Quality in Software

Of all the traits we strive to put into software, quality is one of the hardest. Merriam Webster defines quality as “a degree of excellence”. But excellence at what? At the most basic level quality is a measure of functionality.

Base Definition: Quality Products are Accurately Specified and Match the Specification

That doesn’t necisarrily mean a formal set of “design documents”. However, every software system needs to have a clearly defined purpose and it needs to actually work! We spend a lot of effort on this—requirements analysis, use case analysis, unit testing, regression testing, etc. And for good reason.  If the software “doesn’t work” it will never achieve anything. However, once we’ve satisfied this basic level of quality we should move on to a higher quality.

Advanced Definition (Inherits Base): Quality is the Delivery of Exceptionally Meaningful Features

This is “fuzzy” and “illogical” and that’s OK. A good illustration is the classic Star Trek tension between Mr. Spock’s Volcan “logic” and the “illogical” humanity of the rest of the crew. Software is typically approached with a Volcan perspective–which is OK when defining specifications and testing logic.  But software is for humans. It’s the human quality that allows iTunes to realize that when I put a music CD into my drive it means I want to rip it. (Media player thinks I want to click on the “CD” tab and then click the “RIP CD” button)  Microsoft misses from time to time on the human level, but it has made some hits.  When Word started suggesting spelling corrections as a right-click mouse button option I was overjoyed–no longer did I have to wait and spell check the entire document and loose my sense of context.  I could correct my mistakes immediately, in context, as if they never happened. I still feel a sense of liberation each time I zap a misspelling. 


Quality is a two sided coin.  Quality is about accuracy, but it’s also about emotion.  Quality software must work.  But it also must give something meantinful to the lives of the people that use it.  “Meaningful” may be “fuzzy” and “illogical”, but it’s what divides the accurate from the fantastic, the good from the great.

Microsoft’s Yahoo Blunder

February 3, 2008

 The news of Microsoft’s 40 billion offer to buy Yahoo astounded me. (CNN) Almost in a daze I listened to it again and again on one media outlet after another. All reported the same story: Google is gobbling up the lucrative Internet advertising market and Microsoft wants a share. I’ve seen some bad business moves—Time Warner’s purchase of AOL for example. But this one tops the charts. Not only will it fail. It will fail spectacularly.

Microsoft has had a remarkably successful run selling software. I use this term rather loosely since much of the software it sold is operating system code. Selling “code” may be a better term. Excluding a few minor (and late) exceptions—such as the Xbox–Microsoft made its fortune selling code.

In the early days selling code worked well. In fact, it was the only model around and it still works well in niche markets. In the 80’s anything computer related was by modern standards a niche market. Microsoft focused on owning the largest of these niches and rode those markets to stardom. Microsoft still thinks in terms of owning software market space. Even worse, Microsoft seems to think that everyone else thinks that way too.

This is where Microsoft comes into direct ideological conflict with Yahoo and Google. Yahoo and Google do not sell software. They sell advertising. Yahoo and Google don’t act like software companies. They don’t think like software companies. Because—they aren’t software companies! They are advertising companies. Microsoft doesn’t understand the advertising business. Most people don’t. Although it’s a very simple business.

Definition: Advertising is the art of consistently drawing lots of attention.

That’s it. Find a way to consistently draw attention and you have created advertising space. If you don’t believe me—think about the Super Bowl. It is the king of advertising. Why? It gets LOTS of ATTENTION. World class sports and world class entertainment rolled up into one massive show available for—you guess it—FREE.

Google has been winning the war on Internet advertising war because it’s really good at getting lots of attention. In addition to providing the best search engine on earth Google has found another way to get lots of attention: Offer free software services. People flock to Google services by the millions. Google doesn’t really care about the “code markets” it’s poaching. It doesn’t even think in terms of “code markets”. Google is just looking for “cheap” attention—and it’s getting it. The fact they have eaten up some of Microsoft’s “code markets” is mostly an accidental byproduct of their business plan.

Yahoo is very similar to Google, just less successful. In order for Yahoo to regain momentum it must capture advertising space (i.e. get and hold attention) quickly. That will come in direct conflict with the existing Microsoft for-sale software model. Microsoft will never let Yahoo poach any of their “code markets” until those products are no longer producing significant revenue. By that time Google will have poached all the useful advertising space and moved on. A merge with Microsoft is the death-knell to Yahoo’s ability to compete with Google.

On the other side, Microsoft gains very littel from Yahoo.  An advertising company has very little in common with a niche software company. It can do nothing to defend it from Google. Microsoft may gain something in intelectual property and people, but certainly those things can be aquired much more cheaply from small startup firms. Ultimately, the main problem with the Yahoo acquisition is it will distract Microsoft from what it really should be doing—abandoning declining niches (like OS and Office Products) and moving into new niche space. The purchase of the ProClarity business intelligence suite was an excellent start down that road. Microsoft needs to build on those kind of small purchases.

I predict that if Microsoft goes through with the Yahoo purchase it will find itself caught between being yesterday’s niche software player and tomorrow’s advertising company and will fail at both.


Disclosure: I do not own any positions in either Microsoft, Yahoo or Google.

Twelve Lessons From Writing Documentation

November 18, 2007

We all believe good system documentation is important, but who actually does it?  The typical corporate IT system documentation usually consists of repository comments, a few moldering requirements documents abandoned on some network share and maybe a few inline code comments.

A couple years ago I finally tired of the standard “documentation process” and actually started to document some of what I do. 

Here are some lessons I’ve learned:

1) Like any skill, writing documentation improves with practice.  As skill improves it also becomes more fun.  (Yes, I said fun.  It really *can* be fun)

2) Some of the “classic” documents (requirements for example) turn out to have a very short useful life.  Other nameless documents—instructions for running a complex script—turn out to be highly useful.

3) Documentation is best written in short segments.  I use a wiki—it facilitates the kind of quick, “jot down an idea” thoughts that are often the most useful.  Writing in short segments also keeps it from getting boring.

4) Documentation must be easy to update.  Otherwise it gets out of date and looses the trust factor.  Again I really like the wiki for that.

5) Documentation must be easy to search.  Anything difficult to reference—like the traditional formal document stored on a shared drive—simply won’t be used.

6) Documentation is for programmers and users, not management.  Keep it professional (even if the document on multi-threading seems like it deserves that explicative!), but casual.

7) Keep documents small.  I prefer 1 to 2 printed pages.  If any single document is more than 3 pages long its coving too much ground and should be broken into its component parts.  It’s easier to navigate short documents and they are easier to search.  (Fewer false positives)  Leverage the power of the hyperlink!

8 ) Scale the documentation.  Systems are naturally hierarchical.  Systems break into sub-systems, which become classes and so on.  Let the documentation naturally break out into patterns that fit either the architecture, or usage of your systems.

9) Its OK to have documentation outside the code.  Documentation that’s tied to specific parts of the code should be in the code–class and method documentation for example.  But system and subsystem documentation may work better in a wiki.  The important thing is that the documentation is easily accessible and universally recognized as the place to go. 

10) Not all documentation is code related.  (For example, a dictionary of business terms/acronyms) There needs to be a place to store non-code documentation.

11) Documentation should answer questions of what, where and why.  The code already answers “how” so don’t waste time on that.  For those who think code is “self documenting”, just try to write code that explains why a particular design or architecture was chosen instead of a competing alternative. . .   Some of the most useful comments are ones like “we tried doing… but that turned out to be a bad idea because. . .”

12) Documentation should be shared.  The more eyes that see it, the more valuable it becomes.

But in the end, the biggest lesson–the person who uses my documentation the most:  me.  I’m amazed at how often I go back and read something I wrote to refresh my memory on a certain system, process or whatever.  The time I’ve spent writing has easily paid for itself just in time saved from re-researching.

What Else to Learn at University

October 4, 2007

The other day I joined in on a short conversation between an intern and a full time developer.  They were discussing what a university student should learn in addition to what’s taught in the classroom.  They weren’t talking about make-up work for an out-of-date curriculum.  (Which unfortunately is so common)  But truly how to go from good to great.

Here are some of the ideas that came out in that conversation and what I thought of later.  If you have any other suggestions please feel free to add your comments below.

1)       Master SQL.  Data is the core of nearly every system.  While the database schema may be generic, the data in the schema is the least generic piece of the system.  All the quirks and undocumented requirements of the business will quickly find their (often ugly) way into the data.  Strong DB skills are essential to create and maintain effective and efficient systems.  Bosses are always on the lookout to pick up job candidates with stronger than average database skills.


2)       Learn a DB language.  T-SQL and PL/SQL are easy to learn and extremely valuable in the workplace.  Very few students graduate with DB language skills.  The few that do have a massive advantage in the job market.


3)       Watch out for teaching languages.  Explicit teaching languages like Pascal are a thing of the past, but languages that are taught a lot (C++ and Java for example) carry a lot of baggage.  First, everyone knows them.  Each job opening in that language will have dozens of candidates—many with prior experience.  Second, the language is usually not growing quickly so the opportunities for advancement are limited.  You should master the teaching language—but don’t bet your economic future on it.  Instead, learn a non-teaching language.  Find a language that interests you and has a growing job market.  Master that language.


4)       Get an internship that uses your non-teaching language of choice.  If that falls through—get a different internship.  Practical experience in the “real world” simply can’t be matched in the classroom.


5)       Do a bootstrapped startup.  Build a software product and sell it.  But whatever you do, don’t spend a dollar on it that the business hasn’t already earned.  The point of a startup is experience—hiring someone else to do the dirty work will give them both the experience and your money.  Don’t waste it.  Grow slowly and leverage momentum.  Become the world’s expert in the product you are developing and selling.  You’ll either succeed or have a very impressive resume or both.


6)       Be balanced.  Writing code is not everything.  I am not referring to beer bashes–the party life will do little more than lower your grades.  (One imballance is never corrected by another.)  I mean seriously engage in life outside of computing.  Volunteer, attend church, sing in a choir and play in intramural sports.  The great secret of technology is that writing great software is only half about technology.  The other half is about people.  Great systems can only come into being when the people who write them understand people, their needs, their dreams and their desires.  Software must be shaped to be human.


Far too many lines of beautiful code are written that no one will ever use because they don’t do anything useful for anyone.  It is such a shame.  Great software can only be written when the walls of isolation between IT and non-IT are broken down.


I was fortunate to attend a small Christian school that not only has a top notch CS program, but also a great liberal arts curriculum.  Rubbing shoulders with English, PE, Nursing, Religion and Psychology majors on a daily basis enriched and widened my life in a way nothing else could. 

There was the supper at the cafeteria where a psychology major friend of mine played a small (non-embarrassing—thankfully!) psychology experiment on me.  Then explained the experiment and its’ meaning.


There was the athletic friend who twice tried to teach me how to hit a golf ball (and failed miserably)


And on and on


Learning to understand (and appreciate) the different skills and ways of thinking of the “non-technical” world has paid off over and over in the years since.

Is Leadership a Programming Skill?

August 15, 2007

The other day I posted an article on leadership to  Within minutes it had been voted down.  The article was popular elsewhere so it wasn’t the article.  Apparently the consensus is that leadership doesn’t fit with programming.  I disagree.  Here’s why leaderships *IS* a programming skill:

1) The Trend Towards Integration
The days of isolated systems that don’t communicate with other systems disappeared years ago.  We are often called upon to write code that forms the glue between various systems—and various groups of people.

In my own job I often find myself working directly or indirectly with dozens of people.  The social integration task may be as much of a challenge as the technical task.  Programmers must be able to effectively work with different people in different roles. 

2) Projects are Bigger than One Person – And Include non IT members
One day I learned of a system problem and went to talk to with the clerk who reported the problem to get more information.  To my surprise the problem had started days before, but it wasn’t a big enough to bother his boss about.  I didn’t hear about it until it had reached the minor crisis level.  I immediately made a mental note to add this clerk to my “team”.  From then on I regularly checked back to find out if any new issues had come up.  It didn’t take long for him to learn the scenarios that indicated potential problems and he would report anything strange that came his way.  The result of this team: timely first-hand information and some good PR for IT.

Programmers tend to see their team as only fellow coders.  The many programs that poorly fill user needs are evidence enough of the harm this causes.  Effective programmers draw the user community into the “team” and together work towards common goals.  Tactfully overcoming geographic and organizational hurtles are as much a part of a programmer’s job as design patterns and class hierarchies.

3) Effective Leaders Know How to be Good Followers
Good leaders know how to organize and focus efforts on the task at hand.  Those skills make it easier to contribute to any project—regardless of who is leading.  If you don’t have the humility to be a good follower, you won’t be a good leader.  People don’t voluntarily choose to follow someone on an ego trip!

4) The Ego Problem
Let’s face it—a large percentage of the people in IT are in it to feed oversized egos.  (From time to time that has included me!)  The results are devastating.  Leadership contrasts self absorption by focusing energies on improving the community.  Over the last few years I’ve seen a lot of positive growth in this area.  The growing strength of the open source movement is a powerful testimony to great attitudes of so many programmers.

In university I decided not to be a programmer because I enjoy people too much to stand the idea of spending 100% of my time staring at a computer screen.  Thankfully, that detour didn’t last too long.  How misinformed I was—I can’t remember the last time I spent 100% of my day starting at the computer screen without some break to work with a colleague, answer a question, discuss a design, etc.  Computers were built by people and for people.  The human factor can never (and should never) be removed from that equation.

Jeff Staddon is a full time software developer living near Chattanooga, TN. USA


Jeff’s Book Recommendations:

Probably due to it’s title, The Effective Executive, this book is amost unknown inside of IT. However, I found it to be very useful. (It’s really about being a effective knowledge worker.) While aimed at management most of the content is applicable to any IT role.


Hints for Self Management

August 6, 2007

In spite of the micromanagement horror stories that regularly appear on the whole IT is very self-managed.  Unfortunately, most of emerge from the university with little more than “Introduction to Management”.  Until the schools start addressing that shortfall here’s a crash course.

Peter Drucker in his classic work The Practice of Management identifies 5 key areas of management*.  Here is that list (minor modifications) with thoughts on application to self-management.

1) Set Objectives

Software systems typically start out a mess—and get worse over time.  One of the reasons is that so much is done for the short term with little long-term focus.  Force yourself out of that mold.  Look ahead 3 to 5 years.  Use designs that anticipate needs for change.  Refactor and fix old code.  Think long horizons.  Daily objectives are fine—but it’s better to think of accomplishments in 3 to 6 month time segments.


2) Organize

If you work in a typical corporate IT shop, you are probably equipped with some sort of automated to-do list.  (They go under a dozen names—ticket system, request system, etc.)  It is tempting to think that the system alone will organize your work.  While useful, it certainly will not organize.

First, users don’t report everything.  At best the system will contain only a slice of your user’s real needs.  Furthermore, if you have much of a backlog, much of that slice may be out of date.  Simply pulling the highest priority request does not mean you’re fulfilling the user’s real needs.  If at all possible, get to know the users and what they are trying to accomplish personally.  Then pick what you work on accordingly.  Every minute spent understanding the world from their perspective will pay back in hours.


Once I spent weeks coding a piece of functionality.  After a few days I began to wonder if it really made sense—but it was requested so I proceeded.  I finished it up and demoed it to the primary user.  She looked up and me and said “You aren’t going to like this”.  Yes—you guessed it–two weeks work, completely thrown out.


In addition to incompleteness, automated systems come up with a random ordering of requests are not technologically related.  (Even if categorized—the categories are the users, not yours)  Technological schizophrenia results in high context switching costs and high costs from lack of learning–you never work at anything long enough to learn it deeply enough to do a quality job.  User requests must be groups into technically logical units and worked on in concert.  However, this must be compatible with the user’s goals—another reason to take the time to get to know the user community and their goals.


3) Motivate and Communicate

Software developers are notoriously poor at documentation.  One of the main problems is so much documentation is so formal.  Formal documentation is no fun to write and rapidly gets out of date.  I’ve found that informal in-code documentation and wiki sites are far more effective. 

When writing documentation—think big picture.  What does this system do?  What does this class do? Etc.  If (when) your code gets into the hands of another programmer they can always figure out the details (by reading your code), but they won’t know the reasons behind your design decisions.  Understanding how a system was shaped can really help in making decisions to modify/extend a system.  In short—don’t document code: document design.


4) Measure/Evaluation

All the great software developers are I know are pretty brutal self evaluators.    We are probably too good at self evaluating and undermine our own (and others) confidence.   Keep in mind mistakes and errors are statistically random.  Some days are going to be worse than others.  If you aren’t creating a few errors—you probably aren’t writing much code.  J

5) Personal Development

Read, read, read.  I spend my lunches reading blogs like Joel Spolsky’s at  Get involved in local user’s groups.  For example–my hometown’s .Net user’s group (  Sometimes bosses will even let you cut back on work time to attend meetings.  J


*The Practice of Management  Page 333, 334

** For a great series on (real—not self) management in Software see Joel Spolsky articles starting with:

Database 501

July 23, 2007

Back in my university days none of us were very enthusiastic about database class.  We were future programmers, not data administrators.  We understood that school is full of pointless challenges set up by “clueless” administrators.  But, most of us persevered and made it though such drivel as database class.  Little did we know!


During my first summer internship I was introduced to data driven web programming.  Two or three properly designed tables with the appropriate data could generate hundreds of web pages.  I was hooked on data.  And I’ve been hooked every since.  During the years I’ve picked up a few basic principles.  Most of these ideas can be found in database classes, but perhaps not described exactly this way.


A)  Make it Easy to Remember Field/Table Names.  (Looking up objects takes a lot of time and can easily derail thought processes)

1)       Use full names unless for everything except for extremely common abbreviations.  (Like ID for identification)   It will take at least a minute every time you need to look up the name of a field you’ve forgotten, but only milliseconds to type in some extra characters.  Optimize for remembering not typing.  (Oracle’s 30 character limit is a sad relic of a previous age)

2)       Use the same name for the same piece of data.  For example, if everyone has used date_added, don’t name your field added_date.

3)       The same applies to work breaks.  If the convention is to use underlines, use underlines.  CustomerNumber may be more “pure” than customer_number, but making everything consistent is more important.


B) Make it Easy to Identify Fields/Tables

1)       Identify keys with the table they belong to.  For example account_id is a good key for the account table.  sequence_key is a really bad field name.

2)       Preface tables with system names.  For example sales_accounts, sales_transactions etc.  However—I’ve seen this one misused.  Don’t go overboard.  Many systems are highly integrated and prefaces can be more confusing that beneficial.  If you will find yourself asking “Now was “items” in manufacturing or sales?” then use the same preface for both systems.


C) Be Prepared for Change

1)       Never believe anyone when they say a field will never change.  Use auto-sequence keys rather than natural keys for foreign key references.  When the natural key changes (notice I use the word when not if) the only thing that will need to change is the natural key’s index. The foreign keys can (and should) remain unchanged.


D) Appropriately Use Normalization

First and foremost–a transactional system should be normalized.  Normalization is not “academic”.  Nothing is more practical than a well designed database structure.  Allowing duplicate data to sprout across a system may seem “easy”, but in the end it will results in hundreds (even thousands) of lines of code merely enforcing data consistency.  There’s no reason  that code should handle what a database was already designed to handle.

However, there is an exception to the normalization rule.  Non-transactional reporting data should not be normalized.  For example, consider a typical transactional system with an inventory table, an item master table and a sales history table.  In a typical environment, when the item master is changed, we would want to see queries against the inventory table reflecting those changes.  (i.e. using a join between inventory and items)  For example, say a price change or minor description correction of a certain part/product.

On the other hand, if we are querying against the sales history table, we do not want to see the changes in the item master.  We want instead to see the sales data at the time it took place.  Even if it’s inside a typical transactional database driven system, the sales history table is actually a data-mart/data-warehousing table.  In data warehousing the rules totally change.  There are still rules—just different rules.  A data warehouse is not normalized.  Instead, you snapshot all the data needed for reporting.  The result is a wonderful (for reporting) set of completely static de-normalized tables.  Unfortunately, most software developers have not had any experience with data warehousing (mine own is extremely shallow) so we often try to apply normalization rules and fail miserably.

This is not revolutionary—data-marts and data-warehouses have de-normalized forever.  What is new is the recognition that even small systems often have data-warehouse style tables mixed into the typical set of “normal” tables.  (A common example of a data-warehousing table would be an event log)  The key to properly designing such tables is recognizing what they are and applying the appropriate design principles.  (And above all don’t try to have one table accomplish both—it won’t work)


E) Leverage the Power of the Database.  These should be obvious. . .

1)       Always define datatypes – varchar aren’t a substitute for any kind of data.  Generic expansion fields (attribute1, attribute2, etc) are equally evil.  (An unavoidable one for those of us working with Oracle applications.  L)

2)       Don’t put comma separated values inside database fields.  (Yes, I’ve known this to actually happen)

3)       Leverage the power of database programming—PL/SQL, T-SQL, etc.


If any of ya’ll have other suggestions please comment below. 

Ps. I reserve the right to delete “religious” arguments if they get out of hand!