A walking skeleton when there are lots of communicating components

[Rick Pingry]

Hey Gents,

I understand that a Walking Skeleton is supposed to be the thinnest slice through all of the components of a system.  Lets say your system is a multi-player game and the game client needs to communicate with a master server which then communicates to a DB and then spawns a melee server which also talks to the game client.  Should your Walking Skeleton, with its first acceptance test, try to hit all of those areas?  Or is it ok to start with some subset?  Could I, for instance, make my first tests about creating a new user and then quit, or should it slice through creating a new user, logging in, finding a battle to join, and then starting a new battle, then exiting the battle, then quitting?

Thanks,

-- Rick

[Nat Pryce]

I'd make it just connect to the server, do a very simple operation,
and then quit. No spawning, no DB, no logging in at this stage.

--Nat

www.natpryce.com

[James Richardson]

Sounds like a lot of this has been pre-designed.

Db, master server,melee server, users, logins, battles... All these are design decisions that are reducing choice.

Why not try to do something in your game, as a test, then write the bits that make that work...

I mean, you might end up with a free-form p2p game with no master server, and no persistent user info...

James

[Donaldson, John]

Yes, I like this answer – it goes right to the heart of the matter – “Growing” OOS…

Of course, life is rarely that simple, but still.

 

John D.

[Witold Szczerba]

I would be careful with the extreme way of thinking like: DO NOT plan
or care about anything ahead. It looks like going from one doomed to
failure position which is: do complete and detailed plan before
starting to code (aka waterfall) to another which is 100% opposite: no
plans at all. I think both edges are not good, one has to strike a
balance between them :)

As to the original question: the walking skeleton is something good
enough to be able to start working on a project, which is easy to
launch, there are initial tests prepared, so you can do initial commit
and announce to your team something like:

People: fetch the code and launch it; once you have it working - start
adding your stuff and push to repo with confidence, because walking
skeleton let you execute and verify your job continuously :)

Regards,
Witold Szczerba

[Steve Freeman]

Of course there are no guarantees, but we have learned a few things over the past 10 years. One of which is that initial designs can be surprisingly wrong. The fewer commitments we make early on, the more scope we have to stumble into a better answer. This assumes that we have the skills, experience, and discipline not to crash the development. It's not until you've gone too far that you know where the limits really are :)

In this case, it might be worth starting with some tiny feature of the game with a simple brutal implementation, perhaps hard-coded into the server rather than with the extra moving parts.

S.

[Gian Carlo Pace]

Hi,
IMHO is not important the balance of the quantity of details I want to plan in advance but how many times I actually _start rethinking_ about them and how often I challenge them to be still true.

So if you start small you have to bring details and architecture into questioning many more times than designing a much bigger (even not huge) section in advance.

This remains so hard to me because I can't take any of my decisions for granted and this makes me feel a bit lost but the huge benefit is that I can hopefully stay stick to the goal without going off the track driven by my own technical solutions.

Cheers,
--
gk

twitter: @gicappa

p.s. after reading the [great!] book and lurking the ML for a while here is my first post so... hi all! :)

[Colin Vipurs]

One approach we've taken is that we have a high level architectural
"vision". Something a bit more concrete than the broad-brush
architecture diagrams. We don't stick rigidly to this though - our
architect has planned out alot of moving parts, but we only implement
what we need to when we add a feature.

I've found this gives us a nice idea of whats supposed to go on, but
when we get to it, if the landscape has changed we have the
flexibility to do something differently. I would say that planning
itself isn't bad, but rigidly sticking to it no matter what, is.

--
Maybe she awoke to see the roommate's boyfriend swinging from the
chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

[Lance Walton]

I'm responding to the thread rather than Colin's particular post.

I've been building software commercially now for almost 20 years, and the longer I do it the less I understand what people mean by 'architecture'. Can anybody define it for me, at least in the context of this thread?

Regards,

Lance

[Uberto Barbini]

It's the stuff the architects do. :)


Uberto

[Gian Carlo Pace]

I'm a "dwarf on giants' shoulders" but I would say dependencies and interactions between parts at different levels: starting from objects, passing through services and going up to physical servers.

If why are you asking that?

Cheers,
--
gk

twitter: @gicappa

