— A Brief Introduction —

If you picked this particular book up off the shelves, it's likely that you either make a living as a programmer or plan to do so in the future. Of course, you could just be shopping for something that's precisely the right thickness to prop up your rickety coffee table, but we'll play the odds for the moment and assume that you spend more time in front of a debugger than you do a television. The first questions we typically have when looking for technical books relate to platform and language. What kind of computer? What flavor of operating system? Which particular set of languages and technologies must we know to benefit from this book? For The Career Programmer, it just doesn't matter. Whether we make our living under the flag of Mac or Microsoft, mainframe or mini, our ultimate goals and desires are the same: all we really want to do is make good money, spend our days writing the next killer app, and get our pizza delivered in thirty minutes or less.

However, for those who possess the ability to turn screens full of cryptic statements into state-of-the-art software systems, there's only one slight complication. In order to get paid for doing what we love, we find ourselves working deep in the heart of Corporate America. Nothing we were taught in school prepared us for the illogical, inconsistent, and sometimes downright silly business practices that are the norm in software development shops both large and small.

For instance, deadlines are declared in an almost arbitrary fashion, with no real consideration of what's involved. We're expected to produce specific functionality from vague and ever-changing requirements. We're given little to no time for proper analysis and design, and, when we ask management about hiring professional testers and setting up a QA process—well, I've seen deer in my headlights look less stunned. Internal politics are rampant, threatening everything from our current project to our staplers, which for some bizarre reason seem to be a precious commodity in the cubicle world. In short, from a software developer's point of view, the environment makes no sense. Unfortunately, no matter how unrealistic the deadline, we're expected to work day and night to make it happen, only to have the product shipped with less than fifteen minutes of testing. Care to guess who's going to get yelled at the first time it blows up in the field? I can assure you, the deer have leapt safely out of the glare of the headlights and there's nobody here but us programmers.

Anyone who hasn't worked in our field will by now have labeled me quite the cynic, but I suspect you were shaking your head while reading the last paragraph and remembering the insanities of your own company's releases. As passionately as we want to do good work, it seems that we're checked at every turn by corporate bureaucracy and management that can barely spell the word computer, let alone manage a software development process. Of course, we learn all of this the hard way. All of the books on the bookstore shelves teach us how to program, not how to fend off the lunacy of the business world so that we can actually program and deliver excellence.

That's why I wrote this book. I've spent the better part of the past ten years as a mercenary. For the uninitiated, that's a contract programmer, and it means that I've seen a lot of shops. Over the years, I've learned some tricks to help take control of my programming life again, along with how to further my career in general. (I do like to eat well.) For a long time now, I've been working exactly the kinds of jobs that I like, doing the techie stuff that I enjoy, concentrating on the coding, and actually delivering on schedule, not to mention getting paid well in the process. Much of what I know as a programmer I've learned from other guys who were nice enough to share their experience, and so this is my way of giving a little back. No matter where you fit into your project, you can learn some tricks from this book to help simplify your life and get you back to concentrating on the code. That's the best thing I can think of to give to a programmer.

Assumptions about the Reader

I assume that you already know how to program and that you either currently make your living programming in the business world or soon will be. The platform or language you work with doesn't matter. This is a book about overcoming the obstacles we encounter as programmers in the real world, and these obstacles are the same regardless of what type of software you write. It probably goes without saying, but I also assume that you rail against any and all limitations that you encounter on the job and that you find anything that interferes with your ability to deliver high-quality software extremely frustrating. That's where I hope to help.

Who Should Read This

The issues addressed here affect developers at all levels. If you work as a project manager or team lead, you're already a veteran of many battles with management and are always looking for new ways to talk sense into these guys. If you're a front-line programmer, you're the one who ultimately has to pay the price for bad decisions further up the food chain, whether it's from the Suits in the front office or your own project manager. The tactics and techniques work at both levels. If you're not happy with the way things are run and want to change your job so that you can focus more on software development and less on damage control from dubious decisions, this book is for you.

