Home > Articles > Software Development & Management > Management: Lifecycle, Project, Team

Five Rules for Effective Third-Party Software Development

  • Print
  • + Share This
Leading a well-balanced, professionally satisfying life as a third-party software developer doesn't just happen; it's attained through thought and practice. The Five Rules help you find or rediscover your path to making good code for others competently, comfortably, and profitably.
Like this article? We recommend

Like this article? We recommend

It's a difficult time to make a buck in the software business. Less money is being budgeted for IT projects and more people are scurrying around to get what little money is available. The market is paying less for more. Small development companies that typically charged $100,000 to develop web sites are now charging one third that rate for the same work. Experienced developers in Poland, Hungary, Russia, and India are billing the equivalent of $20 USD an hour to do advanced development work. Layoffs abound and outsourcing is the theme of the day.

It's scary.

For those of us who are third-party developers—the people and companies who make software for the people who make software for the people who use software—things are downright terrifying. In our terror, we do unwise things: We sign onto projects that end up as nightmares, we make price deals that end up as continual money losers. The stress of a depressed marketplace and the pressures of that stress make it hard to resist taking on work for which we're unsuited, committing to unreasonable deadlines, and meeting the unwise and sometimes inappropriate demands of clients. It seems at times as if we want to make a buck at any cost, even if the cost is to drive ourselves nuts and lose money in the process.

Although the situation that I describe above is unattractive and maybe disheartening, it's by no means universal. Some third-party developers do good work and lead balanced professional lives. On a good day, I like to consider myself one of them. These developers seem to observe a consistent pattern of professional behavior, which I describe as the Five Rules for effective third-party software development.

The Five Rules came to me based on 15+ years of experience in the software industry as a third-party developer and observing others in the same line of work. I've worked as an internal developer for a large computer manufacturer; I've worked for a Big Six consulting firm, and I've worked on my own for the last five years. I've seen both sides of the street; I've worked with third-party developers as a client, and am presently a third-party developer myself.

The Five Rules will not completely eliminate from your life the craziness and stress that go with making software. A certain amount of zaniness is just part and parcel of the software industry. If that wasn't true, I doubt that we could have put a man on the moon or created the Internet. In a way, our glory as software developers results from our zaniness. However, the more closely you follow the Five Rules, the easier your life as a third-party software developer will become. The relationship is directly proportional. When the projects I'm working on start getting weird—or I start getting weird—in most cases I've violated one of these very simple rules. The more closely I follow the Five Rules, the better my software, the happier my client, and the bigger my bank account.

If the Five Rules can work for me—a cantankerous, somewhat cynical soul of a software developer—then they can definitely work for you.

The Five Rules

  1. Know thyself, know thy stuff.

  2. If it's not in the spec, it doesn't get made.

  3. Good, fast, cheap—pick two.

  4. Coding time = testing time.

  5. Never forget that you and the client are in it together, for the life of your code.

Rule 1: Know Thyself, Know Thy Stuff

Being part of a project for which you are unsuited or have little real interest (other than making some money) can be a costly nightmare. The best projects are the easiest projects, and the easiest projects are the ones for which a person or company are well-suited—a natural fit, if you will. Doing what you and your company do best is easy and highly cost-effective. Going outside your area of expertise and competence is difficult and costly, for you and your client. Yet, when the phone bill is due, a payment needs to be made on the credit card, or your boss wants you to be a hero "just one last time," your tendency is probably to agree to do work that doesn't feel right, or to convince yourself that you can do work for which you have no interest, qualification, or experience. The temptation to assuage financial insecurity and please the powers that be can be overwhelming and can lead to inaccurate self-perception.

It's in the nature of software developers to believe that we can do anything, regardless of the complexity of the task or the technology required. It's what makes us tick. By the same token, we can easily fool ourselves, and end up pulling all-nighters trying to get something that we thought should work to actually work. The trick is to know what you're suited to do and what you're unsuited to do. Trying to be a square peg in a round hole is a waste of your time and your client's money.

Looking at past patterns can tell you a lot about you and your company. For example, what's the average budget for past projects—$10K, $20K, $100K, a half million, a million? If you're taking on a project that's beyond or below your historic budgetary comfort zone, watch out.

Historically, what's your area of expertise? Has most of your past work been language-specific; for example, in Java, COBOL, or VB? Or have you done mostly "big picture" work—systems architecture and enterprise planning? It's rare (although not unheard of) for big-picture people to be able to do language-specific work effectively, and vice versa. If you find yourself going over into the other camp to make a buck, watch out!

Are you a "front end" person, focused on visual presentation and the science of user interface design, or do you prefer work on the back end? Has most of your work time been spent programming business rules, doing data access work, or working on database administration? Again, it's a rare person who can work both sides of the street. If you find yourself wandering, take notice.

What type of clients have you done well with? Has most of your work been in a formal environment such as a bank or large corporate IT center? Or have you worked with mostly small boutique shops that are more informal in terms of culture and software-development practices? Being the right person in the right environment adds value all around. Trying to get along in a culture that feels uncomfortable to you (and probably to the client) requires energy that you could probably be using more effectively doing other things, such as making software.

Finally, ask yourself, have I done this sort of work before? As a third-party developer, learning a new technology at the client's expense is a waste of the client's time and money as well as a practice of questionable honesty. And, unless you're a person or company of extraordinary genius and unfathomed talent, you'll blow up due to your own ignorance. It's better to be straightforward with the client and offer to help find someone who can do the work at hand. Or accept the burden of learning the new technology as your expense, and don't bill the client for your knowledge acquisition. The worst case is that the esteem in which the client holds you will grow, which is an asset that money cannot buy.

  • + Share This
  • 🔖 Save To Your Account