[Colin Vipurs]

That probably depends on what your job is ;-).

From my point of view and in the context of this conversation it's
merely "bits that talk to other bits". We have a bunch of REST based
web services and some datastores. Architecture for me is the boxes
and the lines that connect all of these things. We also use queues
and topics so it would include those too. I guess its mostly about
the information flow.

What it doesn't include for me is the physical hardware, data centre
location etc. That's the architectural vision that our service
engineering team have.

[Matteo Vaccari]

On Thu, Oct 18, 2012 at 10:05 AM, Witold Szczerba <pljos...@gmail.com> wrote:

I would be careful with the extreme way of thinking like: DO NOT plan
or care about anything ahead. It looks like going from one doomed to
failure position which is: do complete and detailed plan before
starting to code (aka waterfall) to another which is 100% opposite: no
plans at all. I think both edges are not good, one has to strike a
balance between them :)

There is a difference between thinking ahead and committing to a design ahead of time. I'd like to be able to imagine the whole system when it will be finished with all the components communicating together.  I like to balance in my mind how variations and changes in the architecture would affect the visible properties of the system.  This is a thought process that I would like to go on in the back of my mind during most of the time while development is on.  

This is not the same as writing down a decision and sticking with it.  I'd still like to develop the system incrementally and learn as I go.

Matteo

[Kim Gräsman]

Ask Jim Coplien. I did, and I still haven't recovered.

- Kim

[Steve Freeman]

:)

[Jack Bolles]

For me, it means the underlying principles that (can) effect your design and the subsequent decisions. An example might be when building a web app, do you support REST or enforce the single URL or something in between? 

For many apps we write in finance, this may be less important because each is a link in a chain rather than encompassing an entire ecosystem. But that decision itself (semi-autonomous apps pushing data) is another example. 

Another edge would be for decisions that require cross-application integration - e.g. drawing boundaries around long-running transactions is a third. 

I'm not sure what Colin means. Architecture that concerns itself mostly with components never made sense to me.

YMMV

-- 

Jack

[J. B. Rainsberger]

On Thu, Oct 18, 2012 at 5:44 AM, Lance Walton <lance.c...@googlemail.com> wrote:

 

I've been building software commercially now for almost 20 years, and the longer I do it the less I understand what people mean by 'architecture'. Can anybody define it for me, at least in the context of this thread?

I stick with "irreversible decisions in the large" as a working definition. It serves me well.

-- 

J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Author, JUnit Recipes
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com

[Colin Vipurs]

It's ok, people rarely know what I mean. I get told it's my northern accent :).

In this context what I mean by "components" is "web services", not
blocks of code talking directly to each other.

[Xuemin (Shuemin) Guan]

hi Lance, I share what you feel about how the 'architecture' is used in our industry.

In my limited career years, I have worked with a few people who had architect as their job title. Many of them draw broad brush boxes, clouds, and lines. They also tend to talk in abstraction. This usually does not help me do my job as a developer at all.

But, I'm aware there are good architects out there, it's just that I haven't had a chance to work with them.

I also have worked with many people, who had dev as their job title, and who I respect for their technical excellence and integrity. I consider many of them experienced enough to make specific important technical decisions. Such as how we go about testing, which framework we should choose, the style of our coding, and which one we should avoid, what tools or infrastructures we should use to implement functional or non-functional requirements. I find them most useful to do my job.

I don't feel I can define what it is. But I will try to explains what it means for me in a more concrete way.

For me, a large part of architecture is about choices of tools, framework, and protocols etc etc. Sometimes it is about not to choose to do certains things or do certain things. We make these decisions in order to fullfil the same set of functional and non functional requirements for various stake holders. 

Examples are, 

Should it be a web app or native desktop app?

Do we need to persist the input data? If we do, do we just need solr or actually a database. If it is a database, which one?

Do we need to consider to have monitoring?

Do we need to design for cacheability? And how?

What choices do we need to make to scale our app? Multi-threading, or shift it to infrasture? Or something else entirely?

Do we want to use a framework to manage dependency injection and transactions for us? Or it is something we can just do it ourselves using the basic language constructs?

Does part of the functionality warrant a separate app, if yes, how do our app talk to it? Or it should be in the same process?

