Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices" - Theory and Concepts

Robert Martin wrote:
> On 2007-01-13 17:00:24 -0600, JXStern <JXSternChangeX2R{}gte.net> said:
>
> > Page 351, second paragraph: "Instead of starting with the data of the
> > system, let's start by considering the behavior of the system. After
> > all, it is the system's behavior that we are being paid to create."
> >
> > Says who?
>
> Says me! ;-) The problem being discussed is Payroll. If we are
> writing a payroll application we are being paid to create payroll
> behaviors.
>
> I am quite happy to agree that there are applications that are more
> about data storage and provisioning, than any actual processing. But
> that was not the case under study.

The problem is that data and behavior are mostly interchangable. For
example, to the interpreter/compiler, a program *is* data. Actually,
table-oriented techniques tend to build a kind of domain-specific
interpreter, so the ****ogy does have some legs in app design.

In light of this, it is hard to say what is *inharently* data-centric
and what is behavior-centric. I find it a matter of human convenience.
Some parts of the apps are easier to deal with as code-centric
expressions and others as lists/tables of attributes. Code makes for
crappy attribute managers and noun modeling, IMO, such that I tend to
shift those to the table side of things. But nitty-gritty
non-repetitious IF statements and Boolean formulas are easier for me to
deal with as programming code. Such could be tablized if one wanted,
but from my brain's perspective it is best kept those in code. Your
brain may be different and you like more in code. Such people tend to
be linguistic thinkers as opposed to visual thinkers in my observation.
I am generally a visual thinker and thus shift more to tables than a
liguistical thinker would. OO tends to favor linquistic thinkers and
scares off visual people. Software engineering is largely about
psychology, for good or bad, not math nor science.

> --
> Robert C. Martin (Uncle Bob) | email: unclebob{}objectmentor.com

-T-

topmind wrote:
> lilburne wrote:
>> Robert Martin wrote:
>>
>>> On 2007-01-13 17:00:24 -0600, JXStern <JXSternChangeX2R{}gte.net> said:
>>>
>>>> Page 351, second paragraph: "Instead of starting with the data of the
>>>> system, let's start by considering the behavior of the system. After
>>>> all, it is the system's behavior that we are being paid to create."
>>>>
>>>> Says who?
>>>
>>> Says me! ;-) The problem being discussed is Payroll. If we are
>>> writing a payroll application we are being paid to create payroll
>>> behaviors.
>>>
>>
>> Hasn't Payroll been solved? I thought getting paid was one of the first
>> things that Software Engineers and Consultants, irrespective of
>> methodology, had got bug free.
>
> I think the rules and laws keep changing and are often State-specific.
> Anyhow, such is used as a training example regardless of whether there
> are off-the-shelf versions of it.
>

Hmmm! But shouldn't a Agile practitioner advocate buying in?

lilburne wrote:
> topmind wrote:
> > lilburne wrote:
> >> Robert Martin wrote:
> >>
> >>> On 2007-01-13 17:00:24 -0600, JXStern <JXSternChangeX2R{}gte.net> said:
> >>>
> >>>> Page 351, second paragraph: "Instead of starting with the data of the
> >>>> system, let's start by considering the behavior of the system. After
> >>>> all, it is the system's behavior that we are being paid to create."
> >>>>
> >>>> Says who?
> >>>
> >>> Says me! ;-) The problem being discussed is Payroll. If we are
> >>> writing a payroll application we are being paid to create payroll
> >>> behaviors.
> >>>
> >>
> >> Hasn't Payroll been solved? I thought getting paid was one of the first
> >> things that Software Engineers and Consultants, irrespective of
> >> methodology, had got bug free.
> >
> > I think the rules and laws keep changing and are often State-specific.
> > Anyhow, such is used as a training example regardless of whether there
> > are off-the-shelf versions of it.
> >
>
> Hmmm! But shouldn't a Agile practitioner advocate buying in?

An interesting question. If buying off-the-shelf is the simplest
solution, perhaps they would. However, how do you know if the product
fits if you don't *yet* have the requirements? Requirements gathering
up-front generally is not considered agile. I would suggest asking an
Agile movement proponent.

-T-

On 2007-01-21 13:59:25 -0600, "topmind" <topmind{}technologist.com> said:

> Isolation creates duplication of concepts and can make it more
> difficult to use the existing power and abilities of RDBMS. Most of the
> code in your book is WASTED on translating back and forth between two
> medium-to-high-level concepts: OO and relational. It is like spending
> effort translating between Japanese and Spanish and back rather than
> get anything real done.

The payroll system in the book is partitioned into code that knows
about the DB schema, and code that does not. The dividing line is a
set of interfaces that translate high level concepts like "GetEmployee"
into appropriate SQL. To the left of the interfaces the code deals
with Employees. To the right the code deals with SQL, tables, rows,
and columns.

