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

On 2007-01-14 10:49:40 -0600, JXStern <JXSternChangeX2R{}gte.net> said:

> OK, I looked up the book, it's 2002. I probably glanced at it at some
> point. "Agile" goes back to iterative methods first popularized and
> formalized in the late 1970s.

Iterative methods have been around since the late 50s. The term Agile
refers to a suite of practices that include iterative development.
Other practices in the Agile suite include Test Driven Develoment,
Refactoring, Simple Design, Pair Programming, Continuous Integration,
etc, etc.

> "Agile" has nothing to say about using
> one tool or another, or about RDBMS, pro or con.

The principles of Agile design have implications for how to treat the
different components of systems architecture, including DBs. The term
"pro or con" has no meaning here.

> RCM and lots of guys are playing with ideas and publishing books for
> fun and profit, RCM in particular ought to know better, ... but you
> KNOW how OOP seems to blind people to what is known and what is
> standard with RDBMS.

One day you may write a book. Then we can talk about fun and profit. ;-)

In any case, I'm not quite sure what "know better" is supposed to mean
here. Let me give you some advice though. Before you criticize an
author for not knowing better, you might want to read what he wrote.
Reading what someone else wrote about what the author wrote is less
than reliable.


--
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* * * * * * * * **|

> The problem being discussed is Payroll. If we are
> writing a payroll application we are being paid to create payroll
> behaviors.

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.

Fredrik Bertilsson
http://mybase.sf.net

Robert Martin wrote:
> On 2007-01-13 21:08:35 -0600, "topmind" <topmind{}technologist.com> said:
>
> > RCM definitely appears to not be a RDBMS fan and is happier the more he
> > wraps it away.
>
> It has nothing to do with fan-dom. I consider RDBMSs to be valuable
> and important components of many systems. Like any component, it
> should be isolated from the others. This is just good software
> practice. (see Information Hiding).

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 isolation is costing you complexity and code volume. I don't see
how you are claiming it better. You don't describe your scoring
mechanism that goes on in your head.

In case you swap DB vendors? That happens like once every 20 years, and
there are non-OO ways to do it also. Please focus on REAL problems, not
meteor insurance.

> --
> 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 |

-T-

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.

lilburne wrote:
> Robert Martin wrote:
>
> Hasn't Payroll been solved?

I think so. I think you buy them these days. I don't know of any
companies that would write their own payroll system anymore.

Daniel

On 14 Jan 2007 14:48:45 -0800, "topmind" <topmind{}technologist.com>
wrote:

>This may be related:
>
>http://www.c2.com/cgi/wiki?HelpersInsteadOfWrappers
>
>As far as "list boxes", do you mean the kind that you have to press
>something like Ctrl-Shift to select an item? Those are goofy
>keystrokes. The browser makers should have used checkboxes next to the
>descriptions (IOW, tables :-)

On a standard list box, you chose one with a click, you may have to
press Ctrl if you want to multi-select. Other list boxes toggle all
rows with clicks, letting you multi-select perhaps more simply.

Isn't it a sign of the apocalypse that I have to explain this?

J.

On Mon, 22 Jan 2007 14:31:46 +0000, lilburne
<lilburne{}godzilla.nospam.net> wrote:

>> 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'm not sure about bug-free, it sometimes runs slower than spec, and
all the errors seem to be on the low side.

J.

JXStern wrote:
> On 14 Jan 2007 14:48:45 -0800, "topmind" <topmind{}technologist.com>
> wrote:
>
> >This may be related:
> >
> >http://www.c2.com/cgi/wiki?HelpersInsteadOfWrappers
> >
> >As far as "list boxes", do you mean the kind that you have to press
> >something like Ctrl-Shift to select an item? Those are goofy
> >keystrokes. The browser makers should have used checkboxes next to the
> >descriptions (IOW, tables :-)
>
> On a standard list box, you chose one with a click, you may have to
> press Ctrl if you want to multi-select. Other list boxes toggle all
> rows with clicks, letting you multi-select perhaps more simply.
>
> Isn't it a sign of the apocalypse that I have to explain this?

We are talking in terms of web browser conventions, not GUI's in
general. Web browsers are limiting and many of us miss the simplicity
and flexibility of "fat client" GUI's. A web-browser's multi-select is
implemented stupidly. The user should not have to press Ctrl. They
should have used checkboxes or something similar.

>
> J.

-T-

On 21 Jan 2007 10:04:10 -0800, frebe73{} wrote:

>> The problem being discussed is Payroll. If we are
>> writing a payroll application we are being paid to create payroll
>> behaviors.
>
>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.

Well said.

But it's a difficult conceptual point. One gets into terms like
behaviorism and verificationism and RCM would find a lot of support
there, but note that those doctrines have fallen rather badly out of
favor since about 1970, and it's unclear that what replaced them in
psychology or philosophy works in computer science.

My point being that one is not at all forced to use behavior as a
criteria, there are other frameworks. And I see nothing in iterative
or the portmanteau as RCM would have it of Agile, that necessitates
behavior as a key.

J.

On Sun, 21 Jan 2007 09:37:46 -0600, Robert Martin
<unclebob{}objectmentor.com> wrote:

>On 2007-01-14 10:49:40 -0600, JXStern <JXSternChangeX2R{}gte.net> said:
>
>> OK, I looked up the book, it's 2002. I probably glanced at it at some
>> point. "Agile" goes back to iterative methods first popularized and
>> formalized in the late 1970s.
>
>Iterative methods have been around since the late 50s. The term Agile
>refers to a suite of practices that include iterative development.
>Other practices in the Agile suite include Test Driven Develoment,
>Refactoring, Simple Design, Pair Programming, Continuous Integration,
>etc, etc.

I mean the important principles go back - as far as you care to trace
them, then.

You mean, the term Agile was coined in the last few years to wrap up
these old principles and some newer ones.


>> "Agile" has nothing to say about using
>> one tool or another, or about RDBMS, pro or con.
>
>The principles of Agile design have implications for how to treat the
>different components of systems architecture, including DBs. The term
>"pro or con" has no meaning here.

I deny any such claim even makes sense, other than making Agile a
wrapper you can throw anything at all into.


>> RCM and lots of guys are playing with ideas and publishing books for
>> fun and profit, RCM in particular ought to know better, ... but you
>> KNOW how OOP seems to blind people to what is known and what is
>> standard with RDBMS.
>
>One day you may write a book. Then we can talk about fun and profit. ;-)

I know already, have long been struggling with a book in a somewhat
different area, and have researched the meager monetary compensation
involved, but there must be some motivating factor that gets
satisfied!

>In any case, I'm not quite sure what "know better" is supposed to mean
>here. Let me give you some advice though. Before you criticize an
>author for not knowing better, you might want to read what he wrote.
>Reading what someone else wrote about what the author wrote is less
>than reliable.

Fair enough, but I followed a year or two of your evolution thru the
XP world, and the paragraph seemed consistent with that history and at
least some of the claims of topmind.

J.