Sorry for a long post, my 2 pennies.

Xuemin

--
Xuemin Guan
www.flickr.com/photos/wukong
twitter.com/wickedwukong

[Nat Pryce]

For me the walking skeleton's job is to help me understand the
system's environmental constraints:

* what external systems does it have to integrate with?
* what infrastructure does it have to run on?
* how do I get it there?

Anything else is implementation detail, and I don't want to constrain
that with my tests.

--Nat

--
http://www.natpryce.com

[Lance Walton]

If I can't see as far as others, it's because giants are standing on my sholuders.

I'm asking because several people on the thread have said 'architecture' and I don't know what it means.

[Raoul Duke]

> I'm asking because several people on the thread have said 'architecture' and I don't know what it means.

just like biologists don't know what 'gene' means. that is, it has a
lot of different definitions, not just even connotations. you can
probably look up a dictionary definition of "software architecture".

http://en.wikipedia.org/wiki/Software_architecture

'To date there is still no agreement on the precise definition of the
term “software architecture”. However, this does not mean that
individuals do not have their own definition of what software
architecture is. This leads to problems because many people are using
the same terms to describe differing ideas.'

:-)

whatever definition one chooses, if any, it has to be compared to the
definition of "design" and possibly even "implementation".

[Lance Walton]

Yup. There have been several good responses, some consistent, others not. It doesn't really matter, but would help if we knew what was being discussed within the context of this thread...

[Raoul Duke]

(p.s. some silly $0.02 thought of mine... you can maybe brainstorm a
list of litmus tests <something> must pass in order to be considered
"architecture" (oh god i sound like ed meese?). but there will be a
matter of degree vs. "design". for example: when a new feature comes
along, a good architecture will support implementing the new feature
with as little trouble as possible (code change, knock-on effects like
bugs and maintainability and all the other *ilities and security and
you name it). now design could do that as well, but i guess design
tends to be e.g. inside a few modules rather than e.g. across the
entire end-to-endness of the application. i sorta buy into the idea
that architecture and design are the similar, just at different levels
of fractal zoom on the particular whole software project.)

[Lance Walton]

I should have been more specific. I don't want to know what all possible ideas of 'architecture' are. I'd like to know what people mean by it in this thread.

[Raoul Duke]

On Thu, Oct 18, 2012 at 1:49 PM, Lance Walton
<lance.c...@googlemail.com> wrote:
> I should have been more specific. I don't want to know what all possible ideas of 'architecture' are. I'd like to know what people mean by it in this thread.

no, you actually said that a few times, no problem, but nobody can
resist giving their opinion when the subject comes up!!! that's part
of the effing problem with the whole subject, i bet :-)

[Reuven Yagel]

But in his lean arch. book (2010) Coplien just say that it is:"the form of a system"
-Reuven

[Steve Freeman]

ah, now I understand...

S.

[Donaldson, John]

I always go back to the analogy of software architecture with house and town architecture.

How do you ensure the plumbing of a house works, and that the rooms are friendly, and the house doesn’t fall down?

How do you ensure that the houses and the roads and the bridges and the business fit together nicely?

It’s all what we might call architecture at different levels.

 

If you get to an architecture by letting it evolve, or you impose it from the outside – it’s still there and you can still – fruitfully – discuss it.

 

You may want to deny the word – but there’s something behind them.

 

John D.

[Steve Freeman]

Agreed. And there are metaphors out there about how enterprise architecture is more like town planning.

S

[Donaldson, John]

Yes - the French seem to call it "urbanization" - as far as I can tell "town planning" - but still a sort of architecture.
John D.

> If you get to an architecture by letting it evolve, or you impose it from the outside - it's still there and you can still - fruitfully - discuss it.

[Eric Lefevre-Ardant]

FWIW, "urbanisation" in France applies mostly to enterprise-wide architecture. So, big companies would be interested in it; smaller companies, less so. In fact, I've only heard it in connection to the likes of EDF, Eurocontrol, etc. Somehow, their presentations always involved (that was years ago) EAI software.

Indeed, "urbanisation" translates as "town planning".

[Lance Walton]

:-)

A few years ago, in the Zachman Framework web-pages, this definition was given: Architecture is the set of documents that ...

