Creating My Own Personal Hell

In today's excellent post, Jeff Atwood blogs about the classic development process mistakes. He provides this handy list, which I will blatantly repeat here:

People Mistakes	Process Mistakes	Product Mistakes	Technology Mistakes
Undermined motivation Weak personnel Uncontrolled problem employees Heroics Adding people to a late project Noisy, crowded offices Friction between developers and customers Unrealistic expectations Lack of effective project sponsorship Lack of stakeholder buy-in Lack of user input Politics placed over substance Wishful thinking	Overly optimistic schedules Insufficient risk management Contractor failure Insufficient planning Abandonment of planning under pressure Wasted time during the fuzzy front end Shortchanged upstream activities Inadequate design Shortchanged quality assurance Insufficient management controls Premature or too frequent convergence Omitting necessary tasks from estimates Planning to catch up later Code-like-hell programming	Requirements gold-plating Feature creep Developer gold-plating Push me, pull me negotiation Research-oriented development	Silver-bullet syndrome Overestimated savings from new tools or methods Switching tools in the middle of a project Lack of automated source control

I was horrified when I saw that list. I've seen it before, of course, being a big fan of Steve McConnell's works. But seeing the list put there like that, so succinctly, gives me this sinking feeling in the pit of my stomach. I think the project I'm on is guilty of almost every one of those. The problem? I'm the sole developer on it (admittedly, however, not by choice).

I was thrust into this project from day one with a completely unrealistic schedule, no requirements, no goal, no vision, no contact with the users, no management team, and no freedom of movement in the tool selection. When it comes down to it, I have to fill all the roles in the project: I have to be the DBA, the software engineer, the business analyst, the architect, the web designer, the project manager, the customer support representative, QA engineer, the risk manager, the technical writer, the release engineer, and the software developer.

I get paid to be the software developer. It's my job title. I'm not particularly very good at much else; I slog my way through the rest of the roles. In three years, I've been pulling my hair out to delivery *everything* related to the project, and as a result, every facet of the project has suffered. The code quality has never been what I would have liked it to be. In this particular case, the old adage, "Jack of all trades, master of none," has certainly proved to be true. My inability to specialize in my chosen field has prevented me from being able to deliver code of a superior quality; instead, I've delivered substandard products across the board: code, product, documentation, and customer service.

Our process is haphazard at best. I am constantly rushing to get the builds out according to a quarterly schedule. The customer seems to want to get the builds as quickly as possible. I never have time to fully regression test the builds. The customer wants to constantly shortchange the testing time in order to get the builds in their hands. So, I get them the builds when they want them, giving them the caveat that I *know* there are bugs in it. I ask them to fully test the build from end to end. But they never do. They find a handful of bugs and throw it back to me, insisting that the bugs they've found must be fixed before they will continue testing. The company will not hire a QA or testing staff because they believe that I can do it all. So I have to stop my work, resolve the handful of defects the customer has found, and rush that bug fix build out the door. Again, the customer wants that build as quickly as possible--without sufficient time allocated to me to regression test it. So I give it back to them, and they shortchange their own testing again. And the cycle repeats itself.

The customer seems to think that the entire problem rests at my feet. Perhaps it does. I don't know. I'm just tired of being shortchanged on the testing time, the lack of hands to help with the testing (even if it's temp assistance), and the proper prioritization of testing in the development process. You CANNOT shortchange testing in software development. The number of defects in this project has soared out of control because the customer will not allow me to take the time to test it fully, nor will they fully test it themselves.

Each time they get a build, they insist on getting an update to the test scripts, which I dutifully try to update--but they don't give me enough time to complete them--so they get partially updated test scripts. Even then, I know that they aren't using them. How do I know this? Because when I use the test scripts to test the software, I find defects that aren't reported in our defect tracking system. I know they aren't using them. So why do they demand that I prepare them for them? Are they using them as some sort of ego-bloating paperweight on their desks? I know the work has to be done, but dammit, why isn't sufficient time allocated for it?

I cannot tell you how many weeknights and weekends I've given up for this project. And it's not like I'm getting paid overtime for this stuff. I have no personal life. And "thank you" and "good job" is simply not enough. I don't get paid for all the other hats I wear. I get paid to be a software developer. I don't get paid to be the the DBA, the software engineer, the business analyst, the architect, the web designer, the project manager, the customer support representative, QA engineer, the risk manager, the technical writer, and the release engineer. And management doesn't see that. All they see, every time I bring this up, is that the customer is apparently "happy" and that I can always be relied upon to get the work done.

Of course I can. I'm killing myself to get it done. It's Classic Mistake #4: Heroics. The company thinks I'm freaking Superman.

My God. What have I done?

To a large degree, I led the company to that opinion. I took on too much work. I let them believe that I could do it. But eventually, I started pushing back when I realized my mistake. I set realistic expectations about what could and could not be done. The course was reasonably corrected.

But in every project, in every organization, there is a certain Wall. Beyond that Wall ye shall not pass. It is the Wall of Absolute Resistance, and no amount of pushing, pleading, or reasoning will avail you. The forces on the other side are simply not reachable.

You can preach best practices until you're blue in the face, and some organizations will simply not see the light of day. You can talk about automated unit testing and they won't care. You can talk about investing more time in testing, to reduce the costs of defects as early as possible, and they'll still be more interested in beating a competitor to the market with a bug-riddled application than they will be in sparing users a frustrating experience and corrupting their data. You can tell them that you are going to have to bring on more hands earlier in a project to ensure its success, and they'll be more worried about the costs of the new employees' benefits in the short term than they will be about the rapidly escalating costs of the software's development and maintenance in the long term.

What do you do in an organization like that? What should I have done? The short answer is this: I don't know what I should have done in the past. It's been a valuable learning experience for me, that's for sure. In newsgroups, people have told me they envy me my position, that it's great job security. My response to them these days is this: I can live without this kind of security.

In the future, if a company offers me a job and tells me I'll be the sole developer, I'll walk away from the offer. I'll never do this again.

Some folks have claimed that it presents the great opportunity to establish your own process. In my experience, there is no process in a team of one. There's nothing in place to hold off the torrents of work that come your way. There's no one to correct you when the urge to gold-plate the code comes along. There's no one to review your code. There's no one to ensure that your code is checked in on time, labeled properly, unit tested regularly. There's no one to ensure that you're following a coding standard. There's no one to monitor your timeliness on defect correction. There's no one to verify that you're not just marking defects as "not reproducible" when, in fact, they are. There's no one to double-check your estimates, and call you on it when you're just yanking something out of your ass.

There's no one to pick up the slack when you're sick, or away on a business trip. There's no one to help out when you're overworked, sidetracked with phone calls, pointless meetings, and menial tasks that someone springs on you at the last minute and absolutely must be done right now. There's no one to bounce ideas off of, no one to help you figure your way out of a bind, no one to collaborate with on designs, architectures or technologies. You're working in a vacuum. And in a vacuum, no one can hear you scream.

The insane hours, the stress, the loss of a productive life outside of your job--it's not worth it. I'm willing to accept all that I have done to create this scenario. And you can bet that I'll be doing everything in my power in the future to ensure that it doesn't happen again.

If anyone's reading this, let this be a lesson to you. Think hard before you accept a job as the sole developer at a company. It's a whole new kind of hell. If given the chance, take the job working with other developers, where you can at least work with others who can mentor you and help you develop your skill set, and keep you abreast of current technology.

Take my advice. Don't open that door. It leads straight to Hell.