This Application Has Unique Business Rule Needs

No it does not. If it did, then your customer/employer
would be
doing something no other human being has ever done, which
is unlikely in the extreme. The application may be
unique in its particulars, but it is almost certainly
extremely common in its patterns. This week we will see
how "unique" needs are in fact nothing but common ordinary
development projects.

Beginning With the Conclusion

I have had this conversation with many programmers over
the past few years, and it always follows the same
patterns. The easy part of the argument is showing the
programmer that what he thinks is special or unique
is in fact common. The much harder part, because it
involves the delicate human ego, is showing the programmer
that he has not seen this because he is ignorant. This
is not fun to do and I myself usually skip it, it's
usually not worth the trouble.

Path 1: Details

Occasionally I speak to a programmer who thinks he has
a unique situation. His claim begins with
the mountain of details he must handle, details which appear
to be contradictory, subtle, and overall perplexing. He
wonders if some new approach is required to handle them.

In answering this claim, we begin with the easy part,
showing that the situation is itself not unique. In short,
all worthwhile projects involve mountains of detail, so
there is nothing special there. When it comes to the
subtleties and the maze of exceptions and special cases,
these are common in mature businesses that have evolved
this complexity in response to business needs over the years.
So again there is nothing unique here, the programmer's
situation is again common.

At this point we have to ask how the programmer will deal
with this perplexing mountain of detail. If he knows
what he is doing, he will give the general answer that he
is going to break it down as much as possible into
independent smaller problems that can be solved on their
own. Since this is nothing more than how all programmers
solve complex problems, the entire "uniqueness" claim
has completely collapsed. His project is utterly common.

The much harder part of the conversation comes if the
programmer does not know how to break down
the problem. For instance, if the problem is all about
a fiendishly complex pricing system with lots of discounts
and pricing levels, and the programmer does not know that
he needs to begin with the database, and he further does not
want to hear that, well, there is not much I can do for
him. He will end up working a lot harder than he needs
to, and will probably remain convinced he is dealing with
something "unique".

But let's go a little deeper into that example of the
complicated pricing system. Why do I claim that he must
start with the tables, and that is he is wasting time
if he does not? Well, a complete answer is much more than
will fit here, and in fact I hit that theme over and over
in these essays, but it comes down to:

• He must have an accurate and precise description of
  the details that govern the pricing scheme. That is
  what tables are for.
  
• In working out the mechanics of the tables, particularly
  their primary and foreign keys, he will come to a
  his most complete understanding of the mechanisms
  involved.
  
• When the tables completely reflect the details he
  must work with, the code will just about write itself.
  
• Lastly, but probably most importantly, the customer
  will expect to control the pricing system by adjusting
  the parameters at all levels. Again, that is what tables
  are for. The user is in control of the pricing system
  if he can edit the tables (because of course he cannot
  edit the code).
  

Path 2: Combinations

Once upon a time we had simple desktop business applications,
games, and then this weird new thing, "the web". Now they
are all mixed together, as we play games on the internet that
are tied into huge databases. Modern applications often
combine technologies that used to be comfortably separate.
On any particular project,
some of the requirements look like they
can be met with an RDBMS, some require management and
delivery of media such as MP3 or video, and he is told as
well he must provide RSS feeds and import data coming in
XML format. Perhaps as well there will be stone tablets
and papyrus scrolls.

This programmer may believe he is in a unique situation
because of this combination of needs. Because no single
toolset out there can meet the entire project, perhaps this
is something never before seen? But this does
not hold up. Just like the argument about complexity,
he must break the problem up correctly, and when he has done
so he will have a perfectly ordinary project. Though I might
add it will also be a very interesting project and
probably a lot of fun.

In The End It Is All About Patterns

I have given two examples above taken from my own experience
where programmers have claimed to me that they faced some
unique situation. There are many other cases, and they always
make perfect sense to the person who thinks he has discovered
something new. The biggest flaw in the programmer's thinking
is failing to distinguish between particulars and
patterns.

My claim in this essay is that the patterns of all problems
are the same. Somebody has seen it before, somebody has done
it before, the answer is out there. The process of analysis
and programming is about slotting your particulars in the
patterns that have already been established.

In the broadest sense all programs process data, and
particular programs break down into broad patterns of data
access and manipulation. Sometimes you have a broad range
of users putting in data with very little massaging
(think twitter) and sometimes you have one group controlling
much of the data while others make use of it (think
Amazon), and sometimes your data is mostly relational
and table based (think any ecommerce or biz app) and
sometimes its mostly media (think youtube).

Once you have these broad patterns identified, you can then
proceed to make use of established practices within
each particular area. What is the best way to provide
sensitive data on the web and protect it from unauthorized
eyes? Somebody has done it before. What is the best way
to track large amounts of media? Somebody has done it
before. What is the best way to set up a complex pricing
system with lots of discounts and pricing levels? Somebody
has done it before. In all cases, your particulars may
be different, but the patterns will be the same.

Conclusion: Find the Patterns

Whenever I find myself looking at a situation that appears
to be new, I try to tell myself that it may be new to me,
but it is not likely to be new to the human race. If it
does not appear to follow a well-known pattern then I
proceed as if I have not yet recognized the pattern
and continue to analyze and break it apart until the pattern
emerges. So far it always has.