I can't remember what the '...' was, but I'm pretty sure that that definition was about as wrong as it's possible to be, just given the way it started.

[Nat Pryce]

I'm currently preparing a lecture & exercise on architecture for an
undergraduate course, and the term is actually defined by an IEEE
standard. IEEE1491 I think.

www.natpryce.com

[Antonio Carpentieri]

this one? 

https://en.wikipedia.org/wiki/IEEE_1471

[Nat Pryce]

That's it. IEEE 1471 defines architecture as:

The fundamental organization of a system embodied in its components,
their relationships to each other, and to the environment, and the
principles guiding its design and evolution.

But I prefer JB Rainsberger's definition -- it's far snappier.

--Nat

--
http://www.natpryce.com

[Lance Walton]

Ah. Now I understand.

On 19 Oct 2012, at 11:22, Reuven Yagel wrote:

[Lance Walton]

'fundamental', 'components', 'environment', 'principles' : I probably need to circle around a few more times before grokking this.

I prefer JB's definition better. I think Martin Fowler also said something like "architecture is the stuff that you will wish you'd done differently" or something like that.

[David Peterson]

Heh, I actually like the IEEE definition, although I agree it is a bit wordy. What I like is that it's expressed in terms of a "system" and, since systems can be nested, implies that architecture is at every level not any specific level. That's the way I see architecture: fractal.

[Matt Savage]

David Peterson <da...@crowdsoft.com> wrote:

> That's the way I see architecture: fractal.

That's been my experience too.

http://deadwildroses.files.wordpress.com/2012/09/fractal-wrongness.jpg

[Esko Luontola]

On Friday, 19 October 2012 19:21:16 UTC+3, Lance Walton wrote:

'fundamental', 'components', 'environment', 'principles' : I probably need to circle around a few more times before grokking this.

I prefer JB's definition better. I think Martin Fowler also said something like "architecture is the stuff that you will wish you'd done differently" or something like that.

In "Who Needs an Architect?" [1] Martin Fowler says "I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important."

He also quotes Ralph Johnson who mentions some definitions, such as it being the "shared understanding" of the developers, "the set of design decisions that must be made early in a project" (commenting about it "I complain about that one, too, saying that architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other."), and finally "Architecture is about the important stuff. Whatever that is."

I like Martin Fowler's definition of architecture being the things that are preceived as hard to change. I quote:

Remember Johnson’s secondary definition: “Architecture is the decisions that you wish you could get right early in a project.” Why do people feel the need to get some things right early in the project? The answer, of course, is because they perceive those things as hard to change. So you might end up defining architecture as “things that people perceive as hard to change.” [--] I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.

[1] http://www.in-ag.eu/uploads/media/whoNeedsArchitect.pdf

[Lance Walton]

Thanks. Looks like I might have made up a definition too :-)

[Lance Walton]

Maybe it's the kinds of systems I work on (simple ones), but I've never needed anything like that.

[J. B. Rainsberger]

On Fri, Oct 19, 2012 at 1:21 PM, Lance Walton <lance.c...@googlemail.com> wrote:

 

'fundamental', 'components', 'environment', 'principles' : I probably need to circle around a few more times before grokking this.

I prefer JB's definition better. I think Martin Fowler also said something like "architecture is the stuff that you will wish you'd done differently" or something like that.

I learned my formulation from Fowler. In "PEAA" he wrote about irreversible decisions, and that really stuck with me.

-- 

J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Author, JUnit Recipes
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com

[J. B. Rainsberger]

On Fri, Oct 19, 2012 at 2:51 PM, David Peterson <da...@crowdsoft.com> wrote:

 

Heh, I actually like the IEEE definition, although I agree it is a bit wordy. What I like is that it's expressed in terms of a "system" and, since systems can be nested, implies that architecture is at every level not any specific level. That's the way I see architecture: fractal.

I tell people that architecture is just large-scale design, and so the same principles apply in the large as in the small. Most people don't buy it at first.

-- 

[Esko Luontola]

On Friday, 19 October 2012 23:17:45 UTC+3, J. B. Rainsberger wrote:

I tell people that architecture is just large-scale design, and so the same principles apply in the large as in the small. Most people don't buy it at first.

 

