Re: When does presentation layer come in?
- --- "aacockburn" wrote:
>Agreed. And Robert talked about close collaboration, and that will
> Robert Biddle wrote:
> > It occurs to me there is no one right answer to this, because
> > good products can start from anywhere.
> Thanks, Robert, you are of course correct.
I'm just starting with this stuff, and trying to figure out how it
should work for us. I've learned a lot in the last few weeks, and
have a lot further to go (and I have to say, it's quite fun doing
I do have a clear sense from what I've read and heard and discussed
with people, that there's a tendency in some Agile approaches to push
back on the interaction design. For me, it's a question of working
out, for any given project, what's the best approach. When does
having a rough screen idea help to move things forward, and when
would it hinder? Given that you have to get the interaction design as
right in the final delivery as you do the code (and given that you
might need to change either at any point).
All I'm talking about here is scrawling some layouts and ideas on a
> To get back to the point I was trying to raise ...Alistair, it is of interest, and there is indeed no point saying that
> > what shocked me, as many programs as I've written in my life,
> > but this time being the sponsor and not the programmer, is how
> > upsetting it is to me to have to work with a marred visual
> > design for a time, even when I know it will get fixed
> > "eventually".
> I am presenting here, not a problem to be solved, but a reaction
> for consideration from a real sponsor and focal user on a
> real project.
> It is of course possible to respond with, "You shouldn't feel
> that way", or "You feel that way because you're doing it all
> wrong", but that doesn't address the matter at hand - I do feel
you shouldn't feel like that. What it shouldn't do is affect your
approach to what needs to be done. Is your reaction to the marred
visual design different from whatever the coding equivalent would be
(if there is one)?
I suspect that if I moved from a visual design bias to a coding bias,
I might feel the same way about the code - but when I'm working with
designs I always expect them to change, and I do indeed observe your
reaction in others. From their point of view they refer to it as me
changing my mind, or unable to make my mind up. I would expect and
hope that your upset would decrease over time, as you become more
accustomed to the role. It will be interesting as well to see if it
affects your views on the timing in which to introduce the
interaction design into an Agile project.
- William Pietri wrote:
> The team decides the highest priority is to fix that. So the whole teamWilliam, why do you say "apparently not?"
> spends the week rummaging through the content management system,
> rewriting copy, changing labels, clarifying wording, and so on. Not a
> line of code is written; no software is produced.
> Upon release, key metrics improve significantly. Users are happier,
> signups are more frequent, retention goes up. Millions of extra dollars
> will be made over the next year. By external measures, it is the most
> useful week of work all year.
> Would the business call that a week with progress? Yes. Would the team
> call that progress? Yes. Would that Agile Manifesto? Apparently not.
Is not the text appearing on the screen part of "working software" no
matter whether the text is compiled into the object code or read out of
some data store?
Is this not an example of "satisfy[ing] the customer through early and
continuous delivery of valuable software?"
Is this not a case of "deliver[ing] working software frequently?"
Is this not an example of "business people and developers [working]
Is this not an excellent example of a "team reflect[ing] on how to
become more effective, then tun[ing] and adjust[ing] its behavior
Your other example, where "eventually, after many months of work, they
decide they can release," seems to violate several principles,
particularly, "Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a constant
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org