In any application, OO or not, this translation must take place. All
we have done with the code in the book is to assign a place for that
translation.

There is no duplication. There is no waste. There is simply a
separation of concerns. Those concerns would exist regardless of
whether they were separated or not.

--
Robert C. Martin (Uncle Bob)  | email: unclebob{}objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |

On 2007-01-21 12:04:10 -0600, frebe73{} said:

> Payroll behavior is producing a payment file to the bank, using data
> supplied by employees and adminstrators. The data is the important
> thing. Behavior is only the method of transforming data. Like many
> other business applications, it is all about providing information or
> data to different actors. The behavior of the application is low-level
> stuff that is not important on higher abstractation levels.

I suggest you test your hypothesis by creating a personnel database for
IBM and then writing the paychecks by hand. You will be allowed to
type SQL commands at the terminal to access the database. You will
also have the tax code for all the states and the federal government,
as well as all the insurance codes, union contracts, etc. You should
be able to write the paychecks easily with all that information since
there is not much behavior in the system.

--
Robert C. Martin (Uncle Bob)  | email: unclebob{}objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |

> > Payroll behavior is producing a payment file to the bank, using data
> > supplied by employees and adminstrators. The data is the important
> > thing. Behavior is only the method of transforming data. Like many
> > other business applications, it is all about providing information or
> > data to different actors. The behavior of the application is low-level
> > stuff that is not important on higher abstractation levels.
>
> I suggest you test your hypothesis by creating a personnel database for
> IBM and then writing the paychecks by hand. You will be allowed to
> type SQL commands at the terminal to access the database. You will
> also have the tax code for all the states and the federal government,
> as well as all the insurance codes, union contracts, etc. You should
> be able to write the paychecks easily with all that information since
> there is not much behavior in the system.

The paychecks are a data structure. How they are produced and how they
are communicated to the receiver is just a low-level issue. As you
describe above, a payroll system may be implemented without use of
computers.

On a very hight abstractation level we can describe the requirements of
the system by defining the data model for the input data and the output
data, and data derivation rules. If we choose to use computer software
to implement it, is an implementation issue.

Fredrik Bertilsson
http://mybase.sf.net

Robert Martin wrote:
> On 2007-01-21 13:59:25 -0600, "topmind" <topmind{}technologist.com> said:
>
> > Isolation creates duplication of concepts and can make it more
> > difficult to use the existing power and abilities of RDBMS. Most of the
> > code in your book is WASTED on translating back and forth between two
> > medium-to-high-level concepts: OO and relational. It is like spending
> > effort translating between Japanese and Spanish and back rather than
> > get anything real done.
>
> The payroll system in the book is partitioned into code that knows
> about the DB schema, and code that does not. The dividing line is a
> set of interfaces that translate high level concepts like "GetEmployee"
> into appropriate SQL. To the left of the interfaces the code deals
> with Employees. To the right the code deals with SQL, tables, rows,
> and columns.
>
> In any application, OO or not, this translation must take place. All
> we have done with the code in the book is to assign a place for that
> translation.

First off, this could be done without OOP. We could have functions that
wrap the SQL. Thus, it is not really an OO-specific thing.

>
> There is no duplication. There is no waste. There is simply a
> separation of concerns. Those concerns would exist regardless of
> whether they were separated or not.

It is additional code and likely additional work. The more beurocracy
you put between the RDBMS and the app code, the more places you will
often have to change. For example, if a new attribute or table is
needed for a given calculation, then likely there will be two 2 units
that need changing: the SQL along with the SQL wrapper's interface, and
the app code that uses it. However, if the SQL was together, then only
one unit needs changing. Thus, wrapping is more effort: one has to make
2 hops instead of one. These kinds of changes can and do happen quite
often. Swapping DB vendors is fairly rare. Thus, you are paying a
nearly GUARENTEED indirection tax of about 25% on on-going code
maintanence in order to prevent a roughly once-per-10-year event, and
such effort is only about a 10-day effort on medium projects (if you
combine the testing with general new-version testing). Thus, over a
10-year period, the heavy wrapping may cost at least 3 hours a week,
adding up to more than 1,000 hours in 10 years. This to prevent an
80-hour DB swap effort?[1] One would have to swap vendors roughly every
18 months to break even!

The economic calculatioins are just plain against this in most custom
application shops. It just does not add up. My version of your app
would be roughly 1/2 to 1/4 the same amount of code. Shorter code in
general is usually easier to learn, modify, test, understand, read, and
debug. Your code is full of "red tape". It is mostly martialing stuff
back and forth between instantiations and interfaces istead of doing
domain-related calculations. It smells of a programmer jobs program
better than any spend-happy liberal could ever pull off. (I shouldn't
mind from my perspective, but one does get bored dealing with bloated
red-tape code. I like to spend my time on real work, not red tape.)

