Chapter 11

This chapter is a bit different from the rest of the book. For one thing, I'm going to change the point of view of the writing from the impersonal to the first person. While I've tried to give an objective presentation of the material up to now, this chapter represents my own subjective view of programming.

Even after programming in one form or another for 30 years, I still find programming a fun thing to do. I'm still doing active development on my own open source projects, the V C++ GUI Framework and VIDE. I'd like to extend the Wmvc framework I used for this book.

Over the years, I've programmed in many languages, including some you've probably never heard of. The main languages I've used include Fortran, Ratfor, Pascal, C, PDP-11 assembler, Intel 8080/8086 assembler, C++, and Java. Of all the languages I've used, I find I like C++ and Java the best, mostly because they are object-oriented. There have been many new programming ideas developed over my career, but object orientation has been the most significant. Besides the real benefits of how easy it is to maintain object-oriented code, I just find it more fun to design and program with objects.

I've been involved with programming at many levels. When I was at Sandia National Labs, I worked with on a very large project with many programmers and layers of management. When I started my first personal computer software company, I learned how important it is to write software that will work on different computers (Microsoft was just one of many small companies back then), and that work correctly for paying customers. My years with the University of New Mexico taught me how to teach others about programming. My favorite time was that spent with my company, Reference Software, working to build a great team of programmers to develop our grammar checker and other reference software works. And the past few years, I've tried to give something back to the software community, first by developing open source software, and now by writing this book.

In this chapter, I will cover some of the things I've found important for developing great software. Some of these are important programming principles, some simple tips or guidelines, and some a matter of philosophy.

I've divided this chapter into several sections. The first section, Programming, is about day-to-day programming - how to write code. The second is about using tools to make your programming efforts easier and more productive. The next section is about the programming work environment, and how a good work environment is critical for developing good software. And finally, I'll cover how to use some of the many resources available today to enhance your programming skills.

Programming

This section covers some practical aspects of actually programming. Some of these topics are really about programming, some are more philosophical. All are principles I have found important for writing better programs. Some of the issues apply both to a personal productivity level, and to a workplace level, and I'll cover them under both categories.

Your Code Never Dies

I have found the simple realization that Your Code Never Dies has a profound effect on just how I program, perhaps more that any other single factor. It is true. No matter how small, how trivial, or how temporary you think a piece of code might be, almost without fail, you or someone else will see that code again sooner or later. Now, depending on how you use this revelation, that can mean the code can come back to help you or to haunt you.

One of the best examples I can think of personally is an editor I originally wrote in 1980. Partly because I didn't like the editors available on the VAX computer I was working with at the time, and partly to really learn how to program for that VAX, I decided to write an editor. I wrote the first version of the editor in a language called Ratfor, which allowed you to use C syntax to write Fortran programs.

The editor worked well, and I've used it as my editor of choice ever since. Well, before long, I moved to a different computer and operating system. The first thing I had to do was move my editor to that machine. Before long, we switched to C instead of Ratfor, so I translated the program to C. Then I changed jobs, and took the editor with me.

Over the past 20 years, this editor has followed me everywhere I've gone. It has undergone many transitions. First, from Ratfor to C. Then modifications to make it work on different systems with different terminals. Then to support a graphical user interface. Then to C++. And so on. Today, you can still see remnants of the original Ratfor code in the source for my free V IDE. And I'm still using it, still modifying the code, and still finding bugs. Back in 1980, I don't think I possibly could have imagined that I would still be using and modifying descendents of that code in 2001.

The same can be said about the millions and millions of lines of code that had to be reviewed and fixed for the millennium. If all those programmers who had originally written this code thirty, twenty, or even just five years ago had believed that their code would never die, perhaps many of the problems associated with Y2K could have been avoided.

Remember, eventually someone (and it might be you) will have to modify the code, which means they will have to understand it. So, write clear, logical code. Choose good names. Comment thoroughly and appropriately. If you had to look something up to use a library, for example, then a comment will help.

Write the best code you can. Take pride in it. You will get a great feeling when someone later tells you that they were impressed with your code quality.

Don't write quick and dirty code. You might think you'll remember what you've done, but you won't. Even after a few months, let alone years, your own code might as well have been written by someone else. So when you write code, remember you will have to see it again, and you won't remember what you were doing the first time. Give yourself a break.

While you can use refactoring later, it is easier to get it right when you are creating the code the first time. This doesn't necessarily mean you have to write perfect code while you are still working on it and figuring out how to make it work, but you should refactor and fix code before you consider it finished.

Program With Style

