On Mon, Mar 2, 2009 at 7:31 AM, James Byrne wrote:
> Whether or not a client is a
> stand-alone design element or is dependent upon a superior element of
> abstraction is really quite beside the point insofar as the presentation
> of the system to the user is concerned.
I like to focus on that k
Andrew Premdas wrote:
> James,
>
> I'd question whether you need to give a monkey's about 'entity'. Whilst
> it maybe an essential concept in the overall legal framework that doesn't
> mean it has to be in YOUR world. If your software is about recording services
> provided to some client and re
Andrew Premdas wrote:
> James,
>
> Thanks for taking the time and providing more fodder to chew on.
>
> There are a couple of things I'd like to point out
I will take a little time to digest this and perhaps to comment but, in
the meantime, thank you for your thoughts on this matter. There is
James,
Thanks for taking the time and providing more fodder to chew on.
There are a couple of things I'd like to point out
Modelling the world is a futile and pointless task. Its to big and
complicated. Model YOUR world instead, choose the external boundaries
carefully and make your world as sim
Stephen Eley wrote:
> It is an interesting idea. I knew Redmine had wiki and forum
> features. I think I've probably been somewhat unfair to it because I
> got the sense it was trying to be a better Trac, and Trac leaves a bad
> taste in my mouth. I know that's not rational, and I should give i
On Tue, Feb 24, 2009 at 10:11 AM, James Byrne wrote:
>
> I am sorry that I did not make myself clearer. Redmine is far more than
> a project management tool. It is in fact a rather sophisticated, if
> limited, content management tool that supports PostgreSQL as its back
> end. I was suggesting
Andrew Premdas wrote:
> James,
...
> Client is not a good name for an emphemeral role. If you need adverbs
> and adjectives to clarify your verbs and nouns, then your verbs and nouns
> aren't good enough. I'm not convinced that Entity is a particularly good
> name either the fact that you need so
Stephen Eley wrote:
>
> Thanks, James. But at the moment I have no need for that level of
> overhead. Gantt charts are an anti-feature for me. I'm effective
> enough with my index cards and thumbtacks. >8->
>
I am sorry that I did not make myself clearer. Redmine is far more than
a projec
On Mon, Feb 23, 2009 at 7:04 PM, James Byrne wrote:
>>
>> I'm the technology director for a non-profit academic society. My
>> organization has 15 employees.
>
> I occurs to me that you might find a look at Redmine
> (http://www.redmine.org) worthwhile. If not to use then at least for
> implemen
Stephen,
It appears that James situation is similar to yours which is very different
to what I assumed. I've written a response (rant) about addressing his
problems in that context. Personally I still think that you have to start
with fundamental customer produced features. As you and James are on
James,
If this is the case then to do BDD well you have to simulate the dialogue
between customer and developer. At the moment you are so thinking like a
developer so you are starting with detailed technical features rather than
general customer features. Also you're using such complicated languag
Stephen Eley wrote:
>
> I'm the technology director for a non-profit academic society. My
> organization has 15 employees. I'm the one who knows anything at all
> about computers. When I came on, I delegated *to myself* the
> responsibility of getting rid of our current excremental Web site,
>
Stephen Eley wrote:
>
> ...So that's my reality. Cucumber for collaboration isn't the value
> for me. I suspect that there are a *lot* of companies out there with
> one-person IT departments that may fit into my situation, and
> certainly a whole ton of personal projects where there was never a
Andrew Premdas wrote:
>
> n.b. I'm expressing my opinions forcefully without much regard to tact
> or diplomacy. No offense in any way is intended :)
>
None taken. I am trying, desperately, to move from one way of thinking
to another. I expect it to be a painful process.
I am afraid the way
On Mon, Feb 23, 2009 at 10:57 AM, Andrew Premdas wrote:
>
> The focus has to first be about getting your customer really
> into producing features with you. If you achieve that then what should
> happen is
>
> 1. You and your custoimer meet often and work (rather than just talk)
> together and pro
James,
Personally I think your missing the point entirely about BDD. The
fundamental idea of BDD is to drive/guide the relationship between the
customer and developer. So you shouldn't be having meetings with customers
that arrive with
" the idea of "client" being that of an ephemeral "role" assi
Stephen Eley wrote:
>
> Well... In my opinion, yes and no. I personally have my doubts about
> the 'waterfall' chain of serial projects you're talking about here.
> "We will do authorization. Then we will do admin screens. Then we
> will..."
Perhaps I expressed myself poorly, or perhaps I
On Fri, Feb 20, 2009 at 8:02 PM, Stephen Eley wrote:
>
> You can't really show off authorization. It's visible, but it doesn't
> excite people. You need to have some basic stuff in for it before you
> can open it up to the public, but it's not necessarily Square One, and
> treating it like it is
On Fri, Feb 20, 2009 at 3:46 PM, James Byrne wrote:
>
> As a practical matter it appears to me that the logical flow is
> Authentication/Authorization, administrative functions relating to
> record maintenance, algorithmic user applications, report generation,
> utilities, and finally loose ends.
Michael Latta wrote:
> I would suggest a different approach to organizing the features.
...
> Requirements changes have a different workflow than implementation
> bugs. I would recommend you track that difference in your project
> management system. Keep an eye on how much changes after
> implem
I would suggest a different approach to organizing the features. In
particular I would recommend the features be used to test
implementation invariant aspects of the system. Our features are
whole stack sequences that involve views, controllers, and models in
almost every case. We test t
21 matches
Mail list logo
