Part One: Are we not Wolves?
Software developers are like wolves. Depending upon the size of the prey, sometimes we need to run in packs. Sometimes we need to run alone. Sometimes we need to do a little bit of both.
Most software development methodologies seem to have been designed more with the wolf pack in mind. While many of the pack management tools are very beneficial, using these processes often consumes more time than the lone software developer (or many a small company) has to invest.
From the point of view of the Wolf Pack developer, while formal "design-first" processes are 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. When you know what you are trying to accomplish only too well, then you should feel free to jump right in and do what you know. This means that when you are working in small teams trying to move quickly (or alone), then you should feel no shame in spending more time creating software than in developing shelf-ware.
Even when running in-groups, wolves need to be individually motivated. Of course, when prey is scarce, hunger is always a motivator. You do what you have to do to survive. However, when you have what you need to survive, then bringing down a big project, either alone or in-groups, is about personal accomplishment... Team success... Learning new techniques... Having fun!
Of course, during the day the "thrill of the hunt" can go a long way to keep you motivated after the basic needs have been met. Once the days work has been done however, earning a right to howl over the prey is what motivates many a well-fed wolf to rejoin the hunt tomorrow.
When tacking a huge project as a Lone Wolf, common sense will tell you that you will only be able to bring it down one bite (byte?) at a time. Moreover, in order to keep you coming back to the hunt each day, you need to feel like you have gained something for each and every session you spend working - especially if you are sacrificing scarce part time hours away from the rewards of family and friends.
I have discovered that failing to appreciate how much each of us needs to feel a sense of accomplishment after a day of hard work has demoralized more great projects than any other single factor. In general, most of us need to see some progress each day, certainly each week, for the majority of the time that we sacrifice to the hunt. For this reason, redefining research and development chores in such a way as to demonstrate personal successes becomes even more important when working alone.
Obtainable Goals and Granularity
History has taught us that any large goal can be divided into a series of smaller steps. For example, when we bundled our programming tasks into modules and called them "objects", we discovered modern modeling techniques. When we named our objects in such a way to support cohesive and understandable units of work, we discovered how important re-use is. Finally, when we ensured that our objects readily couple together to achieve our results elegantly, we discover the true meaning of reusable software architecture.
Unfortunately, once companies understood what software engineers were up to, they began to let others use our models to drive us like sheep, rather than to allow us to operate like the wolves that we are. Over time, not only is the act of herding wolves somewhat self defeating, but in the rare instance when a company is able to make it work for a while, the cost is usually expressed in terms of producing software that merely imitates others.
The problem is that sheep seldom create "killer applications". Time and time again history proves that the best work comes from empowered, insightful, well-fed, and caring workers. I have seen first hand how the ability to culture and tolerate an empowered, entrepreneurial spirit is why small companies become large, and why its lack is why large companies become small.
So how to create a process that encourages people to act like wolves, rather than sheep? Doing this for a group can indeed be complicated. It is an involved subject that required detailing an approach worthy of an entire book. However, establishing your own personal habits and tactics that allow YOU to keep motivated enough to finish a project on your own is very easy to understand. Sharing what I have learned to help keep me motivated is why I took the time to write this paper.
The Tao of the Lone Wolf
Let me being by saying that I have created many software products. Over the past 20 odd years or so, I have worked on hundreds of products, tools, and frameworks using the technique that I want to share with you today. I offer a mere handful of my more interesting products at my web site.
To begin the process of tacking a project as a Lone Wolf, I have discovered that you need to understand is what type of wolf you are. By way of a statement of work, you should begin with understand the type of mission you are setting out on.
For example, whenever I start out on a project, I usually define the mission statement for the undertaking as a trade of between three goals. I call them the "3 Fs", or "Fun, Fortune, and Fame". When it comes to selecting Lone Wolf activates, many find that they can pick any two at the expense of the third. This concept is interesting enough to spend a little more time understanding what the trade off between things like [fortune / fun] or [fame / fortune] often entail. Let me share with you some of the 3F tradeoffs for a few of my more modern projects.
Fun / Fortune / Fame
Of course the theme of "Fun" is easy enough to understand, but when you own a company, "Fame" can translate into simply getting the word out that you have some neat technologies to offer.
A good illustration of my "Fun / Fame" project would be my "Neat Odd Job" (NOJ) Project at Sourceorge.Net. Why? -Because the task of re-hosting my huge labyrinth of personal source code was done certainly more for "fun" than "fame". Indeed, even if I write a book on the subject that sells the best-case 10,000 copies or so, it is doubtful that it will ever make me enough coin to pay for my time investment. However, as a reusable set of core technologies, the 10 odd years that I spent evolving it created a great core for use in the rest of my products. It also helped me learn enough about the process to write this paper for you.
But like you, I also have to pay the bills. For this reason, creating EzGourmet, News*NET, FileSpy, and EzSearch were done mostly for Fortune (read m-o-n-e-y) and Fun (or Fun / Fortune?) As a five-star software offering, next to EzInstall, EzGourmet has been the most popular Lone Wolf title that I have written to date. (Well, there was a little fame involved when PC Format Magazine chose two of these tiles to display on their covers this year.)
Finally, "The Quote For Today" and (more recently) "Doctor Quote" was a way to write an ezine list server and automatic content generator, so creating is was mostly about building community. Clearly an example of the "Fame / Fun" emphasis, as up until very recently I gave the product away in exchange for signing up to my free daily ezine.
So before you begin a project, take a moment to step back from it for a quick inventory of your expectations. Then look at the world, your 3F balance, and take a guess at where it is going. Bring the two together, and plot a path that takes you where you want to be as if you were giving advice to someone else.
Oh yes... And unless you hold a lot of Microsoft stock, don't neglect those bill-paying activities!
So much for the Artificial Intelligence. Now let me share a lightweight R&D methodology that has worked for me when playing the role of a Lone Wolf developer for the past 25 odd years or so.
A Common Problem
Many a project comes to me during my contemplative moments, usually during the off hours. (EzGourmet was developed during a thanksgiving break by re-using the code base for the product that we will present in the next article.) Once armed with a neat idea, the rush is off to document as much of it as I can before I forget it. Sometimes this documentation is a scrawling on paper that I latter cleanup and scan into a project folder. Sometimes I need to add use cases or a storyboard. On the rare occasion, I will even snap off a quick prototype using a RAD tool.
Once I have documented what I want to do enough that I could explain it to a friend who knows the difference between RAM and network, I note what I have just done in my personal log, and move off to do something else.
The Importance of Pausing the Creative Process
So why stop when you are "hot"? Because most of us must let a vision "cool off" in order to view it objectively. Before work begins, you simply need to determine the relative importance of the project to the other demands on your time, talent, and energy.
Of course, while allowing a hot project to cool down a bit, I often find time to research it a little more. By using the cooling off period to see what has already been done, I could discover another way of doing the project, find a competitor that does it better, or decide upon a better design and / or feature set.
No matter how I spend the cooling off period, the next time that I sit down to push the cause forward (can be hours or weeks latter), I start with reviewing my personal "to do" list by subject to review the ideas. Once I determine both what type of mood I am in at the moment (usually a 3F thing), how much time I have available, as well as what project is likely to achieve my goal de jur, I am ready to start.
Of Wolves and Tools
Once the general direction has been established for a project, it is time to carve the project into steps that I feel that I can accomplish with relative ease. This is where the RUP can become a burden, or a blessing, depending upon how much you need to explore the design and / or communicate your idea to others. In general, the more that your task has in common with other projects, the more able you are to jump right in and do what most of us like to do most (code)!
Because Caliber/RM is an excellent requirement management tool, using it to begin to solidify your requirements is also a great option. If you can't afford this tool, then using the EZLOG / EZBLOG utility that we discuss latter is not a bad place to start either. Whatever tool you use, it is important to categorize your notes by subject, so you can search and review the morass intelligently latter on. Linking ideas together is all about keywords.
Depending upon the type of requirements you write and how much of a code base you have to start off with, it is not unusual for the Lone Wolf to jump right from his or her ideas and requirements to code. Better still, because Borland's tools allow you to extract documentation and re-factor legacy source code, a good deal of your modeling work can be little more than understanding what you have got lying around the den to work with. In general, most Wolves have discovered that the more times you walk a given path, the less time you have to spend thinking about how you are going to get there.
Once you know what you are going to do, then organizing your project into a series of steps is important. Once you have determined the path relationship between those steps and ascertained the critical path, traditional logic says that you are ready to begin developing. However, when working as a Lone Wolf tackling a big project however, I often find that another step is required.
To demonstrate an alternative way to carve up a project for personal success, lets consider the creation of an all-powerful GUI application in your spare time. For example, after inventorying and arranging tasks in their critical order, I often find that I need to optimize the list so that I can see my work progressing. In other words, in order to keep from getting discouraged when working alone, I need build momentum in the project by earning those "howling rights" early on in the project!
When creating a new GUI application, I often find that, while designing an innovative user interface is often important, even the best user interface in the world needs something behind it to deliver the content.
Of course this "magic something" is commonly referred to as an "engine". By way of operational necessity with my personal methodology, I often find that segregating the approach of engine creation into a classical Model, View, Controller (MVC) design pattern is a good place for most work to start.
Figure 1 - Classical MVC
Because a lot of what I do uses some variation of the MVC model above, I often find that beginning work on the model allows me to first capture the essence of what I need to gather from the user and / or system interface. To garner some cheap howling rights.
Once the requirements are known, they form the basis of a critical-path data "model" that I need to host, create, or extract from another resource.
Howling Over the Model
While it is not unusual to tackle a modeling session in short order, it is not uncommon to discover that what I assumed was going to be an easy modeling activity is in fact an elaborate mixture of model and / or view re-use from other projects. To be competitive, you need to review your legacy models and views, as well as those written by the competition!
Figure 2 - Modeling Includes System and Business Objects
When I work as a Lone Wolf, I find that tackling the re-use step is also a great way to achieve some satisfying howling rights. When working for a client, however, the process of identifying subject matter experts, assessing the competition, unearthing related business objects, and discovering / learning how to apply reusable components or technologies can become up from 40 to (in the extreme case) almost 80% of the work.
Tacking the Controller
While many might think that tacking a controller is relatively trivial, the amount of work spent evolving adequate controller(s) for your model(s) will increase as the number of objects, as well as their viewed aspects, increase. So while in the beginning you might limit the design of your controller to be concerned with the location, storage, and access of data to support your hosted model(s), over time the scope and purpose of the controllers can evolve.
Fortunately, most people find that when they have designed their controllers properly, that scaling the application does not require changes to the public interface of the controller or its controlled objects. Indeed, when following this Lone Wolf Methodology, it is not uncommon to be able to discard the user interface entirely.
Whether confronted with the need to migrate your application to .NET, the Internet, or another operating system, I have discovered that the ability to be "user interface independent" can be built into just about any major application at a very modest organizational cost. Indeed, as computing innovation promised to continue onward for the foreseeable future, for years I have been discovering that the ability to build value in your MVC can become the most important part of ensuring that you can migrate your application when the business (not necessarily technology,) needs arise.
The Forgotten Views: Creating Testing and Other Interfaces
Because we all are (or should be) always testing our code is some form or another, we should spend some time up-front ensuring that our tests are preserved for future re-use. In general, we need to be sure that our tests are generic enough to be reused, as well as to ensure that the objects being test always operate according to plan. For this reason, every project should offer a simple, easier-to-deliver interface to test the objects in their native controller. A "Testing View."
While a often seen as a burden, creating and using testing frameworks (or Views) frequently ensures that you catch bugs well before they find their way into the hands of your end users. Indeed, when expressed in terms of earning your howling rights for the day, there can be a real sense of satisfaction when you create a test case that leads to the repair of a feature that you previously "knew" worked properly. For this reason alone, writing test cases can become addicting.
Note: While many might argue that the age of the command line interface is dead, not only do I feel that it lives on for creating robust, testable business applications, but it also can be useful when creating Inter / intranet services and other "neat odd jobs". I will demonstrate the creation of one such tool using this methodology in Part II of this article.
Do you need a "Project View"?
Fortunately or un, we are invariably employed by those who can be much less technical than ourselves. For this reason, we geeks usually need to demonstrate progress on a regular basis if you want to keep employers happy.
Unless you have taken the time to create yet another view of your project, you can feel pressure mounting on you as more and more meetings take you away from more productive work. So unless you can codify a view that can demonstrate how much work you have been up to, be sure to spend more than a little time creating a prototype that relates how well the work goes on your clients behalf.
While simple source code management tools can go a long way to providing end users with a feeling of how well the work progresses, experience has taught that non-technical users seldom avail themselves of this type of project view. So if your employer is non (or neo) technical, then arrange to have another way of informing them of how the work goes. If nothing else, animate or otherwise demonstrate how you are bring a prototype to life over time.
Demonstrating your ability to hit delivery dates makes everyone feel good!
The User Interface
Of course, the user interface is the most important view. As the author of several five star software products, I can tell you that I have spent way too much time agonizing over where to put a button or other graphical component.
While the time that you spend up front developing the user interface will depend upon many factors, I find that creating and testing the other application components first invariably gives me a chance to think about how an interface for my model(s) should ultimately look and feel. For this reason, when working on my own projects, coding the graphical user interface is often the very last thing that I do. Not only does concocting the non graphical "views" ensure that my model is regression testable, but it also insures that my technologies are less dependent upon any given vendor's framework or supporting technology. I have discovered that with a little practice, even graphical conventions (such as list boxes, set views, etc.) can be encapsulated in such a way as to allow a utility interface, or other views, to be approximated (at least enough to support regression testing.)
Weather working alone or in-groups, you need to understand your motivation for working on a project. Understanding why you are doing the work at hand (3Fs) can help you pilot the progress on your project, as well as control the tone of your development activities. This is especially true when you are working alone.
When translating your ideas from concept to reality, the need to decompose a project along functional lines, as well as lines of personal enjoyment ("howling rights"), is often the only difference between project completion, and project abandonment.
Finally, when working for others, the need to demonstrate progress regularly can give you the freedom to do what your enjoy doing most. Understanding the expectation and capabilities of your employers is often crucial to the success of your project.
In part two of this series, I will demonstrate the application of the "Lone Wolf Methodology" by reviewing the creation of a tool that has been designed and developed in a controlled, evolutionary manner to support the concepts described in this article.
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 stand ready to accept your consulting assignments. His web site is Soft9000.com.