Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: JXStern on 22 Jan 2007 11:18 On Mon, 22 Jan 2007 14:31:46 +0000, lilburne <lilburne(a)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.
From: topmind on 22 Jan 2007 11:23 JXStern wrote: > On 14 Jan 2007 14:48:45 -0800, "topmind" <topmind(a)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-
From: JXStern on 22 Jan 2007 11:25 On 21 Jan 2007 10:04:10 -0800, frebe73(a)gmail.com 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.
From: JXStern on 22 Jan 2007 11:29 On Sun, 21 Jan 2007 09:37:46 -0600, Robert Martin <unclebob(a)objectmentor.com> wrote: >On 2007-01-14 10:49:40 -0600, JXStern <JXSternChangeX2R(a)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.
From: topmind on 22 Jan 2007 11:31
lilburne wrote: > Robert Martin wrote: > > > On 2007-01-13 17:00:24 -0600, JXStern <JXSternChangeX2R(a)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. There are a lot of real-world details left out of Robert's example anyhow to keep it digestable to the reader. He does put such a disclaimer in his book. One of the problems with biz examples, or any examples for that matter, is that if you pick something familiar to the reader, it is probably already "packaged", and if you pick something too esoteric to be packaged, nobody will relate and you spend half the book explaining the domain. -T- |