I also would like to see your comments on taxonomy issues. (The
SQL-wrapping issue has been beaten to death on comp.object anyhow.)
Excerpt from my critique:

(begin quote)

Page 352 and 353: Figure 26-1 and Figure 26-2

Martin commits a common OO mistake of making a hierarchy of "employee
types", or at least "payment types" (hourly, commissioned, and
salaried). "Types" are often a poor modeling decision in business
applications because they cannot handle orthogonal traits very well.
Martin gives tons of lip service about making applications easier to
change without lots of code overhaul. However, hierarchical OO classes
are expensive to de-hierarchy.

In fact, I've witnessed first-hand an actual scenario that busts
Martin's hierarchy. I've worked at a place where it was decided that
any employee can receive sales bonus. If they sold the company's
products to their neighbors or friends, they qualified for commissions.
We live in a heavily sells-oriented capitalist society, so preparing
for such a situation should be a no-brainer.

If you look at my schema below, you will notice that there is nothing
that forces a mutually-exclusive choice of "payment types". The
equivalent of Martin's 3 classes is driven mostly by the "empRates"
table. If they are an hourly employee, then they have a corresponding
hourly rate row in the table. If they are salaried, then they have a
monthly rate (per specifications on page 350). If they get a sales
commission(s), then the commission rate(s) are also there. We are
making the design assumption that they are not necessarily mutually
exclusive.

You may ask what keeps somebody from being both an hourly and a
salaried (monthly) employee. If such combinations are not allowed, then
it can be prevented via data entry validation and/or database triggers.
The point is that we are not hard-wiring the allowed or disallowed
combinations into our basic design to give us feature flexibility.
Validating such combinations is treated also as mere data configuration
issue, and not a large-scale code feature.

(End Quote -- yuk, I need to rework some of my writing on that
website.)

[1] If one uses features that are very vendor-specifc, then DB vendor
swapping can take much longer. However, finding new-vendor ways to do
things the prior way is still going to be needed regardless of wether
you wrap or not. It is not effort wrappers save. Swapping in general
won't be free even under wrapping, so I may have understated my point
by not "charging" the wrapped version for swap hours.

>
> --
> Robert C. Martin (Uncle Bob) | email: unclebob{}objectmentor.com

-t-

Robert Martin wrote:
> On 2007-01-21 12:04:10 -0600, frebe73{} said:
>
> > Payroll behavior is producing a payment file to the bank, using data
> > supplied by employees and adminstrators. The data is the important
> > thing. Behavior is only the method of transforming data. Like many
> > other business applications, it is all about providing information or
> > data to different actors. The behavior of the application is low-level
> > stuff that is not important on higher abstractation levels.
>
> I suggest you test your hypothesis by creating a personnel database for
> IBM and then writing the paychecks by hand. You will be allowed to
> type SQL commands at the terminal to access the database. You will
> also have the tax code for all the states and the federal government,
> as well as all the insurance codes, union contracts, etc. You should
> be able to write the paychecks easily with all that information since
> there is not much behavior in the system.

This is a straw-man argument. SQL-only is not what is being compared. I
*have* seen people do an awful lot of processing with just SQL.
However, I don't recommend such a heavy use, though. SQL in its current
form is not good enough for that (although a better relational language
could be). But the amount one can use SQL (or a query language) is like
a sliding scale. Nobody is recommending 100% SQL. Some UNDER-use the
query language and some OVER-use the query language. OO proponents
typically under-use it, preferring to use OOP programming instead.

As far as where to use queries and where to use imperative code (app
code), I already gave some rules-of-thumb in a nearby reply.

>
> --
> Robert C. Martin (Uncle Bob) | email: unclebob{}objectmentor.com

-T-

> > Isolation creates duplication of concepts and can make it more
> > difficult to use the existing power and abilities of RDBMS. Most of the
> > code in your book is WASTED on translating back and forth between two
> > medium-to-high-level concepts: OO and relational. It is like spending
> > effort translating between Japanese and Spanish and back rather than
> > get anything real done.
>
> The payroll system in the book is partitioned into code that knows
> about the DB schema, and code that does not. The dividing line is a
> set of interfaces that translate high level concepts like "GetEmployee"
> into appropriate SQL. To the left of the interfaces the code deals
> with Employees. To the right the code deals with SQL, tables, rows,
> and columns.

How many getEmployeeBySomeCriteria methods do you think you will end up
with in a normal payroll application? Why do you want to hide predicate
logic and set operations behind a procedural interface?

> In any application, OO or not, this translation must take place.

Absolutely not.

> There is no duplication. There is no waste.

If you have a table employee and a class employee, you obviously have
duplication. If you have five variants of getEmployeeBySomeCriteria,
you obviously have duplication.

Fredrik Bertilsson
http://mybase.sf.net