S9K Training


 

Consulting & Training by Randall Nagy


Randall

Overview

Training

Community

Custom R&D

Soft9000.com

Motivation1

The Tao of the Wolf Pack

How to keep motivated!

03/10/2004 -- By Randall Nagy

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 consume 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.

While this article was written to address the need a small developer team, we should note here that what works for me and you individually usually works for our R&D teams, as well. The only difference is the amount of consensus building that we will have to do. The larger the team, the greater the number of artifacts that we will need to produce to discover, document, and manage expectations.

Both personal and technological reliability and trust also play an important role in aiding or discouraging your project's ability to move quickly. In group situations, the need for product documentation and quality varies in accordance with project visibility.

Keeping Motivated

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!

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.

Hunting Elephants

When tacking a huge project as a Wolf Pack, 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 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 derailed many great projects. 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, defining 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 units of work, we discovered how important re-use is. Finally, when we ensured that our objects readily couple together, we discover the true meaning of software architecture and reuse.

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 requires 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 me keep 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.

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. For this reason, before you begin any large undertaking, you should personally qualify what you want to get out of the work.

For example, whenever I start out on a project, I usually define the mission statement in terms of a trade of between three personal 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 law of 2/3 is interesting enough to spend a little more time understanding. Specifically, we need to review 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 "Fun" theme is easy enough to understand. Unlike fun, 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 Sourceforge.Net. Why? -Because the task of re-hosting my huge labyrinth of personal source code was certainly done more for "fun" than "fame". Indeed, even if I get invited to 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, File Spy, 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" are examples of a pure "Fortune / Fame" evolution. The former software offering started out largely as an excuse to write an automatic content generator and list server to build a user community. As my need to create a tool to do my hobby evolved, the task has clearly shed the former "Fun / Fame" emphasis, as I no longer give the windows database interface portion 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 ("Fortune") 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 Wolf Pack developer for the past 25 odd years or so.

A Common Problem

Many a project comes to me during my more contemplative moments. While these can occur when working, they also come during the off hours. (EzGourmet was developed during a thanksgiving break.) 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 merely 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 so I can explain the project to others.

Once I have documented what I want to do enough that I could explain it to a fellow developer, I note what I have 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.

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 keyword. Once I determine both what type of mood I am in (usually a 3F thing) and how much time I have available, I am ready to start.

Of Wolves and Tools

Once the vision and goals have been established for a project, it is time to carve the undertaking into steps that I feel I can accomplish with relative ease. This is where the "design it all first" approaches 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 lone wolves 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 provided 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 your notes 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 many 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. Here again, what works for you will also usually work for your team.

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 relationship between those steps and discovered the critical path, traditional logic says that you are ready to begin developing. When working as a Lone Wolf tackling a big project however, I often find that another step is required.

Project Organization

To demonstrate an alternative way to carve up a project for personal success, lets consider the creation of an all-powerful GUI application. 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!

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. 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 engine creation into a classical Model, View, Controller (MVC) design pattern is a good place for most work to start.

Figure 1 - Classical MVC

I often find that beginning work on a model the resembles the above 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.

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 own legacy as well as that of 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.

For those who are impressed by the word "modeling", when it comes to creating objects the are going to be used to carry data between an engine and a view, modeling exercises can become very easy. For example, when arriving fresh on the scene to rescue a project from analyses paralyses, I often begin by asking subject matter experts (SMEs) to create a series of paper-based forms to help get the modeling process started. Not only are the forms that they produce usually easy to turn into business objects, but the process of creating these forms help educate me in the nomenclature used in their business domain(s). The rest of the design is usually able to be cobbled together from books like Design Patterns.... While a bit eclectic (you will probably never have to use 80% of the patterns that it describes), it is none the less a good tome to become familiar with.

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 Wolf Pack Methodology, it is not uncommon to be able to discard the user interface entirely.

Interface Independence

For years I have been teaching that the ability to build value in your software can be the most important part of ensuring that you can migrate your application. As computing innovation promised just as much change then as now, you should be prepared to change your product when the business (not necessarily technology,) needs arise.

Whether confronted with the need to migrate your application to .NET, the Internet, or another operating system, I have discovered having previously provided the ability to be "user interface independent" can make the chore take days, rather than months. I have also discovered that this type of flexibility can be built into just about any major application at a very modest organizational cost.

The Forgotten Views: Creating Testing and Other Interfaces

Because we all are (or should be) testing our code, 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 tested 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 controllers.

While often seen as a burden, creating and using testing frameworks (or Testing Views) helps to ensure 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. The more you are in charge of the ultimate product delivery, the more you should want to demonstrate the type of progress required 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 and / or your pack 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.

We should note here that while simple source code management tools can go a long way in demonstrating 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, consider animating or otherwise demonstrating how you are bring a the project to life using a prototype. Demonstrating your ability to hit delivery dates makes everyone feel good!

The User Interface

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.)

Conclusion

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 choose between many projects, as well as govern the overall 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 "Wolf Pack 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

Mr. 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, UTL and more. Either he or his Wolf Pack associates are ready to accept your consulting assignments. His web site is Soft9000.com.

(mod) (mod)