I love Kent Beck's experience about his daughter in http://www.infoq.com/presentations/responsive-design at 46-48 min. :)

[J. B. Rainsberger]

Thank you. I hadn't heard that before.

[Matteo Vaccari]

To me, "architecture" is about things I sometimes need:

• make sure that we all have a rough idea of how we'll develop the system
• make sure new team members can find their way around
• make sure we can show the stakeholders that we have a clear idea of how their problem could be solved, and how our solution will fit within the rest of the enterprise system

The last point is about an attitude I've seen in some XP teams that might say "we don't know how the system will be, we'll learn along the way" which might be true but is not what will get you the trust of the stakeholders.

What do you think?

Matteo

[Steve Freeman]

Of course everything depends on context. Like most projects, the original C3 had various critical features fixed before anyone started, including the most flexible dev environment ever.

The trick that many organisations miss is that often the best way to achieve what the stakeholders want (a degree of confidence in the result) is to do a minimum of validation and then get on with it. Actually making this work requires skill and flexibility, both of which tend to be lacking in enterprise situations.

I think it's reasonable for a dev team to say "this is how we do things" (that's what Energized Work do), as long as they can find consenting clients. Less sophisticated clients will need different teams.

S.

On 21 Oct 2012, at 07:40, Matteo Vaccari wrote:
> - make sure we can show the stakeholders that we have a clear idea of

[Nat Pryce]

I remember reading a definition of architecture that was something
like "decisions that would be too expensive to change". Anyone know
where that comes from?

--Nat

On 18 October 2012 13:04, J. B. Rainsberger <m...@jbrains.ca> wrote:

> On Thu, Oct 18, 2012 at 5:44 AM, Lance Walton
> <lance.c...@googlemail.com> wrote:
>
>>
>> I've been building software commercially now for almost 20 years, and the
>> longer I do it the less I understand what people mean by 'architecture'. Can
>> anybody define it for me, at least in the context of this thread?
>
>

> I stick with "irreversible decisions in the large" as a working definition.
> It serves me well.

> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
> http://blog.thecodewhisperer.com
> Author, JUnit Recipes
> Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com
>

--
http://www.natpryce.com

[J. B. Rainsberger]

On Sun, Oct 21, 2012 at 9:18 AM, Nat Pryce <nat....@gmail.com> wrote:

I remember reading a definition of architecture that was something
like "decisions that would be too expensive to change".  Anyone know
where that comes from?

Fowler, for me. Probably even in "Refactoring", but definitely in "PEAA". Maybe even the early C3/XP articles.

-- 

[David Peterson]

Nat, have you tried thinking about architecture from a program-is-a-graph point of view?

[Rick Pingry]

Thanks everybody,

So to sum things up what I am hearing to this point, the walking skeleton is only about setting up the REQUIRED external components, and you should be careful about making any other decisions too early.  I am not sure I quite get that though, what is too early?.  The GOOS book does say you should set up a broad-brush architectural design before your first acceptance test.  What if I really don't have any external requirements?  I am responsible for the whole thing with all of the decisions right from the start.

Let's give a slightly simpler example to get a better idea of what the FIRST ACCEPTANCE TEST should look like.  Let's say I am working on a program that needs to have a plug-able architecture, a list of tools that can be created after my program is done by a plug-in writer.  When the user opens the program, those tools show up in a list and the user is going to be able to drag and drop those tools onto some other widget and configure their inputs and outputs to create sort of a meta-programming language.  Kind of like MATLAB I guess.  At this point, I am not sure about the complete structure I am going to need for what is a plug-in, but I know I am going to need a name, an icon, and a nice description with links to documentation.  I will also need some kind of list of configurable inputs that the user can edit.  There may or may not be some actual dynamic code the plug-in writer would actually need to write in JAVA.

So, that should be enough to get started I think.  I *think* that I will probably have a folder on the file system and then scan that folder for anything that looks like a plug-in and list them.  Is it too early to be thinking that way?  What is the first acceptance test?  Let's say that I want to start with some plug-is, "A", "B", and "C".  Is my first acceptance test showing the user the three plug-ins in the list and hard-coding them?  Or is it perhaps the fact that I am scanning the folder for the plugins, even though that by itself does not give the user feedback, so it does not seem complete, so probably not.  Is it the whole thing, starting from scanning the folder and showing the list of plug-ins?  That seems pretty big.

