Part Two: The Lone Wolf NOJ
The first part of this article presented some suggestions of how to create a lightweight methodology designed to keep your personal software development tasks interesting and enjoyable. In this second part, we will review the creation of a tool that demonstrates the principles discussed.
I have been called evil for noting that the essence of good design is to begin creating classes based upon developer objects. I have even been ridiculed for starting to write code before talking to a subject matter expert. Have you?
From the point of view of a tool developer however, many design and consensus building activities can be easily omitted when you are the subject matter expert. From the point of view of the small company or developer, while the full RUP design suite is great to use when you do not know what you are doing beforehand, too much design can be just as project killing as not enough design.
Even when working in large corporate teams, I often like to point out that guilt about "not doing it right" can often be belayed in as much as a set of tools, often referred to as an "operating system", is invariably required to create any modern software undertaking today. In short, when we adopt a tools first project mentality, even the most ardent methodologists must concede that an awful lot of "unauthorized" software development had to occur first before anyone could come up with many of the more pedantic methodology fiefdoms. Moreover, many major tools were created far in advance of any methodologies (or methodologists) that most would notice today.
So when playing the role as the Lone Wolf, you should feel free to do whatever it takes to do what ever it is you like to do as a software developer (usually - to develop soft-wares!) If you will forgive the hopelessly Microsoft-ish terminology, when expressed in terms of company profitability, delivering the project .EXE is always more important than delivering the project .DOC.
The Tool-First Mentality
The next thing that I have discovered over the years is that a Lone Wolf developer will find that a "tools centric" or "prototype first" mentality often provides for a very palatable way to create a righteously bug free product. Indeed, when considering the "Testing View" that we will demonstrate for this project, is in reality little more than an engine prototype turned into a console accessible tool.
Figure 1 - A "Value Added" Development Approach
The figure above illustrates the views testing / prototyping method that we discussed earlier: One that I have used with a good deal of success over the years. By developing a console view, then adapting the interface to the platform / vendor specific interface, I have found that I am better able to test and maintain a virtual army of product interfaces. The tool interface makes it much easier to regression test the core technologies.
Moreover, when armed with an equally righteous frameworks and / or tool set, then jumping right from concept to code can keep you motivated by allowing you to do the things that you like to do best.
In the case of EZLOG and EZBLOG presented for this paper, a very early version of the cross-platform Neat Odd Job (NOJ) Library forms the bulk of the core technologies used.
Even when being paid to be a designer / analyst, I find that allowing my brother developers to "do their thing" while the rest of the project is milking the SMEs, ensures that team morale on both the .DOC and the .EXE sides of the house is kept high. It is simply too expensive to keep resources sitting idle while a project is being defined.
In Search of a Model
In keeping with the first part of this article, first I usually put together a model that I use to collect the essentials of what I needed to do. Namely, collect, associate, and search interesting data. From phone numbers and files, to quotes and URLs, I design succinct models that express relationships as if they were each filled out on a paper form.
Figure 2 - MVC Revisited
I would like to note here that while not a very intellectual activity, I often find that a forms-based approach to modeling any business object often provides a familiar metaphor that a user can readily understand. Better still, when it comes time to normalize the model into database schema, having the users create form-based models up-front ensures that I am able to speak the lingo at the firm.
At this point, I must mention that I understand that many modern software developers feel that "modeling" is more than simply supporting the hosting of objects between data syncs and sources. For those of you who are offend at my use of the term "model" herein, please feel free to substitute the term "data object" or "data model" whenever you are feeling so offended. Indeed, I believe that even when data are extracted by sets from databases, the propensity to omit the details of how SQL (etc) is used to extract and / or manage these data amply justifies the abbreviated usage herein. In short, my contention is that by limiting modeling activities to detailing what is unknown, rather than what is known, is simply the best part of what a good modeling activity is all about. Unless you really enjoy the chore, the Lone Wolf should not spend too much time documenting what everyone already knows!
Controller Manages CRUDS
Because the testing view separates the implementation of the controller from the GUI interface, the resulting tools that I concoct usually work equally well as stand-alone, or network applications. Once again, because of this segregation, I am usually free to take the engine out of any application, GUI or not. This means that at any given time, I could make a properly crafted application work on or across a server, across an n-tiered environment, or even underneath another programming language.
Figure 3 - Back-End Migration Possibilities
Of course, it goes without saying that it is even possible to share the same code base between massively diverse applications... Even if you have to resort to Inter Process Communications (IPC) mechanisms to do it
Like most enterprises, the controller for the majority of my projects simply brokers sets of objects from one place to another. Just like what most companies want to use data sets for. For this reason, I usually create a series of controller classes that perform the basic CRUD (Create, Read, Update, Delete) operations on a set of homogeneous record types.
I would like to note at this point that (with all respect to tradition), I have also discover that SEARCHING data is also a good deal of what modern controllers are usually all about, so the CRUD acronym these days should be expanded to "CRUDS".
When we plan for software evolution, we need not fear product revolution. From the point of view of the EZLOG console interface, the tool readily ported itself to Borland VCL, then to Java (via JNI). Indeed, because most operating systems cache so well, even the cost of executing external commands from a GUI application would be more tolerable today, than a decade ago. (Just witness how well a CGI application can run on a moderately busy server with a decent spindle speed.)
Click here to download the EZLOG / EZBLOG product.
The console interface into the EZLOG engine allows the program to be tested, as well as used as a stand-alone tool. Because the EZLOG interface is a stand along console application that uses the same technologies, it can also be deployed on clients and servers using anything from batch files to Perl or PHP --Whatever your quick-n-clean test case law-enforcers require.
We need to keep in mind that not all interfaces need maintain the same feature set. For example, while EZLOG uses a clean "do it and exit" operation, EZBLOG, while using the same MVC code, offers more things to do with a model (like publish it.) This means that there are more things to test. EZBLOG has grown so much as to merit additional testing suites.
Figure 4 - Test Case Evolution
While I use a test script to drive EZLOG test cases, EZBLOG re-uses that as well as a more sophisticated JUnit / CppUnit / NUnit style of testing. In keeping with the credo of the NOJ developer (yet another story!), you are free to do only what you have to do to create a robust NOJ.
The Punch Line: Of Iron Tools and Wooden User Interfaces?
Just as when Microsoft switched us all from "WIN16" to WIN32, the upcoming shift from WIN32 to .NET will require the best applications to change. Fortunately, over the years I have discovered that with a little experience and IPC know-how, you can indeed have the best of all possible worlds.
Figure 5 - Managing Your Future
When properly encapsulated and supported, even when it comes time to completely dispose of a product interface, maintain or migrate to another operating system, it is indeed possible to do so in such a way as to keep adding value across all product views and interfaces.
Using the concepts described in this paper, I hope that you can begin to design your business products so that they will be better able to quickly adapt to unforeseen challenges. In the final analysis, we need to begin to understand how to craft our application in such a way as to encapsulate marketing challenges. Challenges such as creating .NET compliant applications. An exciting challenge that promises to usher in the first popular object oriented operating system interface ever produced for the global computing marketplace.
About the Author
Randall Nagy has been in the computing industry since 1978. An experienced author, lecturer, and trainer, he has worked with such firms as Borland, IBM, AT&T, Informix and UTL, The State of Connecticut, Progressive Insurance, Southern California Gas, and more. Either he or his Lone Wolf associates are ready to accept your consulting assignments. His web site is Soft9000.com.