> On Wed, 19 Feb 2003 13:39:55 -0000, "Paul Campbell"
>>> On Wed, 19 Feb 2003 12:08:42 -0000, "Paul Campbell"
>>> It would be interesting to understand what happened and why. I
>>> haven't encountered cases where well-factored code was that
>>> difficult to change.
>>Because we use a java serialisation based persistence mechanism, and
>>thus there must be no outward referential links from the classes being
>>persisted, thus listener style callbacks to monitor model changes that
>>would otherwise be quite reasonable end up dragging in the whole
>>world. Granted this problem is specific to the mechanism but it was
>>know at the time that we were going to do it this way.
Ah yes. Great example. Quite likely the simplest approach *now*.
Definitely a serious limitation *later*.
Quote:> I'm wondering why no tests or stories caused this problem to go on for
> so long without being discovered, given that it was known as an issue.
I think this architectural limitation is easy to know beforehand. But
until you have a specific performance requirement, java serialization
might be good enough. Suddenly you hit the wall. The "fix" is a soft
statement and not really testable. How would you write: "Don't serialize
the whole world because it won't scale" as a test?
>>> >If you are going to preach some principal called STTW then please
>>> >please be at pains to qualify it as you have here with your
>>> >consideration of the big picture. Because in its raw literal form
>>> >it is down right dangerious IME.
>>> It's a sentence, Paul. It's a reminder of a complex practice.
>>> Nothing we do can be captured effectively in one sentence.
>>But I am saying its worse than that - its a dangerous over
>>simplification, and I have both direct and indirect experience of
>>people taking it literally - when I see comments from people doing
>>test first design who say stuff like "... then I code until I get a
>>green line (in junit)" then its a good bet that there isnt much
>>holistic design consideration going on here.
Its a bad bet when the person doing this is a very good developer. That
person may have a very good idea of the "layout of the long road ahead",
but also appreciates the value of taking small steps and unambiguous
indications that one is still on the tarmac.
>>I guess unltimately Im not criticising what you are actualy doing so
>>much as how other people are interpreting the guidlines and I guess
>>that isnt your fault :-).
> I rather like to think that. If people read what we write, I think
> they'll get it. If they take 8 words out of context, they might not.
>>Why not use "the simplest design that takes account of the likely
>>future design and architecture evolution" if thats what you really
> That isn't what we mean. This must be more difficult to explain than I
> ever knew.
Yes it is. Because the benefits are subtle and profound, i.e., hard to
believe, and the fear (reality) of the local optimum is rather too well
experienced in our industry.
> Do the simplest thing that could possibly work. If you know it
> couldn't work, do not do it. To be simple, code must, in priority
> 1. Run all the tests;
> 2. Contain no duplication;
> 3. Express all the ideas the programmers want to express;
> 4. Minimize the number of classes and methods.
> Did the serialization issue you mentioned above meet these criteria?
Quite easy to imagine it did. Until one day a new test concerning
performance ran into a serious rewrite in order to pass.
Quote:> If so, or if not, how did that impact the difficulty of doing the
Paul, how well was the serialization encapsulated? If you'd TDD'd it,
then it would be very well encapsulated. Perhaps you could have then
written a new serialization component that only serialized a portion of
the world and replaced the "ends" with references. (If your objects
serialized themselves, how hard would it have been to have this delegated
instead as a prior refactoring step?)