Re: [Gnu-arch-users] arch 2.0 survey followup

[Thomas Lord]

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