Today we see much emphasis on the idea that
a developer can simply learn the syntax of a given language. In fact, today the
tools to create computer code are very good. In fact, tools are so good that the
hard part is not writing code...but what to write! Once we have a good design,
the coding part will practically fall into place.

Thus, the real skill today is not someone
who knows how to print the word hello in 32 different computer languages. The
real skill is then finding out what you need when you hire my services. While
you probably know what you need, translating this into an information system is
what separates the men from the boys.

The key here is your requirements. Every
software company in the world says they listen to the customer and then write
great software. The problem here is that listing to the customer is not enough.
Good software is software that accomplishes tasks. Hence, software must be task
orientated.

Good software is task orientated.

To make software task originated we build
an imaginary user, or "person". This approach sounds rather simple...it is not.
This approach also means that we DO NOT simply write down the requirements. We
can have some requirements to look up a product price in an inventory system.
That is a requirement. However, there is a huge difference between sales people using that information for price quotes as compared to the accounting
department.

In other words both the Accounting
department and the sales department need to look up pricing information (that is
a requirement). What is different between the inventory department and the sales
department? Why of course it is the task they are trying to accomplish. Hence,
both Accounting and sales need the same information but for different tasks. In
fact there will probably be information that accounting needs and that the sales
people are forbidden to see.

Simply shifting the software design from an
requirement based system to one built around a imaginary user with a specific
set of tasks is the key here. If you think about this you will begin to see
*one* reason why we really do create better software. There are a good many
other reasons why our group can write great software, but I would rather other
consulting groups figure this out instead of reading it here!

However, I do let my guard down and spill a few good secrets in the following
article: