The problem with building the book, from the start, around a working application (or, vise versa, building an application during the course of the book), in my mind, is that it requires far more cooperation and coordination between the contributors. I don't think it really works to the strengths of a collaborative, wiki-esque environment. It makes it more difficult for new contributors to join in, since contributions have to fit within a pre-defined narrative flow. You won't have people specializing in one area or another, since bits and pieces of the topic might be scattered throughout the book. And it increases the overhead for existing contributors, because of the potential for endless discussion on what should fit in where and how to improve the book's flow or the application's scope. When people only have an hour a day, and may only write a paragraph or two, I think that works against us. You decrease the contribution pool and increase the amount of effort required to get somewhere.
If, instead, we take on the role of researchers at this stage, just breaking things down by scope and topic, then we're laying a strong foundation for the best contributors to create the final product. You minimize the amount of digging and fact-checking the "authors" will have to make, while making it easy for anyone to contribute and specialize. In the process, we identify the people best suited to the task of forming that cohesive whole. It gets us off and running quickly, while accounting for the need to eventually establish a narrative, whatever form it might take. It's a less messy, albeit probably longer, method for reaching the same goal, a method with, in my opinion, a greater chance for success. Timothy S. On Thu, Sep 4, 2008 at 10:38 AM, Don Ryan <[EMAIL PROTECTED]> wrote: > The discussion here (knowingly or otherwise) mirrors something that comes up > a lot when people are debating the pedagogical approaches in academia. A > framework like Tapestry, which comes into its own on larger projects, is not > served well by using toy examples to illustrate framework features. If the > toy example is not something that anyone would ever do in the real world, > it's essentially not a very good example. > > Many introductory approaches to software development feature examples with > two or three classes and no persistence. In other words, an over-engineered > solution that essentially achieves next-to-nothing, and is consequently > unsatisfying to implement. A far better approach (along the lines of what > Howard and Thiago have suggested) involves giving the students a working > system to begin with, large parts of which are intended to be black boxes to > them, and will remain black boxes even at the end of the course. Students > deal very well with this. > > A variation on this approach (which might work well here), is that some > parts of the system could be black boxes at the outset but the intent is to > peer inside them at some later stage. So, for example, you could provide > some custom components at the outset that would make the first cut > implementation more satisying to the student. (Using custom components is > identical to using built-in components from their perspective.) You could > subsequently examine how some of the custom components are implemented and > then move on to creating custom components from scratch. > > It is worth pointing out that the structure of such an approach is > fundamentally different to the structure of a more traditional approach. The > "chapters" would essentially be phases in a development project and the > topics would be covered as a side-effect of being taken through each phase. > Trying to label each "chapter" in terms of what topics are covered may not > be entirely possible. So Timothy's suggestion of going ahead with "compiling > and organizing information, and then later on creating the narrative > structure" wouldn't really work here. Neither would such a book serve > Patrick's objective of something you could easily peruse bits of. So it's > swings and roundabouts so some extent. You do lose some things. But, in my > humble opinion, you gain a vastly superior pedagogical approach. Added to > that, you get a non-trivial demo application thrown in for free. (Whereas > you can typically achieve much less in your standard last-chapter-of-book > "case study", due to space constraints.) > > Regards, > > Don. > > P.S. Incidentally, these ideas have been around a long time. Some authors > refer to is as an "inverted curriculum" in that you start with a working > system rather than end up with one and that you interact with relatively > complex objects first rather than start by building the nuts and bolts. > This message has been scanned for content and viruses by the DIT Information > Services E-Mail Scanning Service, and is believed to be clean. > http://www.dit.ie > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