If you know you are writing code that others will read, then it becomes important that you write your code with style. Style is more that having good data structures, or using good algorithms. It is making code that is both easy and inviting to read.

If you read a good textbook, for example, you will find it is more than just a collection of words and sentences. It will have a definite style to it. The first page of each chapter will have a specific and consistent design. The chapters will be broken down into parts or sections that also follow a design. There will be a consistency as to how the pages look, how the figures are arranged. There will be conscious use of whitespace to make the book easier to read. There will be a significant degree of artistry that has gone into the design of the book.

The same should be true for computer code. Many programmers try to cram as much code into as small a space as possible. This is not good programming. You should use design principles when laying out your code, just as is done when a book is printed. One thing that many programmers don't seem to realize is that liberal, but deliberate use of whitespace can make a program much easier to read¹. The following are some of the layout principles I find important:

Know What You Are Doing

It really does help to understand what you are doing. Take the time you need to understand the problem, the computer, the programming language. For example, it really does help you program better if you understand shallow vs. deep copy or how the Java runtime works. It does help to look at Swing with object-oriented eyes.

Write Practice Programs

Whenever I move to new system (a new operating system, a new programming language, a new GUI, etc.), I spend a week or two learning about it by writing a few practice programs, or getting some program you've worked with before to run. I can't really count the number of times the first thing I did when moving to a new system was to get my editor working on that system.

When I'm moving to an environment when that wouldn't work, I try to get a few simple programs working. It is important to get a reasonable understanding of the tools (editors, compilers, etc.) available with the new system, as well as how it works. Once I have the basics down, I can move on to something real.

Practice Incremental Programming

Whenever I am creating new code, I practice what I call incremental programming. I always add the very least I possibly can, test it to be sure it works, and then move on to the next step.

For example, when I add a new class to a system, I will just create the bare outline of the class, perhaps with a few stubs for methods, get that basic outline to compile and link. Only then to I start to add functionality. I will do that one feature at a time, and in as a small of an increment at a time as possible. After I add each feature, I will test to see that it works as it should, and that I haven't broken anything else.

By adding one small feature at a time, you can minimize the time you spend debugging. Because you will know just what part of the code you are changing, you will usually be able to know just what part of the whole program you are affecting, and can usually find out what went wrong easily without needing to resort to using your debugger.

The Tools Matter

It is important to find just the right set of tools that fit your own style. I personally still find I'm most productive using a Unix style development environment. This means a good set of separate tools - an editor, a compiler, a debugger, and some other software tools like CVS and grep. Other programmers thrive with a full featured IDE where all those tools are available from one interface.

Just which tools you use is much a matter of personal style. I like to do things my own way, for example, and I find the flexibility of separate tools makes this the easiest. I find that using a big, full-featured IDE takes a great deal of overhead to learn to use effectively, and then it will likely to thwart how I like to do things anyway. Others find just the opposite, that a big IDE makes their life easier.

The important thing to realize, however, is that the tools really can make a difference. You should take the time to try using different tools, and use the ones that work best for you. Just because someone hands you a big Java development tool that they think is the way to program Java doesn't mean that it is best for you. Investigate the alternatives.

Objects Really Help

Object-oriented programming really is more productive. If you have well-designed objects, you will be able to confine changes to just an object, and the objects that use it. This is ideal for the incremental programming I discussed earlier.

Testing

Most of the testing I do is unit testing associated with the kind of incremental programming I tend to practice. When I'm first developing a new class, I will usually write a driver program first, which really is just a test for the new class. As I add functionality to the class, I can use that driver to test the new features. With the cycle of add one thing, test that thing, I find I can produce lots of working code quickly. This is not that much different than the test/code cycle of eXtreme Programming.

Debugging

Since I've been doing object-oriented programming in C++ and Java, I've found I very rarely use a debugger. Every so often, especially when using a library or framework, I find I need to resort to a debugger, but that isn't often. Debuggers can also be useful when you are integrating different components of a bigger project.

When I'm working on a specific section of code, I find that incremental programming makes debugging trivial. I know what I've just changed, so I know where to look when something breaks.

When I can't find a bug, however, a debugger isn't necessarily the best first step. One of the best ways I've ever found to track down a bug is to try to explain the code to another programmer. Just going over the code with someone else will uncover the bug with surprising regularity. Try that first.

The very nature of objects means that it can also be very informative to put trace print statements in object constructors. With Java, you can run your programs from a console, and print useful information whenever an object is constructed. This will often show exactly what you need to find out.

When you do need to resort to a debugger, it is important to understand just how the program is supposed to work. It is difficult to know just where to set breakpoints, or what variables to watch unless you know what the program should be doing.

I also have one critical rule to follow when debugging. As you debug and try things to fix the bug, change only one thing at a time. As you go over the code, it is often tempting to change another thing or two before you recompile and test again. Resist. If you change more than one thing in the code at a time, you will not know for sure which change fixed the problem, or if you've introduced yet another bug in the process.

Don't Reinvent the Wheel

A lot of programming problems have already been solved. Try to avoid reinventing a solution to a problem that has already been solved. There are textbooks with algorithms. There are design patterns you can use. There are libraries and frameworks that can solve the problem with minimal work on your part. The goal is to minimize the work you need to do reinventing what someone else has already done.

Sometimes It is Better to Do It Yourself

Even though you want to try to avoid duplicating existing work, sometimes you have to. The existing solution you find may not do just what you need, or it may even be more difficult to use than just starting from scratch. Sometimes it is important to know when to give up and do it yourself.

There is one trend in software development that sill makes me a bit uneasy, and that's the development of tools for automatically generating GUI interfaces, especially for Java. This is a feature of both Forte and JBuilder, for example. While these tools can be really great for exploring various user interfaces, I worry about two aspects of them.

First, you are locked into the structure of the code they generate. This means that if you want your code to have a particular organization or design, you may have to bend it a bit to fit the GUI code generated by the tool you used. And while the code generated by such tools isn't necessarily bad, it will always be generalized to fit the requirements of the tool, and not necessarily easy to modify or understand.

Another problem is long term support. For example, while Sun is currently supporting Forte, there is no guarantee that in a year or two market conditions won't force Sun to drop Forte and switch to a new product. If that were to happen, then anyone who had relied on using Forte to build their user interfaces might be out of luck.

So, while rapid GUI designers might be great for prototypes, it is probably better and safer to build your own GUI code, or at the very least to use only open source tools. This applies to almost any kind of automatic code generation tool.

You Can Get Ideas Any Time

Over the years, I've discovered I have some of my best programming ideas either while I'm in the shower, or right when I first wake up in the morning. While you are intensely involved with a programming project, you are likely to find that good ideas can pop into your head at almost any time. I have found it very valuable to be prepared for such occasions by having a small spiral notebook always nearby. I can then write down my ideas right away before they get away, and then review them later when I get back to programming. I still haven't figured out how to always read my own scrawling, however.

Keeping such a notebook can be useful for other aspects of programming, as well. You can keep meeting notes in it. You can write down trivial details of the installation process of some software product. While handheld organizers are great for many things, sometimes a plain old notebook is still best for writing down rapid notes.

Get A Life

I really like programming. When I get on a roll, I can become totally oblivious to what is going on with the rest of the world. But only up to a point. Then I have to do something else.

I've known programmers who got so wrapped up in their job that they were missing out on the rest of the world. While some employers might like this kind of programmer, it is very important to get some kind of life away from the computer. I have found that programmers who have a life outside their jobs end up being great and productive programmers for years, while those whose life is programming will burn out.

Sometimes, however, you do get on a roll. You will be turning out code at an amazing rate, and it all works. These times can happen infrequently. If possible, you should take advantage of being on a roll. But don't overdo, especially to the point of ignoring your friends or family. These rolls usually only last a week or so, so beware if you are letting them go on too long.

A Plan Matters

Master programmers who have been programming a long time can sometime program by feel. Their experience tells them just what approach to take solving a problem and how to write the code. Unfortunately, there just aren't that many programmers with that ability available. For the rest of the time, it really does matter to have a plan.

Taking the time to understand the problem, analyze the requirements, and do a proper design really pays off. Using the talents of a master programmer to help make the plan can be especially productive. Once a plan is ready, then all the programmers involved will be more productive and the resulting product will be better. While the up front planning may not be as much fun as actually building a product, the effort will pay off.

The Tools

As I said in the last section, your software tools really do matter. They can make you a more productive programmer while making the programming task more enjoyable. In this section, I will discuss a bit of what I believe about software tools.

Your Editor Really Matters

While you are actually programming, you will spend a whole lot of your time in your code editor. Hardly any other programming tool can invoke more ardent feelings and discussions than an editor. Which editor you use really does matter. You should know about the alternatives, and be able to use the one that best suites your work style.

Know About the Time-Tested Tools

Many experienced programmers find that Unix-like programming environment is still the best. Today, Linux is probably the best place to experience the Unix-like environment, although there are versions that work on Microsoft Windows.