So, I go round and round in my head with stuff like this.  

As I am writing this, my gut is telling me that I can start with showing the hard-coded plug-in list and then evolve the *test* (as well as the code) to have set-up and other conditions that include populating a folder with the plug-ins I want to read.  Perhaps the problem I have been having is that I think of the each test as I add it as being static, that EACH acceptance test is "correct" as it is being written.  Maybe the idea from the very start is that I am evolving a test, along with the code.  GOOS talks about the grander TDD process that includes writing a failing acceptance test, and I always thought of that as creating a brand new failing acceptance test, but perhaps it could also be fleshing out an existing test, adding setup, teardown, and constraints.  You might be working on adding to one test... "whenTheUserStartsTheySeeAvailablePlugins()" for a while.

That said, would that same idea continue all the way until you actually have a useful user story?  Not just open, see the plugins and close, but perhaps a happy case of the walk through the entire system of seeing the plugins, configuring them doing real work, then closing?  Perhaps this primary use case walks through the system and many other tests handle edge cases.  Or is that going too far?  GOOS does have its first example of the user starting the bid and losing, but that is at least a full useful cycle for the user.

This is starting to jive, but please let me know if my thinking is going the right direction.  Hope this helps someone else that might have had similar issues.

-- Rick

[David Peterson]

Good question. This is what it's all about!

There are goals and solutions, and they form a hierarchy such that a solution at one level becomes the goal of the next level down. At some point, there's a switch from the language of the business needs to the language of the implementation.

I recommend trying to write the acceptance tests as far as you can in terms of the business needs, rather than the implementation. If you do that, it will free you up to change the implementation.

"Plugins" and "scanning folders" and "widgets" and "icons" are all in the language of the implementation. What are the business needs?

David

[Raoul Duke]

On Tue, Oct 30, 2012 at 9:05 AM, David Peterson <da...@crowdsoft.com> wrote:
> "Plugins" and "scanning folders" and "widgets" and "icons" are all in the language of the implementation. What are the business needs?

...when one eventually gets to the implementation language :-) i day
dream that it would be nice to come up with a 'model' that abstracts
the idea of plugins separately from how they are to be presented. so
you can keep the gui-specific "icon" idea from getting mixed into and
polluting code for other uis.

like as a thought-experiment-forcing-function, what if e.g. you have
to support 2 different UIs, one that was crappy ascii command line,
and another that was fancy gui stuff? then one might try to have the
ideas existing apart from how they are drawn on the screen. (like some
metadata in the plugin might be used to look up the desired icon in
gui mode, but the ascii mode would just show the name in text.)

so it seems like there's the top-down thing of trying to stay in the
business terms for as long as possible, to keep yourself more flexible
and focused, and then when you are in any given level you also have
the horizontal splits to do of trying to make cohesive but not coupled
'units'.

sincerely.

[Steve Freeman]

In this hypothetical case, I'm not sure I'd start by thinking about plugins. I think I'd start by implementing an application with a representative sample of the features these plugins would implement. I'd then refactor very hard to isolate the common behaviour, and back the plugin mechanism out of the code. Then I could tighten it up to provide the extension mechanism. I can do this if the development is under my control, things get harder if I have to coordinate with many other people.

A boss I used to work for reckons that it takes three rewrites to come up with a properly reusable framework.

S.

On 30 Oct 2012, at 15:01, Rick Pingry wrote:
> So to sum things up what I am hearing to this point, the walking skeleton
> is only about setting up the REQUIRED external components, and you should
> be careful about making any other decisions too early. I am not sure I
> quite get that though, what is too early?. The GOOS book does say you
> should set up a broad-brush architectural design before your first
> acceptance test. What if I really don't have any external requirements? I
> am responsible for the whole thing with all of the decisions right from the
> start.

> [...]

>
> This is starting to jive, but please let me know if my thinking is going
> the right direction. Hope this helps someone else that might have had
> similar issues.
> -- Rick

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

+44 797 179 4105
Twitter: @sf105
Higher Order Logic Limited
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 7522677