Colin Law wrote: > On 8 October 2010 18:21, Marnen Laibow-Koser <[email protected]> > wrote: >>>> else. >> is, everything that is actually of value to the user. �The user never >> sees or cares about the internal workings of the application (except as >> specified in his requirements); they are not of value to him. �Only the >> functionality is of value to the user. > > I don't entirely agree here. Firstly the scenarios only describe the > functionality of the current phase of development.
Which, at any given time, is all we care about. > The user has an > interest in the internal workings of the application in so far as he > expects there to be further phases and therefore expects the design to > facilitate later phases as far as possible, even though he may have > little idea what those phases may be. No. The user wants the application to work. Other things being equal, he doesn't care how. The internal workings are irrelevant to the user; the concern of further phases is one of project management, not internals. It's to the *developer's* advantage to structure the application so that adding more value for the user will be as easy as possible -- hence good development practices -- but the user sees and cares about none of this. Don't kid yourself that the user has any reason to care about what goes on under the hood, as long as the application works as specified. > I know we don't want to do > premature optimisation however, I will come back to this below. > >> >> Now, since only the functionality is of value to the user, from that >> perspective it is clear that the only purpose of the application code is >> to provide an implementation that delivers that functionality. �If we do >> anything else, we are not providing any particular value to the user. > > Again I will quibble, slightly tongue in cheek, though not entirely. > The purpose of the code is to provide the implementation, as you > state, however the process of developing the application has other > purposes. Notably to provide us with a living wage and job > satisfaction. That adds value for the *developer*, not for the *user*. If all we care about is running up the billable hours, there are lots of ways to do that -- and not all of them involve adding value for the user -- and soon the user will realize this and find a developer who can actually add value for him. Your user's goals are not your goals. > I believe that to some extent software development can > be an art as well as an engineering operation. Completely agreed. (My background is in musical composition, so I *would* say that. :) ) > Consider initially > just small sections of code. Often there are numerous ways of coding > a piece of functionality, with no difference in the result of running > the code. Usually one of these 'feels' right. Nothing in the > scenarios suggests one or the other but we code it the 'right' way > because we get satisfaction sitting back and savoring the design. Right. If we are good developers, we probably have a sense of the best way to write something at the moment. Other things being equal, there's nothing wrong with that. > OK, > I am getting a bit carried away here but I am sure you know what I > mean. In addition we may code it a particular way because we believe > it will be easier to maintain To a point. But not much. Do The Simplest Thing That Could Possibly Work is an important principle. Don't bend over backwards to generalize; let the generalizations emerge. > and is less likely to have unnoticed > bugs. That's what tests are for. > I think these ideas also apply to the larger scale design of > the app, including the models and relationships. The overall design > can be aesthetically pleasing, or even a thing of beauty (I know, OTT > again, sorry). The scenarios do not address that aspect of the > design, only the designer can do that. And the user will not care one iota about all that beauty. It, in and of itself, adds no value for him at all. The only thing adding value for the user here is that the beautiful code *makes the app easier to maintain* -- that is, to extend functionality -- that is, to do things that *do* add value for the user. To reiterate: there is no user value at all in elegant code, except insofar as the elegance makes future development easier. There is developer value, but no user value. > >> >> Since the models are part of their app code, their only purpose is to >> implement the functionality specified by the user (which is what is >> captured in the scenarios). �So yes, on balance, I think I would agree >> with the contention you attribute to me. >> >> Apparently you do not. �What else do you think the models -- or any of >> the rest of the app code -- is there for? �I'm hard put to come up with >> anything else... > > The purpose of the models is obviously to satisfy the scenarios, but > the purpose of the design is also to facilitate further phases, No! The purpose of the design is to make the project *as we know it now* work. Further phases can take care of themselves when they come. > even > though we do not know what they will be (see later again) and to give > us satisfaction in the design as discussed above. Since we don't know what the further phases will be, we can't design for them. Period. You're deluding yourself into premature generalization, and apparently somehow think that your clients care what the source code looks like. > >> and refactor later as necessary. �Remember YAGNI. > I am not suggesting adding extra functionality that may or may not be > required, but ensuring that the initial design provides a base that is > most likely to allow extra functionality to be added without major > re-structuring of the design. That would require too much guesswork. There is no point in doing that -- you'll probably guess wrong. Implement today's requirements today, and refactor for tomorrow's requirements when you know what they are. > >>> identify the underlying objects in that real world without worrying >>> too much about the _details_ of the scenarios. >> >> Precisely. �That's what I meant by business domain objects in my earlier >> post. �If we want the user to be able to purchase products, we know we >> have "user" and "product" as business domain objects. �We don't know >> (though we might strongly suspect) that we will have User and Product >> classes in our program. > > I think now our ideas are starting to diverge. My initial assumption > would be that there _will_ be user and product classes _because_ they > are domain objects (unless the scenarios show that they do not > actually exist in the app). That would be my initial assumption as well when I start to implement, but that's because I follow such a programming style in general. Apparently not everybody does. [...] >> This is an implementation detail, and as such >> it is irrelevant right up till the moment we start implementing. > > I am not sure what you mean here. I mean that the nature our object model should be of no concern to us at all till the moment we start to write actual code. > >> >>> �I believe this should provide a better >>> base on which to build the app. >> >> But it won't. �It just forces you into prematurely making implementation >> decisions on insufficient information, and perhaps slightly ossifies the >> result of those decisions. >> >> Why do you think there is any advantage to doing this. > > See below. > >> >>> �Scenarios will be modified and added >>> to dramatically over time but the underlying objects in the >>> requirements are less likely to change (I don't mean that their >>> behaviour will not change, but their existence). >> >> That's true with regard to the underlying domain objects. �It is not >> necessarily true with regard to the underlying program objects. > > But that is the point, if the domain objects and program objects map > onto each other closely, Which there is no guarantee that they will. (There was an interesting post from Jim Coplien a while back where he said that very few bank systems actually have any sort of Account object internally, even though there's a business concept of an account.) > then since the domain objects tend not to > change dramatically the program objects will also not change > dramatically (though their behaviour will be added to and modified of > course. Behavior is most of what program objects are about. That's not really true of domain objects. I guess -- and I hadn't realized this before -- that in that sense, the two are somewhat incommensurable. Perhaps this is why some OO experts don't like modeling domain objects with program objects. I wonder. > >> >>> �If the >>> identification of the objects is correct (or optimum or whatever) at >>> the start then this will minimise the effort in tracking the changing >>> requirements. >> >> But that's not even true. �It assumes a degree of clairvoyance regarding >> the future directions the project will take that we do not generally >> possess. > > Again, by mapping domain objects closely to program objects then > clairvoyance is not required as domain objects tend to be stable. Really? What happens when your client's business model changes? Or when you discover domain objects your client didn't know existed? (Not so far-fetched; see http://c2.com/cgi/wiki?WhatIsAnAdvancer for a real-world example.) > >> >>> >>> I am still not sure that I am expressing myself very well. >> >> I think you are...I hope I am too... > > Certainly. > > Colin > > PS My brain hurts. Mine too. :) Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