Know About the Latest Tools

While the many of the standard software tools have been around for years, there are new ones being developed all the time. This has been especially true with the rise in Java's popularity. There have been many tools developed specifically for object-oriented development, and for Java development. Some of the newer tools are available in free open source versions, but most are commercial products. I already covered some of these in the last chapter. Here is a list of the latest software tools:

Tools Go Away

Software tools can really enhance a programmer's productivity. There is one significant problem with many tools, however, especially commercially developed and marketed tools. Market forces change, and companies go out of business.

Remember, your programs will never die. Unfortunately, companies, methodologies, and even programming languages do. There will always be a certain amount of risk when using the latest software development technology. While this risk shouldn't stop you from using the latest and greatest, your plans should include contingencies for such unfortunate events.

The Work Environment

Even though the Internet has given many programmers the opportunity to do at least some of their work at home or on the road, most programmers will still work at some kind of office, usually with a group of other programmers. The work environment can radically effect how productive programmers are. In this section, I'll touch on a few things I learned about just how important the work environment is.

Most of the time, I talk from the perspective of management because these are the policies I tried to follow when I was a manager. Some of these just seem like common sense to me, although they aren't practiced by many companies or managers. However, I've found these concepts and practices to be true, and to help keep programmers productive.

If you, as a programmer, work at a place that is not pleasant, or follows policies that don't take into consideration the special abilities and needs of programmers, then you should try to convince your boss that policies like I outline here really work, and will result in more productive programmers.

A Happy Programmer is a Productive Programmer

The most important thing I've found is that a happy programmer is a productive programmer. Thus, whenever I've worked with a team of programmers, I've always tried to create a work environment that is not just pleasant, but fun. This is not necessarily easy to do, but I've found that following these principles can help create a great environment for programmers.

Physical Environment

The physical environment is important. This includes not only the physical building, but the computers and software tools needed for programming.

I personally find that a private office with a door that is usually open, but can be closed, is important. The usual policy it to try to keep your door open to invite spontaneous and casual conversation, but to be able to close it when you need to concentrate.

I think that open cubicles are too public and too noisy for programmers. They can work for support people, such as a testing group, but don't allow the quiet concentration programmers sometime need. If the physical space or company finances don't allow for individual offices, then the cubical space must allow for as much privacy as possible.

Extreme Programming is an exception to this. XP calls for pair programming in a shared common space. However, XP also calls for quiet, private space that programmers can retreat to when necessary.

Programmers should also have up to date equipment and software. Spending a few hundred or even a few thousand extra dollars for tools for a programmer you are paying a salary of many thousands of dollars makes sense. Keeping the software and equipment up to date will help maximize productivity.

Flexibility

Once you give your programmers a good work environment, you then have to give them as much flexibility as possible in how they do their job. I've found that if you give your programmers the respect they deserve, and give them flexibility in how they work, they will reward you by giving back their best work.

40 Hours

Programming is a creative and mentally intensive task. Expecting programmers to work more than 40 hours a week on a regular basis does not work. Eventually they will burn out and become much less productive. I find it very significant that a 40 hour workweek is a major principle of eXtreme Programming.

The Team

The importance of teamwork has long been known in sports. Having a great team of programmers who work together well is also important for software development. Not only does a great team produce great software, the team members come to count on each other, often both professionally and personally.

The work environment should encourage teams to become close and work together well. This includes putting team members close together in the workplace. It can also include less tangible things like making things fun. This can include encouraging the team members to have lunch together, and providing social get-togethers. If the company is small enough, these activities can extend to the entire company.

Marketing Matters

When a company produces a product that it sells to a large customer base, it will no doubt have a marketing department. Conflicts between the marketing department and the development department are legendary. The fact is, the efforts of the marketing team are just as important to the company's health as are the efforts of the programming team. Both sides must learn that they really need each other.

Marketers must accept realistic time estimates from the developers. At the same time, the developers must listen to the marketing team. They often know what the ultimate customer wants, or at least what will make the software product most valuable in the marketplace. And the developers must give realistic estimates of time frames. They shouldn't pad the estimates, and if marketing has some fixed date it needs for a release, then the developers should tell marketing what they can reasonably deliver. And marketing should listen. With mutual respect, the whole company will profit.

Keep Up To Date

A company needs to do everything it can to keep its programmers up to date. This means providing access to training, sponsoring trips to relevant conferences, and providing the latest in proven hardware and software technology.

Share the Struggle

