Message 03301 [Homepage] [Navigation]
Thread: oxenT03280 Message: 6/8 L2 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

[ox-en] Theory of satisfying projects and products



The theory of satisfying products and projects
==============================================

"I can't get no, I can't get no,
I can't get no satisfaction,
no satisfaction, no satisfaction, no satisfaction."
Rolling Stones, (I Can't Get No) Satisfaction

In today's world, there is a large number of free software applications.  The
free software development model has a potential of producing high quality
software with high quality documentation that would make the user able to fully
exploit in a straightforward manner it's all promised features.  Such a
software would be a very powerful tool for the user that would bring him a
great level of satisfaction.

However, sadly, the real situation is far from the theoretical potential.

Everyone wants to be satisfied by the things he is using. Who wouldn't. But
there are only few projects whose goal is to satisfiy it's user, and most other
projects just pretend this, according to the law of "90% of everything is
crap".  It's natural that the user wants to select those products that will
satisfy him, but if he goes only according to what these projects say, it will
not work, because all projects say they are the good ones. If he goes by what
his friends say, this will not work either, because what works properly in one
situation, may completely fail in another.

Therefore we propose a simple formal system how to discriminate projects, whose
true goal is to satisfy the user, from the rest. We will supply an easily
verifiable definition of a "satisfying project". Then the only thing that is
need to be known publicly about a project is, whether it is satisfying or not.
Such information is much easier for the user to check than large amount of
often conflicting users' testimonials. It's also easy to comply with our
definition for the projects whose true goal is to satisfy the user.

Definitions
-----------
product - a physical object, design of physical object, software or other
          information entity that is published
project - a systematic product development effort, usually performed by a team,

Satisfying product
------------------
A satisfying product has the following information (typically documents)
available for the user:
- requirements
- features
- usage instructions

It must be clear to everyone what exactly are the requirements, what exactly
are the features and what exactly are the usage instructions.

Note: this specially means that it's not possible to have more versions of any
of these documents published without being apparent which one is the official
one. It's also not allowed to have any of these documents missing. It also
means that it must be clear what is part of each of the document
and what is an external information that is not.

If the user meets conditions that he reasonably believes are meant by the
requirements published, and if for each step in the instructions he performs
actions that he reasonably believes are meant by that step in the instructions,
then, independently on other circumstances, he must always perceive the
behaviour of the product to satisfy what he reasonably believes is meant by the
published features.

Note: the word "believes" is used to guard the user against ambiguities in
requirements, features, or usage instructions. It can happen that the developer meant
something else than the user understands. It's the developer's responsibility
to ensure that such confusing situation doesn't happen.

Note: the word "reasonably" is to guard against user's unreasonable belief.
Reasonably means that according to common consensus, it's not generally obvious
that his belief is wrong. A reasonable belief is for example that if a program
says it supports HTML, that it will support CSS.  Unreasonable belief is that
if a program says it supports JPEG, that it will support PNG.

Dissatisfying product
---------------------
If a product is not satisfying, we call it dissatisfying product. We
colloquially shorthand this as "crap", too. 

Note: it specially means: for a product to be dissatisfying, a single
incident showing that the product is not satisfying is enough.

Bug
---
Bug is a particular thing that causes the product to be dissatisfying. This
term is only for practical purposes of developer communication and doesn't have
any actual importance in this theory

Bugreport
---------
Bugreport is a report that proves beyond reasonable doubt that the product
is dissatisfying.

Satisfying project
------------------
It's a project whose goal is to produce a satisfying product. If the project
leadership consistently demonstrates intention to produce satisfying product,
then we call this project to be satisfying.  

Dissatisfying prpoject
----------------------
It's a project that is not satisfying.

Note: this particularly means that if unwillingness to fix bugs is publicly
proven by anyone (typically someone whose bugreport was not taken into
account), the project is not satisfying.

Importance of satisfying projects
---------------------------------
Satisfying projects are very important for the users. First, the probability of
troubles is minimized for the user, because the goal of the project is a
satisfying product, whose very definition is based on delivering the promised
satisfaction to the user. Second, it's not possible that a bug
causes the user a trouble and then fixing the bug is arbitrarily delayed.
Therefore if the users gets a trouble, he always gets satisfaction by the fact
that by having this trouble he contributed to the effort towards a satisfying
product, and therefore towards eliminating other people's trouble.

Why were the requirements chosen
--------------------------------
Clarity which document is the official - if this is not met, the user can
pick up obsolete document and get resulting troubles and waste potentially
long time because of this confusion

Missing features - the user doesn't know what to expect from the product and
therefore is unable to plan into the future with this product

Missing requirements - the user carries out the instructions properly but it
still doesn't work because he didn't know that he had to fulfill some
requirement first.  Because of this, he wastes potentially a lot of time
resolving the issue.

Missing usage instructions - the user cannot use the device in a
straightforward way. He has to experiment, in a trial and error way, which
usually wastes a lot of time.

Clarity what belongs into the document - the user is not sure what belongs into
which document or not. He either has to bother the developer with support
request (costs significant time for both user and developer), or take a risk.
If he takes a risk, the result can be that it doesn't work, meaning potentially
a lot of time spent by the user resolvingn the issue

Meeting the requirements
------------------------

It's not difficult to have a goal of meeting these requirements. First the
developer writes these documents in a good faith. Then he publishes them and if
a users send bugreports then, he fills in the a missing information or changes
ambiguous wording.

It's not difficult to have a goal of keeping the technical design itself in a
good state either. It basically means slowing down, relaxing and keeping a
database of bugs with priorities. Taking one bug after other and resolving
them. Not being afraid of ripping parts of the design out and redoing them
again because of a bug caused by their bad initial design. And working on new
features only when the bug database is empty.

Implications for user's satisfaction
------------------------------------
Choosing one's project to be developed in a dissatisfying way is a decision
that means consciously allowing a frustration of the users that is potentially
unlimited. This should be realized by the users when choosing between a
dissatisfying and satisfying project. And this should be realized by developers
whose true (not only proclaimed) goal is to help other people with their
development. 

Conclusion
==========
We suggest here for projects who strive to truly satisfy their users, to comply
with the definition of satisfying project, because then users will be able to
easily indentify them as a project that has user's happiness as a true goal.
We believe this simple formal system has a potential of ending frustration of
users who would like to enjoy the high quality software available, but are
unable to, because they are cannot determine which one it is. We also believe
this can make developers whose just vaguely felt what their true goal is, to
realize their true goal in its full importance, and subsequently make the user
experience more pleasing.

CL<
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de



Thread: oxenT03280 Message: 6/8 L2 [In index]
Message 03301 [Homepage] [Navigation]