Re: arch 2.0 survey followup

Talli,

Thanks.  You helped lead me to a couple of .... dare I say it .... 
decisions.

   1. One of the products of an Arch 2.0 project should be a detailed 
marketing analysis.
       Completing that analysis is not a prerequisite for starting 
design and hacking.  Rather,
       the marketing analysis is part of the product documentation and 
should, like the code,
       be developed and maintained in an iterative, short-cycle process.

   2. Yes, Windows support is critical.

   3. Yes, a GUI is critical.  Committing to Ruby on Rails in a deep way 
would be a
        mistake but it would also be a mistake to not use Ruby on Rails 
for a first GUI
        which should, in parallel with the rest of the code, be 
developed in an iterative
        process.

-t

p.s.: here's how I got there...

Talli Somekh wrote:
> * Asking which market is ideal may be inappropriate given the skills 
> in the community. There are no MBAs around here and while some may 
> think that is a net positive there is a skill set that shouldn't be 
> ignored.
>
Agreed.

> But if there is interest in doing a market analysis, I recommend first 
> doing a complete competitive profile to understand who the competitors 
> are and what are their strengths and weaknesses. Then perform a review 
> of what users seek from a RCS. From there, a gap analysis can be 
> created that defines a set of features that can provide a target for a 
> differentiated application.
>
I only partly agree with that recommendation.   The main thing that I 
disagree with is the use of the words "first", "then", and "from 
there".   To a lesser extent, I disagree with "from a RCS".

In some kinds of product categories, what you're saying is obviously 
spot on.   Let's say, for example, that we're going to design a new 
microwavable lunch in an attempt to grab an extra 1% of refrigerator 
shelf space at 7-11.   Well, we better be able to sell better and make 
more money than whoever currently occupies that shelf space.    We take 
as a given that we've got the best food scientists and maybe we even 
have a few trade secrets or patents that will allow us to do something 
seemingly miraculous (e.g., deliver fried goods that come out of the 
microwave nicely crisped).    Now, we have a design problem and don't 
have an a priori understanding of the constraints that design that 
problem.   We need to understand existing consumer habits.   We need to 
understand why consumers currently make the choices they do.   We need 
to figure out what drives consumers are satisfying and how existing 
products only partially meet those needs.   We need to find the gap in 
current offerings that we can fill to achieve differentiation.   It'll 
be swell if we can use our "crispy fried foods" tech for this but in 
doing the marketing analysis, we should be prepared to reach some 
conclusion like: "the best bet is to make a package that is dramatically 
easier to open without burning yourself".   In any event it's important 
to do all of this research up-front because once we have a product 
design, there's then a huge and relatively inflexible investment to get 
from there into production, distribution, and advertising.

So that's a kind of waterfall method of product design.   It's really 
appropriate where, like microwavable lunches, it's pretty easy to study 
the market and, additionally, the production and selling pipelines are 
so expensive to set up and so inflexible in design that you are forced 
to place one big bet.  It's not obviously /necessary/ but it sure helps 
a waterfall approach if you have things like trade secret and patent 
protection on your side so that, during the relatively slow process of 
bringing a product to market, you aren't so easily scooped.

/Some/ kinds of software projects are different and a waterfall approach 
doesn't make as much sense for those projects.   This is why I object to 
"first", "then", and "from there" in your suggestion.   An iterative 
process seems to me to make more sense: continuously developing the 
requirements and the product in parallel, with feedback between the 
two.   I don't have XP or Agile _religion_ but I do think Kent Beck and 
friends are basically right.

I strongly agree that the kind of analysis you suggest is important and 
valuable, though.   I'm beginning to think that, in very literal terms, 
the source tree for Arch 2.0 ought to have a directory set aside for 
this kind of analysis.   Maintaining and improving it should be part of 
the project.   The initial contents can be quite crude but over time, it 
should be tuned up.   It's part of the project's documentation.


> * The current set of "markets" are so disparate as to make "targeting" 
> them almost satire.
>
> An alternative exercise that IMO may be more effective for the 
> community's planning for 2.0 is to develop a set of scenarios. Each 
> scenario describes the relationship between various classes of users 
> and their application of a feature set. For instance:
>
We have the humble beginnings of that, especially in the comments from 
Matteo and Aldrik.   Check it out -- they wrote some really good thoughts!

I think the example you go on to give (which I encourage people to go 
back and read) does a good job of pointing out the level of specificity 
and the focus of attention that is ultimately desirable.    I'm not sure 
that, at this junction, I want to hold up things to insist on perfecting 
our scenario analysis.   It's something to iterate over, just like the 
code.   Crawl. Walk. Run.

> * Windows is critical. 
I think that's really clear.

To an extent, it can only help the quality of the code to be portable in 
that way.   It takes nothing away from the GNU mission, only helps, to 
make sure Windows is well supported.

> * A GUI is critical. A thought that Tom and I discussed previously was 
> to build a GUI using a web framework like Ruby on Rails that has very 
> good ajax functionality so that a rich GUI can be built that is cross 
> platform and can be run either in a client server enviro or as a 
> desktop app. Designing the system with thoughts about a GUI now using 
> a light framework atop of the system would be a big win, particularly 
> when one of the potential users is a manager (see scenario above).
>
I very strongly agree about a web-based GUI using AJAX.

I think Ruby on Rails *might* be a good choice and is *certainly* a good 
resource.   So, why the hesitation?  

Part of what makes RoR so hackilicious is ActiveRecord foo -- the 
automagical mapping of an SQL database into an object system with 
precious little need to drop SQL fragments into your code.   It's 
certainly not a *bad* thing to have convenient SQL hooks in the 
framework for an Arch GUI but it isn't a central concern by any means -- 
so one big win of Ruby has only slight applicability here.  Or maybe it 
is a central concern, depending on where use scenarios lead us.   I just 
don't know yet.

Another part of what makes RoR so hackilicious is that it, in fact, 
seems to have a nice core AJAX library that, like ActiveRecord:SQL/RDBMS 
means that AJAX hooks are nicely mapped into the language.   But the 
make-or-take-or-borrow decision is a little unclear to me at this 
point.   It *might* be the case that snarfing and munging the javascript 
library from the RoR framework and mapping it into some other 
programming environment is an equally good or better choice.

All that said, I don't think there is any better choice than to (a) 
build /*a*/ GUI in parallel with the
core functionality; and (b) build that first GUI using RoR.

Building a GUI in parallel avoids a waterfall approach to making sure a 
GUI is possible.   It also ensures that (since we are talking about 
supporting users who are sure to prefer a GUI) the core functionality 
design evolves with real feedback about how it looks from a GUI perspective.

Building a first GUI with RoR is appropriate because it's so freakin' 
easy compared to alternatives;  because revolutionizing web-gui 
frameworks is not (yet? :-) central to the Arch project;  because lots 
of people will know from day one how to hack it; and because I think we 
are safe in assuming that RoR will just keep getting better and better 
in the short and medium term.  I'm sure there are other reasons, too.


-t