[kforge-dev] Taking stock of our current development strategy

Tue Oct 17 17:37:38 UTC 2006

John Bywater wrote:
[snip]
>> It might well turn out that adapting tg to our purposes would actually 
>> entail more work that it has taken to get our system working in the 
>> first place.
> 
> 
> 
> I agree with this last point: I expect it isn't a productive move. The 
> recent history of software development is that code reuse has failed, 
> that the limiting factor in software development is the formation of 
> concepts (it's astonishing how limiting this can be), and so reuse moved 
> up to the conceptual level, where the form of conceptual reuse, and the 
> basis for communication amongst developers, is the named pattern. I've 
> said this several times to you now, no?
> 
> http://appropriatesoftware.net/wiki?NamedPattern
> 
> Applying some of the patterns, like building a good object-relational 
> mapper takes lots of time, and the recommendation (in PoEAA) is to use a 
> third party component (like sqlobject). But most of the others are very 
> straightforward, and are perhaps best implemented freshly each time.
> 
> Best regards,
> 
> John.
> 
> PS This email has taken me several hours to write. It repeats many 
> things that we've spent similar amount of time going over. So what 
> happens? Do you think I'm mistaken, or do you not understand what I'm 
> saying, or suspect it somehow of a hidden agenda? Or do you forget? I'm 
> really not sure where the discussion is breaking down, and why it's 
> going round in this circle. But it's kinda hard work. I don't want to 
> die trying to explain these things. If we can't form a consensus, and 
> align our thinking, perhaps we should try operating different roles 
> where I act as developer (decide technical concerns, and develop code 
> adequate for your user stories) and you act as product owner (decide 
> business concerns, develop user stories and acceptance tests, and 
> determine whether code adequates to your user stories). I would prefer 
> to form an adequate concensus about software development practice, but 
> if we can't achieve that I feel it would better to focus each of us 
> exclusively on one role.

I'll try to come back and discuss the rest of your email later but for 
the time being I'll just focus on this part. While I'm sorry that 
writing this email has taken you so long I don't think your time has 
been wasted. You tend to write very detailed responses -- and that is 
appreciated. (If it is any comfort my email also took a while to compose 
  though probably not as long as yours. I think we should also remember 
that writing things down, though more time-consuming than direct f2f 
communication, is often more valuable).

But most importantly I feel that much of what you've said isn't just a 
repetition of what you have said before or 'obvious'. For example you've 
made clear that you don't think trying to use an existing 'framework' 
such turbogears more heavily is a good idea. You've also made clear that 
us having that you think we should definitely have our own domain model 
layer (as opposed to using sqlobject in a dual role as ORM and domain 
model)[^1].

There are also, of course, some things I'm not sure we do agree about 
totally. For example, that the history of recent software development 
has shown that code reuse has failed (after all we make extensive use of 
various libraries including the python standard library) but I don't 
think that is always a cause for exasperation -- it is possible for 
reasonable men (and women) to disagree without one of them being a fool 
or a charlatan! Often it is from constructive discussion of 
disagreements -- and their resolution -- that one learns most.

Thank you once again for taking the time to reply.

Regards,

Rufus

[^1] For example using sqlobject.inheritance we could do things such as:

from sqlobject import *
from sqlobject.inheritance import InheritableSQLObject

sqlhub.processConnection = connectionForURI('sqlite:/:memory:')

class State(SQLObject):
     name = StringCol()

class StatefulObject(InheritableSQLObject):
     state = ForeignKey('State')

class Project(StatefulObject):
     name = StringCol()
     services = MultipleJoin('Service')

class Service(StatefulObject):
     name = StringCol()