A Note to Women Who Code

Not everyone who stays up for three straight nights chasing a bug is male. Many women also make a living as professional developers. When the fingers hit the keyboard, it doesn't matter if the nails are polished or not. The compiler doesn't care and neither do I; good code is good code and none of the topics I cover are gender specific. However, the English language simply does not have an easy way to address both genders in a conversational manner. While I applaud the sincere intentions of those who insert a “his/her” or “he/she” into everything they write out of consideration for equality, in practice it can make the text a bit tedious to read.

I'm no Nobel laureate. I'm just a programmer, and I write like I talk. Although the issues we'll cover are serious ones, my priority is to keep this a light, conversational, and easy read. I'm more interested in helping people overcome the many obstacles to good software that Corporate America continually throws our way than I am in being considered a scholarly author. Therefore, to keep it simple, I made a conscious decision to speak to a single gender for the sheer literary convenience of doing so. Because the programming community is overwhelmingly populated by the male of the species, you'll see references to “he” and “him” rather than an attempt to speak to both genders in every sentence. If this is perceived as a lack of political correctness, I hope that the easier flow of words and the matters upon which they touch will compensate. This is a book for programmers. The specifications of your particular body are irrelevant.

What's Not Addressed

This is not a language or technology book. No matter what programming technique you want to master, plenty of books are available to teach you. This book is about overcoming the obstacles you face on the job that ultimately result in release disasters, stressed-out development experiences, software death marches, and bad software that could have been good. It's not a treatise from the ivory tower of academia. It's a field manual for the software developer grunts who relentlessly toil away in the thick of it, day after day.

What This Book Brings to the Party

If you worked in a perfect world, you'd have plenty of time for gathering requirements, for analysis and design, and for implementation and testing. You'd also be in charge of what went into the product, the overall design, and which technologies were used, and you'd release it when you were darned well ready. Management would not interfere, and you wouldn't have to contend with any office politics. Everyone would listen and do things exactly as you suggested. Small, furry creatures from Alpha Centauri would be, well, you know. If you live in such a world, go ahead and use this book for that wobbly coffee table. Oh, yeah, and save me a seat. I'd love to have a job there. For the rest of us, this book is a collection of very simple and practical observations and techniques for putting us in as much control of the development process as the real world is going to allow. A number of hurdles must be cleared when shipping a good product, and some of these can be handled by modifying the approach we take to design, estimating, and other matters of process. Other issues result from bureaucracy and politics. No design methodology in the world is going to help you there. The higher-ups tend to ignore the opinions of programmers partly because we've never learned to speak their language or communicate in a way that is meaningful to them. Consequently, our thoughts and suggestions—the very things that could save our projects from disaster—are ignored even though we're the specialists. Before we can show them how we'd like to do things, we must first acquire the skills necessary to make them hear us. In short, we need to learn how to manage our management so that we can get back to doing the job that we love.

You don't need an MBA to figure this stuff out. You just need to pay attention to how things work and modify your approach to one that is realistic and effective in your environment. The bottom line is simple: whether we agree or disagree, more often than not we're simply told to get the job done in the time we're given, or else. Consequently, the approaches that work when we have the luxury of time fail utterly when we have the ability to implement only a quarter of the process. In such moments, we need simple and practical approaches that get the product delivered.

In the chapters that follow, I'll be addressing these issues with the assumption that you don't have time for the perfect solution. That's why I refer to them as guerilla tactics. They're direct, effective, and they're not always pretty. These tricks are all taken from real jobs with real pressures. When you have to deliver, or else, neatness just doesn't count. Getting the job done is all that matters.

A Quick Peek at the Chapters

Here's a look at the rest of the book. Part I explains the problems prevalent in our jobs, and Part II speaks to the issues and their solutions.

Part I:Software Development in an Imperfect World

Chapter 1: Welcome to Corporate America

