[.ca] Software Development on a Leash (ISBN 1893115917)

From Amazon.com:
Suitable for any project manager or VB software professional willing to think outside the proverbial box, Software Development on a Leash presents some innovative ideas for building more flexible software based on patterns, and "best practices" for reusable component design illustrated in Visual Basic. This book's most salient feature is the authors' no-holds-barred attack on "traditional" ways of designing software. Instead, the approach advocated here is based on software patterns and self-modifying objects. (Instead of hard coding properties and methods as in mainstream object-oriented design, for example, this text shows how objects can modify themselves through metadata.) The result is undoubtedly more flexible objects, which can be better adapted to constantly shifting user requirements (the cost, judging from the VB code snippets provided here, is a very different programming syntax for most programmers). What keeps the discussion in check here is the book's reliance on software patterns, which recur throughout this text to enrich design concepts. Early sections look at how to create objects flexibly using Builder patterns. A chapter on collections (including iterators) shows off the author's own Visual Basic source code (all freely downloadable from the publisher's Web site). A fascinating later chapter looks at virtualizing database code. (This section more than justifies the cost of the book, and you might well productively adapt the suggestions given here, apart from the rest.) By aliasing table and field names, for example, the author shows how your team can sail smoothly despite quickly changing database requirements. Final sections glance at screen and report design, completing the circle of software that isn't at all hard-coded, but can change on the fly to meet new design requirements, even after deployment. Though probably not for every team, this text presents a good many innovative and worthwhile ideas for building more adaptable software. Even though you might not adopt its entire program, this title bears reading for any technical lead or advanced VB developer interested in software patterns and some leading-edge object-oriented design. --Richard Dragan

worst book I ever read:
I am working on a metadata driven project. So I ordered this book. I opened the book, It it looks like a 2 year VB programmer view on software development. Lots of Ideology and preaching, but nothing concreate. like "Interfaces should never be changed" which is fine, nobody changes an interface for the fun of it, but what you do when you have to. or "make your classes small, with small interface, and make as few classes as possible". again, it is like saying it is better to be healty,handsome and rice than ill, ugly and poor. My main reason for the purchase were the rave reviews that apear on this page.Re-reading them - they do not seem authentic to me.

whata-morphic?:
The author proposes a great approach and his passion about it jumps right off the pages. It's great to see a software development veteran who is still this excited about the profession. It's secondary evidence (to me) that his approach has at least some of the motivational aspects he describes. After a brief internet search, the word "metamorphic" in software context appears mainly for application porting and migration (if I have a C application to port to Java, for example). What the author proposes is something different: In his world, there is no "application code" in the program (it's *all* metadata). The author says that polymorphism is actually our enemy when attempting high-reuse, because application-specific relationships become entangled in the implementation. We can spin-off but we can't really take whole subsystems "as is" to completely new problem domains. The metamorphic approach, as I understand it, transcends this issue because no application code resides in compiled software. The download examples are eye-poppers. I have to say that I just gasped when I realized that he was dynamically reproducing screens directly from metadata created by the Microsoft IDE. As quickly as I changed a screen, the change was available without rebuilding the program. This could likely work for pulling in the definitions from any environment with screen-building functionality (PowerBuilder? Visio EA? Borland?) He ties in detailed behavioral control as well. After using Macromedia Flash and similar technologies, these also have a means to include a sort of behavioral "script" to guide the activities. The author describes similar behavioral macros to affect application activity, but for general computing. To troubleshoot, we only need a simple text editor rather than a full-blown development environment, and we can load/reload these textual instruction sets while the program is running. Would I find value in refreshing a user's desktop experience just by transmitting a new textual instruction set? Hmmm. Don't have to think too long about that one. Extrapolating, I suppose I could have a Unix and Windows version of a metamorphic program and run the same application metadata transparently on both. (Perhaps across both?). I don't see any difference in running a Unix/Motif based version of this while using Microsoft IDE metadata as screen-rendering instructions, or vice-versa (although the Gates/McNealy diehards will recoil in horror at this) The author supplies Visual Basic code for the book's examples. I'd like to see this in something more portable like C++. I'm tired of fighting the empty promises of Java.

Impressive, but not for the weak:
This is a good, chewable read. I would not recommend it for new developers, purely academic types or those without real-world appreciation of the true intensity of commercial software development. The author describes separating the application from the architecture, and while I've done this before in software on several levels, I never considered removing the application completely from the compiled software and driving application behavior from what the author calls "external structural and behavioral metadata". Using the same binary program to support multiple applications without recompiling a single line of code? Perhaps without recompiling on each and every application release, which makes perfect sense. However, he avoids rebuild for complex screen-level changes, too (even cosmetics). Not too shabby. The project examples are pretty hot - I can see how he could suggest compiling software only once and doing high-speed application re-delivery with this as a foundation. We deploy software nationally for retail point-of-sale systems and are moving into wireless hand-helds, so the prospect of delivering application-level changes without new compiled binaries is quite intriguing. His "toolkit" includes a linked-list manager (Iterator) which by the author's own confession is not new, but does provide some rather interesting twists on data organization. The linked-list as binary tree is of particular interest, since it eliminates linear searching of large data sets. The XML support is good, and I like the ability to build a very complex custom structure, reduce it to XML, then reconstruct it from XML again. This has significant implications for our XML -based applications that don't talk to each other any other way, and don't support or co-habitate with the .NET XML subsystem. I can see how using this functionality at a lower level could allow two otherwise closed systems to share common structures, or save the structure to a database as XML text for a very advanced version of behavioral persistence. I would suggest using this structure for XML support but not for an XML foundation. I think the author *likely* would agree that available XML-support components are an adaptable technology in their own right, but would fit right into his component model like any other. Again, I like the flexibility, especially since our internet servers are all Unix and Linux portals. I rigged up an example of his TurboCollection along with the interpreter and saved its run-time state into XML in the middle of executing an "application instruction". Not only could I persist the operational state of the application, I could retrieve it and pick up where I left off. This form of behavioral checkpointing is very hard to pull off at an application level, but the data structures make it fairly transparent. A side note to this is in managing XML-based transactions and queued states, indefinitely storing the application's state while it pends for new instructions. However, without a really good handle on software development and a reasonably strong foundation in data structures, perhaps even compilers, the architectural strength of this model would be lost. I've got friends who build game applications using game engines with similar characteristics. For people using it to deploy applications without touching the actual software, this model could probably be further simplified and optimized. His interpreter is also simple but intriguing, in that it can accept instructions on the fly much like the Microsoft Visual Studio .NET "command" window, yet there's no .NET IDE in sight. In the embedded "watch" window I could single-step through the "application" without the development environment. Add to this the ability to define and view "virtual" data constructs or even load and execute new instruction sets without stopping the program - and I can say the author has done his homework. For anyone who cares, the project exercise fine print shares a little secret: that the demo software program included in the downloads is the author's full metamorphic model with "some disabilities" (although he doesn't say what the disabilities are, only that they are performance-related to inhibit production deployment). If this is true, and the metamorphic software is really this small, I'm very impressed.

Good reading:
I like how the author separates the two views - application and architecture. Developing high-reuse systems, especially across multiple applications like he's talking about, is worth further exploration. I'm interested in applying this at least experimentally. New programmers won't get it - someone just starting out won't find much value here. Every application I've ever developed internally or externally uses one model and that's to code the application behavior directly into the software. The author directly asserts that this is a bad plan and develops the argument, but he's swimming upstream against every popular approach. He'll probably take a lot of industry heat for this. Looking over the standard white paper sites, I don't see much on complete physical separation of the compiled components from the application rules. If this is truly the next level, only time will tell. That Apress is willing to push these ideas says a lot for their merit. The project exercises in the book are the real bridge - just reading didn't give me the same flavor. But I would like to see more in the .NET side of it.

A textbook or a sales material?:
I have mixed feelings about this book. The main idea of it (as far as I understand) is achieving high degree of reuse by separating the software from its concrete application and expressing this application in "structural and behavioral metadata". Moreover, in your application, you must get rid of any dependecties on things that you do not control by wrapping it in your software layer and exposing it to the application as very abstract ("metamorphic") object model. The author provides some interesting examples for this and presents the basic building blocks of a software framework built around these ideas. As much as it might sound compelling this concept is not really new. What is worse is that methods and advice presented in the book are sometimes simply wrong or often have serious drawbacks which the author doesn't talk about. For example the author really hates strong typing and recommends reducing the interface of _all_ your classes to just 3 members: "Item", "Ref" and "Action". This is bizarre. The view of strong typing as an enemy of the programmer is completely wrong; it was actually introduced to help control side-effects of changes to class interfaces. Another example is the virtual database layer the author proposes: while it is true that it lets the programmer switch the underlying database engine very easily it is based on relatively low-level SQL concepts and suffers from the least common denominator syndrome. I would say that for many, if not most, application a better way is to design a higher-level database abstraction layer that takes advantage of the engine capabilities. Usually it is not much more code and the performance difference might be enormous. Finally there is the cost aspect. You cannot really adopt the method partially; either you are in or out. And you must really have almost unlimited resources to develop this kind of framework yourself. Which makes you think that it would be reasonable to get the framework developed by the author already. Which is just what the author wants and which is strongly reinforced with the last chapter of the book that literally sounds like a Ginzu knife sales pitch. Is it worth it? You have to decide yourself. For me the extreme programming advice: "Always build the simplest thing that works" has worked very well so far...