Redeveloping the system - was Thoughts on payment handling in 1.4.x

[David Tangye <..hidden..>]

Oh dear: this is quite long. Sorry, but I had a cup of tea and a think,
and decided it is appropriate as is.

On Fri, 2007-04-27 at 10:22 -0700, Joshua D. Drake wrote:
> ... or I beating 
> someone into doing it right through team collaboration and positive 
> reinforcement (2x4, hose, or weed pulling with tweezers).

I come from two small islands that must hold the timber the other way
around: they can it "4 by 2" there. :-) This is a case of a alternative
terminology that might be considered trivial because anyone might
reasonably understand it when its expressed either way. However in
system design what seems like trivial differences in word
usage/definition is one of the main reasons for misunderstanding and
bugs further down the line. There have been many cases of usage of words
and phrases in many discussions here in the past that I have thought
were at best obscure, at least to me. I have very rarely raised issue
because I did not want to appear to be too disruptive.

Discussion in the past day has been extremely good. All you need now is
a development infrastructure/method(ology)/process to capture and use
the results ie to agree and define (record formally as an agreed basis
for the system) these sorts of items: eg -

> On Fri, 2007-04-27 at 08:18 -0700, Chris Travers wrote:
> 
> > > Invoices are accounting transactions.  Sales orders and quotes are not.
 [)Proposed?) Business rule.] 

> > 
> > In particular, when you convert an order to an invoice it becomes a
> > financial transaction.
 [)Proposed?) Business rule.] 

> > Having said this, they are still phases of the document
[Terminology: one proposed definition of the meaning of the term
'document', ie 'an instance of a business transaction as it flows
through an instance of one "business workflow"'?]
[Terminology: one proposed definition of the meaning of the term
'phases']
This example uses words in what I consider to be unusual, so if accepted
as a valid usage for this project, it is important that the terms by
formally defined, so others understand what you are on about.

Its really important to define terminology concisely and unambiguously,
plus as much as possible to have as few different meaning for a term as
possible. One key way to do this is to be very vary about picking up odd
buzzwords and "mots de jour" or terms from foreign domains. Its a common
problem in IT for people to think its cool to impress others with
obscure terminology, and this is a big problem in system design. Stick
to common meaning for terms as much as possible.

I could give dozens more examples of this from the recent past here, but
I am sure everyone gets the idea. Oh a couple of important ones though:
my understanding/experience of relational data and database modelling
results in these terms being understood as follows:
In a physical schema/physical database -
 1. Fields do not exist. They are called columns. Exception maybe:
Microsoft Access database programming, (heaven help you). Fields exist
in views of columns, eg on screens and in reports (views of data).
Conversely on screens and in reports columns do not exist: they are
fields.
 2. Records do not exist. They are rows. Similarly on screens and in
reports rows do not exist: they are records.
Why is this important? Because if you mix the terms up, you start having
a discussion about a logical/business model/users' requirements and end
up sounding like you are making decisions about the way the physical
database is going to be defined, all in one discussion, ie you get
discussion about the nature of the problem(requirements) expressed as
the answer(system design). What you should be doing is addressing and
agreeing on the problem/requirement first before you start working on
the answer/design. Too often in software a system is built without
properly understanding what the requirement is, eg agreeing on the
business rules. This is why bugs occur (notwithstanding design/coding
bugs: they are extras).

In summary: terminology is vitally important. Ignore this at your peril.

A final thought:
If no development method (process plus artifacts) is agreed, how is
everybody going to work together?
	- System Scope, List of Terms, Business Rules, and the models etc are
just examples of key artifacts.
	- A better understanding of process is found in the principles of
Quality, specifically in attempting to raise the project up to at least
CMM level 3. (http://en.wikipedia.org/wiki/Capability_Maturity_Model).
Lack of a clear understanding of what Quality is (not the general
meaning, but the formal meaning as applied to projects (hence the
capitals)) and why it is important, is probably the single biggest
problem that I see with open-source projects.