After landing their first job, many programmers are shocked by the reality of life in the corporate world. Your initial dream of sitting undisturbed each day, kicking out clever little apps, is continually disturbed by unrealistic deadlines, unreasonable decisions, bureaucracy, politics, and crisis after crisis. Any of these could reduce your current software project to a pile of smoking rubble reminiscent of the latest Godzilla movie. They don't teach this sort of thing in school, and even seasoned developers have difficulty knowing how to cope with elements that seem beyond their control.

Chapter 2: Business is War.Meet the Enemy.

To successfully deliver the next killer app, you must fight many battles, the easiest of which is with your debugger. Whether you're a systems architect, project manager, team lead, or full-time coder, your ability to do your job and enjoy your pizza without indigestion is going to be continually assaulted by a host of business-induced problems. The first step in building up your defenses is simply knowing your enemy. Consequently, we'll highlight the problems that most software development teams commonly encounter.

Chapter 3: Good Coding Skills Are Not Enough

In gazing at the enemy, it's tempting for many programmers to simply shrug off management problems as not being a part of a programmer's job description. However, this will be of little consolation to you when you're plucking the arrows out of your posterior. Software development is a team endeavor. If you don't work at your level to help combat the problems that threaten your project, you'll all go down together. If you don't do anything but code, here's why you still need additional skills to survive.

Part II:Guerilla Tactics for Front-Line Programmers

Chapter 4: Preventing Arbitrary Deadlines

It's three o'clock in the morning, your system just crashed again, your debugger shrugs its shoulders and asks for a coffee break, your eyes are so bloodshot that they look like a roadmap of midtown Manhattan, and the product must ship tomorrow if you wish to continue your employment. How did you get into this mess? At this point, there's not much you can do about it beyond persistence, excessive caffeine consumption, and simply hoping for a lucky break. The time to prevent this disaster was much earlier in the game. Where's a good time machine when you need one?

Chapter 5: Getting Your Requirements Etched in Stone

Scope creep is not the title of a bad science fiction movie involving mutant gunsights from outer space; rather, it's one of the foremost reasons that software projects are not delivered on time and within budget. If your features seem to continually evolve as the project progresses, or you find yourself trying to provide well-defined functionality from vague specifications, here's how to nail your requirements down firmly, right at the beginning. If they wiggle, use another nail.

Chapter 6: Effective Design under Fire

The only problem with many design methodologies is that it takes a significant time investment to work through the entire process. Unfortunately, out here on the front lines, we typically have a hard time convincing management that we need a little time away from the compiler for sleep, let alone for months and months of abstract drawings that they don't understand. Consequently, at such times we must break the rules and roll our own design approach, using the best of all that we've encountered in the time we're given to work with. It ain't pretty, but it works.

Chapter 7: Practical Estimating Techniques

Arguably the hardest thing to do in our business (beyond finding pizza toppings that everyone agrees upon) is producing an accurate time estimate for any nontrivial amount of code. Furthermore, many unrealistic deadlines arise due to overlooking tasks other than coding that also eat up chunks of time. In the end, if the estimates aren't real, it's the programmers who pay the price at deadline time. Here's a simple approach to help ensure that your next timeline is an achievable one.

Chapter 8: Fighting for Quality Assurance

No programmer worth his weight in cappuccino ever wants to ship a buggy product. It's bad for the ego, bad for the résumé, and bad on the nerves when your telephone rings in the middle of the night. Amazingly, however, the overwhelming majority of businesses who develop software do not hire quality assurance professionals or otherwise institute any sort of rigorous software testing procedures. This calls for a combination of fighting for change and exercising self-defense wherever possible.

Chapter 9: Keeping the Project under Control

Keeping a software development team running like a well-oiled machine takes work from people at every level. Code standards, version control, technical documentation, organization, discipline, and good communications are but a few of the skills required to keep a project on track. It matters little that you've prevailed in your political battles if your project simply implodes due to poor structural integrity. From programmer to project manager, here's how to keep things running smoothly.

C