While I firmly believe that all the practices I give in this section will result in increased productivity, I also know that sometimes reality intrudes onto these ideals. Companies, especially new startups, have financial constraints. It can be a real struggle to come up with the financial resources to pay a competitive salary, hire all the programmers a project really needs, and have a great physical facility. Sometimes you just have to struggle through.

I've found it is important to avoid secrecy and to share the struggles that the company is going through with the employees. All the employees, including the programmers, will understand, and even work harder to help keep the company going. If you respect your employees, and compensate for tough financial times by giving them extra flexibility or extra incentives such as stock options, they will come through for you.

Let Programmers Help Make Policy

Management needs to respect the programming team. One way to show real respect for the programming team is to let the programmers help make policy. This will include policy on thing like the development environment used. It means that if the team says they would be more productive by switching to XP, for example, then management should respect this view. Give the programmers a voice, and then trust them to come up with the best way to develop code.

Let Your Boss Know What You Need

Just as management needs to let the programmers help make policy decisions, programmers need to let management know when things aren't working or when they could be better. Tell management that 50 and 60 hour workweeks are counter productive. Tell management about object-oriented programming. Tell them how to let you be more productive.

The Reference Software Story

All this happy programmer stuff really does work. One of my favorite stories is about the Reference Software development team I built. Reference Software was a bit unusual in that the sales, marketing, and tech support was located in San Francisco, while the biggest software development team was in Albuquerque. Both locations had a company policy of keeping the workplace fun and flexible. We did almost everything I've mentioned here - flexible hours, part-time work, a quality work place, good equipment and software, and team building.

One of the biggest traditions we established was a monthly Friday lunch for everyone who wanted to come. We would get a big table at a local restaurant, and everyone would have a good time. This simple monthly activity served to renew contacts, and rejuvenated everyone's spirit. This really was a great team builder.

This is not the end of the story. WordPerfect bought Reference Software in 1992, and for some time kept the team mostly intact in Albuquerque. But business being what it is, most of the employees were given the chance to move to WordPerfect's home office in Utah, and the Albuquerque office was closed. Most of the people found new jobs and stayed in Albuquerque. However, closing the office did not end the monthly lunches. For several years after the office closed, the tradition continued, and many of the team's members continued to have the monthly lunch. I hear that some of the people still get together occasionally to this day.

I think there is a lesson to learn from this story. If you create a comfortable work environment where everyone respects each other, and where everyone is happy and likes their job, you will end up with a group of truly productive software developers who become part of a real team. That team can become so strong that even closing down the office won't break the social bonds that were created.

Programming Resources

Finally, I'm going to discuss some of the resources that are available to help improve your programming skills. It is important to keep up with the state of the art. Not only will this keep you productive, it will keep your job interesting, and give you opportunities to use your skills in new circumstances.

Use The Web

The World Wide Web is one of the most important resources available to programmers. If you need the latest information about some programming challenge, or you want to keep up with the very latest trends and discussions, then the Web is the place.

Watch Out for the Web

The Web can be too good. There is so much information, that it can be overwhelming. It is very easy to follow an interesting side path on some topic that is not relevant to whatever you were looking for to begin with. And there is plenty of junk on the web, too. So be careful. If you can't find the information you need quickly, don't waste more of your valuable time following dead ends.

Use Open Source, If You Can

Open Source software is a valuable resource. There is some very high quality free software available, some which can probably help you on your current project. But the same warning applies: there is a lot of junk, and a lot of software that won't quite match what you really need. Don't waste effort trying to track down some free or open source software when it would be more productive to use a commercial product, or to develop the code yourself.

Other Programmers

One of the most important assets available to programmers is other programmers. There is nothing like experience to improve a programmer's skills. One of the best ways to improve your own skills it to work with a more experienced programmer, and to learn from them. This spread of knowledge is part of why code reviews and team programming work so well.

Web Sites

There are an amazing number of web sites available with great resources. Other than the fact there is a lot of poor information available on the web, there is also the problem of longevity. If you make a bookmark list of useful resources, chances are that within a few months or a year, that a large percentage of the bookmarks will no longer be valuable.

Rather that give a list of useful web sites here, I've set up a list of useful links on my own web site (www.objectcentral.com). I hope my links will be around for a long time, and will continue to be a resource for my readers. So check out my web site, and follow any of the links. There will be a special link for information related to this book.

Unfortunately, because of the limits of the page size of this printed book, I haven't always been able to format the code examples in this book the way I'd like to. I have tried my best to make the examples look good, and have kept my braces on lines by themselves.

The Essence of Object Oriented Programming with Java and UML