In case you missed Gates VP’s comment about The Fallacy of Management on my recent post Q & A on Leaving Management for Development, I’ve re-printed it below:

===

I have a working theory that I’ve titled The Fallacy of Management.

The basic definition is that current managers would have us believe that the work they do is the very reason for project success and therefore they believe (and have convinced others) that their’s is the most important role.

The real truth is that most managers are just overhead, projects would likely self-assemble without them, especially with good devs on the job. However, companies do things like targeting management for bonuses and taking other steps to make management a “position of privilege.” The truth is, good managers don’t deliver projects on time, good programmers deliver projects on time and managers just guide the process.

The concept of “separate streams” begins to address the problem of Technical Expertise vs. Managerial Expertise. But it’s also an industry thing. “Similar” professional industries, like engineering or accounting, all have a kind of set progression chart from grunt to project manager. Most current “managers” don’t actually recognize the difference between our and the engineering field, let alone begin to address the number of engineering project managers who probably shouldn’t be there anyways.

It’s the Peter Principle + poor management + uncertain staff (like yourself at times) that allow the whole vicious cycle to keep turning. Every once in a while, people get off the cycle (like you), but right now we’re still early in the game and there are more people hopping on the bike rather than off.

In 10 years, people will know better, the industry will mature (a little) and the Technical / Managerial divide will be well-documented. There’s a trend right now that’s dividing the industry and that’s the “Great Development Houses” vs. “The Body Shops.” Expect that the former will pick up on (or has picked up on) this divide and that they’re capitalizing by hiring the right people into the right positions.

===

[Rob]: Gates makes several excellent points, and I hope he continues to flesh out this theory.

While I agree with most of what’s said above, I have to chime in that a good manager is more than overhead. I’ve worked with managers who made a real difference on our projects, including motivating and rewarding the team, removing political obstacles, and removing the crappy tasks from our plates so we could produce. While most managers could be considered dead weight, a good manager can be invaluable.

Secondly, I question whether 10 years will make a difference in the cycle of developers moving into management. This cycle has a lot to do with figuring out your strengths and desires as a professional, and I think each person needs to go down this path for themselves.

After all the writing I’ve done on the joy of coding and my two trips to management and back, a developer friend of mine has decided to get his MBA so he can go into management. I forwarded him a link to Why Good Developers are Promoted into Unhappiness and he replied:

“I hear you, but I have to experience it myself.”

I can’t argue with that.

[tags]management, programming, software development[/tags]

I’ve received several emails about my post Why Good Developers are Promoted Into Unhappiness. One reader asked some interesting questions on his quest to decide between development and management.

Here are some excerpts from our conversation:

Q: Does leaving management for coding greatly cut your salary?
Going back to coding may cut your salary, but it’s quite possible it will not. In my case, the first time I went from management to coding I was fortunate enough to move into a higher paying development position. The second time I didn’t receive additional money for my “promotion” into running a development team, so going back required no monetary sacrifice.

Obviously I was lucky, and it’s a very real possibility that leaving management could have an effect on your salary. However, I haven’t worked at a company where the development manager makes tremendously more than the highest-paid senior developers. Senior Developers in L.A. can make $125k, in the bay area they can pull $140k+. These are enterprise application developers; highly specialized developers could definitely earn more.

So the question is: how much money do you need to be happy, and is it possible to earn that while still writing code?

Q: Coders seem to be considered commodities and low level craftsman. Why would someone go back to that?
Enterprises that consider developers “commodities and low level craftsman” are doomed to have (at best) average developers working for them.

A close friend of mine works for a company that has experienced a mass exodus of developers for this very reason. The best left first, the mid-range followed. What’s left are the people who clock in 9 to 5 for the paycheck and don’t take pride in what they’re building. The company now has what they asked for: a team of low-level code jockies. The people with initiative, energy, and passion have left.

Since you don’t want to work for a company like that, how do you determine if they view developers this way? The last time I interviewed for a salaried position I brought a list of questions with me and interviewed the company as hard as they interviewed me. I also made it a point to speak to one of their developers, and asked him several questions about the working environment, hours, etc… Most developers won’t lie to you about this sort of thing.

Q: I like coding, but isn’t management a more secure job?
Not in my book – developers have hard skills. I could move to nearly any city in the country, walk in to a company, and demonstrate that I know my stuff. It’s true that the job market is wide open for great managers and coders, but not only is it easier to prove you know how to code, there are more development positions than development manager positions.

Q: Doesn’t a manager generally make significantly more than a coder?
If I posted this on my blog we’d get 50 different answers (cue you, the reader, to post your opinion in the comments). At my job with the City I managed 10 people and I made more than most of them (the few who made more than me had been there for many years).

At my next position our manager made a tad more than us (around 10%), and he received more stock. He put up with 100% more headaches than we did, so we considered ourselves ahead on the deal.

Q: I’m trying to find something I love that pays very well. I’m really exploring if there is more of a ceiling as a developer than as a manager. If there is, I need to figure out how to get above it.

One thing about this industry that I still don’t understand is no pay over 40 hours. Virtually everyone does this. My question is why and why do developers accept it? If they calculate their per hour pay against that 60 hour week, they could probably do better working as a laborer on a pipeline. Does that really make any sense?

Here’s one way to get around the salary cap and get paid for every hour you work: start your own consulting firm or become a contractor. (A quick aside on how I differentiate consultants from contractors: consultants do a lot of work away from the client’s office, and they perform more project-oriented work. Contractors tend to have a cubicle at the company’s office and often do the same tasks as salaried employees.) Either way you’re paid well to write code and are typically paid for every hour you work.

This is why I left a salary in favor of running a consulting firm – for the freedom to choose what work I do, the ability to get paid for every hour I work, to continue to code, and to make more money than a salaried employee.

Q: If you want to keep climbing the corporate ladder up into Direct or VP, don’t you have to go through a management role to get there?

Yes. If that’s your goal, then go into management.

I know of only one exception to this rule. It’s a company in New Jersey that has a technical advancement track that parallels the management advancement track. In other words, people can stay completely technical and still advance in their companies.

At this company, if you don’t want to become a manager when you’re up for a promotion there’s a technical track you can request. I don’t know the exact titles, but these “Technical Directors” are on the same level in terms of power and seniority as their management counterparts; the major difference is they don’t have anyone reporting to them. They operate relatively independently in the company, but at a very technical level. The problem with the management track is that there’s a limited number of slots, because the company needs to have people reporting to a manager. But a company can have as many technical directors as it wants because they don’t require people underneath them.

Another big advantage of technical directors is that when cutbacks come, they don’t need to worry about retaining their team sizes. As a manager if enough layoffs happen and nobody reports to you, then by default your job is unnecessary. The technical director doesn’t have this problem.

A question for you, dear reader: How have your experiences been the same or different from what’s been said above?

[tags]programming, management, salary[/tags]

I relocated from Los Angeles to Connecticut a few months ago, and a few of my geekier friends joked that I had to meet Joel Spolsky and Paul Graham before I came back to California.

Joel is in the midst of his 21-city FogBugz World Tour and one of his first stops was in New York City, where I saw him demo FogBugz 6.0 two weeks ago. In fact, in the picture at the top of Joel’s post about the session, you can barely see my head peeping out over the guy with the black shirt and white stripes on the left side. Those stinking paparazzi never leave me alone.

FogBugz 6.0
The demo went well; it wasn’t spectacular, but it was a good 40-minute overview of FogBugz’s main components: a wiki, forums, bug tracking, and scheduling. But it didn’t need a big flashy presentation – the application itself is seriously impressive.

I don’t know when FogBugz became a complete project tracking and support tool for small software shops, but it’s no longer just a bug tracker. The wiki looks really sharp – the WYSIWYG editor is completely custom, and the AJAX everywhere makes for a fantastic user experience. Joel said they spent between 2 and 3 person-years developing their AJAX library from scratch since they encountered too many issues with third party libraries.

I’ve been using FogBugz on Demand (their hosted solution) for the past several months and I hadn’t even noticed there’s a wiki (intended for writing specs and documentation), forums, group email (perfect for a support team serving external customers), and the awesome evidence-based scheduling piece.

Evidence-Based Scheduling
In evidence-based scheduling a completion date is constructed from developer estimates, but the completion date is actually a range of dates with probabilities that each date will be met. So you can look at the calendar and say “We have a 50% chance of finishing by October 31st, and a 90% chance of finishing by November 23rd.” In addition, the schedule is based on the developers’ past estimating accuracy, so the better their estimates (compared to their actual time spent), the tighter the completion timeframe. Bad estimators means a wider timeframe.

It’s the right way to handle the task of determining a completion date, and now that they’ve implemented it I’m amazed no one has done it before. Some form of evidence-based scheduling is going to find its way into every project management tool over the next few years. If you’re not happy with your bug tracking or project management application you should take another look at FogBugz.

The Wrap-Up
The capstone of the morning was during the casual Q&A session after the official meeting. Most people left quickly and I found myself in a room filled with about 10 other attendees and the entire staff of Fog Creek Software.

After talking to a couple Fog Creek developers I wound up having a 15-minute conversation with Joel about consulting vs. products, leverage, and SaaS. He’s as smart in person as he sounds in his blog, and it’s obvious he’s given a lot of thought to the issues we discussed. Having read Joel’s blog since 2000 it was cool to finally meet him face to face.

[tags]joel spolsky, fogbugz, evidence based scheduling, programming[/tags]

From my new article Computer Science Enrollment is Going Down, and Taking Software Jobs With It:

“How many of us would kill to work with ultra-qualified, talented developers instead of whoever we can find that has a pulse and once wrote an Excel macro for a junior high class project? If Computer Science enrollment continues to drop people will eventually get hired, with or without degrees and regardless of how qualified they are, because companies will be desperate. And then we’ll be stuck working with folks who can’t find their text editor with two hands and an issue of Dr. Dobb’s Journal.”

Read the complete article here.

I once thought I had traveled a unique career path. Graduating from college with a degree in computer engineering and electrical engineering I was on fire to be a manager. My dad had worked for the same electrical contractor for 30-something years and I knew everyone from the Chairman of the Board down to the woman who worked the front desk. I had a major “in” and was quickly shuffled into a management training program, with my sights set on one day becoming CEO of the $600 million firm.

18 months later I left for a job writing software for a dot com in Sacramento, and within 3 months I was running multiple project teams (albeit, small ones). I was young, it was fast paced, and I loved it.

When that company experienced difficult times in 2001, I transitioned into contracting, which I did for about three years before taking a position as the Application Development and Database Supervisor at the City of Pasadena, directly responsible for the management and supervision of 10 developers and DBAs. The prestige? High. The paycheck? Fat. The job? Hated it.

I couldn’t get past a number of issues with this “perfect” position, namely that I couldn’t hire and fire as I pleased, our technology was dated, and it took movement from the hand of God himself to be able to write a few lines of code. On a side note, many of the people I worked with at the City were very good to work with and knew how to do their jobs. Pasadena is one of the most progressive cities in the state, if not the country, in terms of technology. But the job didn’t fit me and I started to interview elsewhere.

By this time I was burned out on managing people and knew what I wanted to do: write code.

“Do you want to manage?”
Nope, I want to write code.

“Do you want to run a team?”
Nope, write code.

“Do Architecture?”
Write code.

“Talk to your co-workers?”
CODE!

During this time an interviewer asked me “Where do you see yourself in five years?” and my answer was “I just want to write code. I don’t want to manage people. I’ve been there and I didn’t enjoy it. I want to get back to learning .NET and come up for air in about 3 months.”

And code I did. I arrived in the morning, threw on my headphones and wrote mad stacks of functionality. I produced more software in 6 months than I had in the previous year. It was a fun time and I look back on it with fondness, if not a bit of envy. But I was naive to think I could continue doing that for very long.

After 6 months I was asked to run a project. I accepted and what started as a two-person team evolved into 10 developers cranking on the largest software project our company had every undertaken. And I was at the helm.

During this time I didn’t write a line of code for 15 months, but my Visio skills were like nothing you can imagine. I knew every keyboard shortcut and every right-click. I saw Visio shapes attacking me in my dreams and I knew the exact mouse movements and clicks to re-size them so they could do me no harm.

I left the company within a year of completing that project. I had voiced my – lets call them concerns – many times but the “good of the project” always overruled my desire to return to writing code. After nearly a year of asking to return to the battlefield, I turned in my badge and made my way back to the world of consulting.

I discovered that although I enjoy running small teams, I have an innate desire to create. And unfortunately, while managing people requires creativity, it does not allow you to create. Although my teams and bosses liked me and my results, it did not fulfill deep need to take dead bits and make them into something living.

We’re Not Alone
Within the last year I’ve heard nearly identical stories from four five other developers whom I’ve known for many years. One friend, while telling me his tale of being forced into project management, described a conversation where he told his manager “I just want to code.” I laughed out loud at his word-for-word use of what had become my mantra for the past 15 months.

Another friend of mine said:

“I feel I may be on a similar track to what you’ve traveled, starting from a developer and moving into project oversight on a $1 Billion project. Maybe one day I could be a programmer again, having come full circle. Programmers are not bottom feeders but something to aspire to, even for people who are currently managers, not just for college grads looking for entry level positions. Working my way ‘down’ to a programmer might work my way back to a place I really enjoyed and have fond memories of. Instead of reverse engineering it’s sort of a reverse career track.”

I imagine there are more stories where these came from.

Why It’s Bad
Promoting developers into management or project management is not bad. On the contrary, I have most enjoyed working for managers who at one time in their career made the 1′s and 0′s dance.

The problem is not that developers are promoted, it’s that the developers who tend to be promoted are the “big producers,” the ones who come through on their projects. These are the same developers who stay late and read software books on the weekend because of their love for programming; that’s why they come through on their projects. Promoting someone who loves to write software into a position where they will write little or no software doesn’t make an ounce of sense.

Someone else said this first, but if Willie Mays played for your baseball team would you promote him to manager? True, he delivers more than his teammates, and he is one of the best players of all time, but a player of that caliber should be left where he can do the most good: smacking balls out of the park. Moving him into manager not only reduces his direct contribution to the team, but is done under the assumption that he has a clue how to manage his fellow players, instead of what he’s obviously demonstrated he can do: hit a baseball like few people in history have.

The answer? Promote developers who demonstrate management skills instead of top notch development skills. They may be hard to find, but top notch developers are even harder to find.

The end result of promoting your best developers is at best a few unhappy months or years as they struggle with their unhappiness and their desire to return to code, while (perhaps) not wanting to disappoint you. The worst case is they feel unbridled resentment as you watch them rush out the door like there were a 70%-off sale at Barnes & Noble.

Why We Fall for It
Every developer I’ve talked to said the same thing: they went into management for the prestige, the money, pressure from their bosses or upper management, and not wanting to “stir the pot.”

Perhaps it’s the fact that the best developers I know are easy to get along with, good listeners, and generally pleasant to work with. Hence, when a manager or executive asks them to run a huge project they take it as a challenge and a compliment. It’s not until 10 months later when they’ve lost their ability to write a while loop that they realize they may have made a mistake.

If you find yourself in management and wish you were coding, don’t wait until you’re completely burned out and bitter; do yourself (and your company) a favor – and do it now. Get yourself back into the code jockey seat. If your current company won’t work with you, there are companies out there who will.

[tags]programming, management, promotions[/tags]

I’ve worked for startups and stalwarts, small shops and large corporations, firms where software is the means to an end, and firms where it was an end in itself. After years of exploring what I love about building software I’ve realized that coding for a 17-person dot com is a far cry from building enterprise software for a 300-person credit card company. It only took me eight years to figure out why.

There are a myriad of articles on interviewing, evaluating, and hiring software developers, but a topic that’s rarely discussed is how to attract software developers that fit your company’s environment. With the current state of the software job market, it’s critical as a hirer that you determine not only what type of developers will be happy in your environment (your “developer demographic”), but how you can become more attractive to that particular slice of the market.

Your Developer Demographic
As an example, IndyMac and Countrywide are large financial institutions with development offices in Los Angeles. They attract people looking for stable jobs with good benefits where they can code 9 to 5 and then go home and not think about it from 5 to 9. I envy people who do not grow bored with this environment; I really do. Life would be much, much simpler if I could handle it.

There are also tech startups that attract caffeine-junkies. Long hours with potentially large reward, and the prospect of building something really cool in a short amount of time that could make a difference in peoples’ lives. Or, more likely, be relegated to the failed startup scrap heap. These companies should be looking for people who love using new technology, are typically younger, willing to take risks, and willing to shoot from the hip.

These may be extreme cases, but they illustrate the point: certain attitudes and personality traits play nicely with certain environments. Often, a developer who thrives in one environment will find that she slowly withers away in others.

The Three Dimensions
To get more specific, there are three dimensions to a company that most affect the internal environment for a software developer. It’s critical that you know which of these your company falls into, and not only market to, but ensure you can retain developers who fit that demographic. The descriptions of the software developers who like to work at each corporate classification are generalized, but they serve as a guide to get you thinking about the personality of your ideal candidate.

Your company may not match exactly with one of the choices below each dimension, but do your best to categorize it. Many companies start off as one thing and transition to something very different in the first year or two.

1. Size
   • Small – Some small companies are startups, and some are 10-year old, profitable, mature businesses that make money hand over fist with 9 employees. Software developers who like small companies are typically social, they like the vibe of knowing everyone, going to lunch with the same people, and knowing that they contribute a great deal to the success or failure of the enterprise.
   • Large – The bulk of corporate development is for larger companies. They tend to have big teams, lots of process, and decent-sized QA and Change Management teams. Software developers who like large companies tend to enjoy more process, like working on larger teams where they can either lead or be led, and enjoy the possibility for growth that comes with a large organization.
2. Chaos Level
   • Stable – Stable companies tend to be, um…stable. They have good benefits, and employees can often get away with working 8 or 9 hour days. Developers who prefer stable companies are likely a little further along in their career, may have a family, like the consistency of coming in to the same office each day, and enjoy their time out of the office when they don’t have to think about software.
   • Startup – Startups tend to be more risky with the possibility of more reward. The salary may not be as high as that of a stable company, but the stock options will be worth six-figures if you can get your bleeding-edge online calendar out the door before Google’s. Benefits tend to be spotty. The hours are long, but it’s more than worth it for developers who are passionate about technology (read: bring books about ASP.NET to the beach), love building software that matters, and enjoy the camaraderie of working on a team of people who share their interests.
3. Focus
   • Software (or a technology that relies on software) - These companies rely on software for their main source of revenue, whether they sell it (Microsoft, Intuit), give it away (Google, Craigslist), or offer it on some type of “pay to play” basis (eBay, salesforce.com). Technology firms that rely on software are companies like Palm, Jenzabar, Apple, or the guys who make the fingerprint readers I keep seeing at data centers. Software may not be their main source of income, but they are technology companies and software is critical to their product. Software developers who prefer these types of companies enjoy being around other software people; they like the idea that technology is at the core of their company, and they love that they work on real products that people use. In addition, they relish the fact that software firms tend to live towards the cutting edge and are able to constantly upgrade their skills to the latest and greatest.
   • Everything Else – These companies make up the majority of companies in the world; their main source of revenue is something other than software – credit cards, lawn furniture – you name it. “Everything else” companies use software to support their business: to track widgets, support their call center, and balance their books. The majority of corporate software jobs are working for companies under this umbrella. Software developers who enjoy this type of company like building applications to support accounting, management, and the people who produce or sell the company’s main product, and they are either very content to know they can go home at night and not think about developing software, or they go home at night and all they think about is they day they can leave the company and work for someone like Google.

Your Company, Your Developer Demographic, Your Job Description
Before writing your job description think hard about where you fall in each of the dimensions. Then think twice as hard about the kind of developer who will be happy at your company. Don’t kid yourself; you can convince the 24 year-old tech hot-shot to work for your financial services company by offering him a huge salary, but he’ll be gone in 9 months because you’re using three-year old technology and developing boring (from his perspective), back-office software.

Once you’ve determined who will be happy at your company, write your job description with that person in mind.

You’re a large company with great benefits? Spell it out in bullet points: plain, simple, and official. Play up your stability.

You’re a small startup with no benefits? Use a casual tone and create excitement. Make that 24-year old hot-shot be dying to work for you.

Even if he has to pay for his own health care.

[Digg this]

When I was in college I was a professional comic book writer. After numerous submissions I had several stories accepted by three independent comic book companies, all slated for publication.

I even received a $100 advance for one of the stories, with all of them paying royalties on the “back end,” meaning I’d probably wind up making $100 per story if I was lucky. And back then $100 was a lot of…no, let’s face it, even back then $100 was nothing. But I could call myself a professional comic book writer.

On Being a Professional
Which is a joke, of course, because I wasn’t a professional. I was writing in a tiny bedroom, typically from 10 at night until 2 in the morning, cranking out a short script every week or two. Sure, I had honed my skills as a writer enough to match the myriad of others trying to make it, but I was not a professional writer. And I’ve had a hard time puting my finger on what it was that distinguished me from those whom I considered “legitimate” comic book writers. It wasn’t the fact that I worked out of a small apartment. Or that I wrote at night.

It was the fact that I didn’t consistently deliver under the pressure of deadlines.

I’m sure I’ll receive a few comments saying that a professional is someone who gets paid for what they do, or someone who does something as their main source of income, or someone who’s easy to work with, or someone who comments their code. Those are some of the components of being a professional, but one of the most important and often overlooked pieces of being a professional is consistently delivering a usable product in the face of deadlines.

How Many Deadlines Must a Man Walk Down…
I knew at least two guys who were amazing comic book artists. Both drew as well as the books on the shelves, but neither could draw an entire 22-page comic in a month…and that’s what it takes to be a professional in that game.

I’m not saying if you miss a deadline you’re suddenly an amateur – the continuum is much less binary than it is fuzzy. But during your career, your present job, or the past 6 months, how many deadlines have you hit? How many have you missed?

There are going to be extenuating circumstances. There are going to be times when a third party vendor flops and the project falls apart at the last minute. And there are going to be times when the deadline is set externally and you know from the outset you’ll never hit it. But if you find that there’s always a reason you aren’t hitting deadlines you have to start asking yourself: Is it you?

I know that somewhere between 55 and 90 percent of software projects fail. Missing deadlines is easy; I could get my mom, who knows nothing about software development, to come in and miss project deadlines. Does the fact that she showed up and collected a check make her a professional developer? She’s easy to work with and comments her code.

So here is my question: during your career, your present job, or the past 6 months, how many deadlines have you hit and how many have you missed?

This isn’t a show of hands, just a gut check.

An SbR reader contacted me looking for guidance on how to work with a group of un-motivated developers; his email is below (posted with permission).

I will post my reply next Monday, after giving you a chance to weigh in on the situation.

Q: “In the course of providing Change Management consulting services to an owner operated company, I got involved in trying to find out what was happening in their IT department (4 Software Engineers). They are all on salary with full benefits.

The IT Departments absolute priority is to insure the company’s current software and network system is operational. In general the current company system only requires minimal daily maintenance with periodic planned upgrades. Accordingly the Software Developers are able to focus the majority of their time on development of a new ERP software system.

They have been at the project for approximately 5 years. Design is complete and development is underway. After much discussion and prodding I managed to get them to produce a timeline to deployment versus completion. Deployment defined as being able to switch from using the current system to the new system with a minimum of equal functionality to the current system. The timeline is to a specific date versus effort in months. They arrived at the deployment via sophisticated process versus an educated guess so I believe it is realistic.

In my view stakeholders must have a deployment date and developers need a realistic deadline. We have our deployment date (set by the developers, not stakeholders) but I suspect they are not committed to it. They start at 8:00 am on the dot and are out the door at 5:00 pm. Lunch and coffee breaks are never missed. My concern is that they have been spoiled by not previously having a definitive deployment date so it is expected to balk at accountability.

My instinct is to shut the project down but I also do not like to give up.

[I'm looking for] direction on how to motivate this group to want to take ownership and to rise to the challenge of meeting the deployment date.”

If you were in his shoes, how would you handle this situation?

After publishing Nine Things Developers Want More Than Money late last year, I received several requests for something that could provide more specific information than the 1-9 score on Rob’s Criteria for Keeping Your Developers Happy. In other words, managers want to know which of the nine areas to focus on, and most who wrote suggested I create a survey they could give anonymously to their developers.

In response, I’ve created a 29-question survey that covers all nine of Rob’s Criteria. I built it in HTML so you can print it out and distribute paper copies, or write code to place the responses in a database for easier analysis. If you wind up using a database I’d appreciate if you would send me a copy of your code so I can post it here.

The survey does not have a norm since it has not been administered to anyone. As a result, determining the results will be up to your interpretation. Hopefully that’s not too difficult given the nature of the questions.

If you have other questions you’d like included, or stories to share about survey results, please post them in the comments.

Dear Software Managers of the World:

We, the Software Developers of the World, realize that our two factions have had many disagreements over the years. Through this letter we would like to extend our hand in a gesture of reconciliation.

This letter contains two lists: the first list describes responsibilities we are willing to accept wholeheartedly, assuming you are willing to accept the second list with an equal amount of zeal and commitment. These lists are not intended as indictments of either side, rather glimpses of an ideal world where developers and managers work together in harmony.

We, the Software Developers of the World, agree to the following:

1. We will do what it takes to get the job done without being asked, including working extra hours (as long as it does not violate clause 1 in the section below).
2. We will not complain when we are assigned boring tasks, bad problems, or have to maintain someone else’s code (as long as it does not violate clauses 4 or 5 in the section below).
3. We will bring issues to your attention constructively and with proposed solutions.
4. We will seek to understand a decision before questioning it.
5. We will build the best software we are able to.
6. We will be loyal to the company and our team.
7. We will be passionate about the software we build.
8. We will be available when you really need us.
9. We will fully document our code and designs.
10. We will happily coach and mentor new developers.
11. We will tell our friends how cool it is to work at our company.

In turn we ask that you, the Software Managers of the World, agree to the following:

1. You understand that “crunch time” is an unexpected part of software development. Unless we have substantial equity in the company, crunch time will not exceed 3 weeks during any 6 month period.
2. You will give us powerful, best-of-breed PCs, huge hard drives, large monitors, and the latest development software.
3. You will listen and take action when we constructively bring a problem to your attention.
4. You will ensure that at least 80% of our time is spent on good problems.
5. If you plan to call us when software breaks, we will be given time to refactor and stabilize it as needed.
6. You will not ask us to serve as technical guides for highly paid contractors only to be held responsible when their code single-handedly brings our operations to a grinding halt.
7. If marketing is allowed to set our deadlines based on their knowledge of software projects, we will be allowed to set their budget and/or revenue expectations based on our knowledge of marketing.
8. You will not ask us to compromise a solid, stable, and maintainable design in order to meet an unrealistic deadline.
9. You will communicate expectations to to the stakeholders. You will ensure that before we begin building an application, all stakeholders spend ample time reviewing and understanding the specification.
10. You will ensure that as new requirements arise we will be given the corresponding amount of additional development time.
11. You will pay attention to your people more than your bottom line.
12. You will make our company a cool company to work at so we’re not lying to our friends.

We hope you take these items under consideration and we look forward to how these changes will positively affect our relationship as we continue to work together to build software for many years to come.

Sincerely,

The Software Developers of the World

Digg this

If you liked this post you’ll also like Nine Things Developers Want More Than Money.

Thanks to Mike Taber, Andrew Black, Jeremy Lukensmeyer, Dave Standring, and Adnan Masood for their input. Special thanks to Mike Taber and Dave Standring for reading drafts of this post.

JD over at DCS Media published an insightful post titled Top 20 Programming Lessons I’ve Learned in 20 Years. A few highlights:

• Always backup your code
• You are not the best at programming. Live with it.
• Simplify the algorithm
• Reminisce about your code
• No project is ever simple
• Software is never finished

There are good problems and bad problems when developing software.

A good problem is designing an elegant caching mechanism for your configuration variables, or determining how to architect your service oriented architecture so it doesn’t look like the New York subway system.

A bad problem is figuring out how to re-architect your code to work with a partner whose API goes down twice a day, spending three hours trying to get your code into source control, or filling out ten minutes of paperwork for a five minute code change.

Paul Graham makes mention of this in Taste for Makers:

“Not every kind of hard is good. There is good pain and bad pain. You want the kind of pain you get from going running, not the kind you get from stepping on a nail. A difficult problem could be good for a designer, but a fickle client or unreliable materials would not be.”

And in Great Hackers:

“One of the worst kinds of projects is writing an interface to a piece of software that’s full of bugs…you don’t learn anything from [doing this]. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn’t teach you anything, because the bugs are random…Working on nasty little problems makes you stupid.”

Bad problems are not interesting, not fun, and they teach you nothing. They create frustration and, given enough of them, will eventually cause burnout.

I’ve seen a string of bad problems last for months, and cause developer after developer to leave a company in search of more interesting work. Bad problems wreak havoc on your ability to meet Rob’s Criteria for Keeping Your Developers Happy.

Look at any large financial institution, government agency, and [insert name of large organization that considers developers to be a cog in their wheel here]. I’ve worked at a few of these companies, and often hear developers who are out of work joking: “If things get bad enough I could always go work for Company X.” Ouch…tell me that doesn’t hurt your ability to find good people.

On the flip side, look at Google, Fog Creek Software, and SourceGear. I’ve never worked at these companies, but evidence is strong that good problems are at the forefront of their agendas. And by some shocking coincidence they get a bazillion resumes for every open position.

A steady stream of good problems is the foundation for keeping your developers happy. Minimizing bad problems and maximizing good problems should be every development manager’s #1 goal.

[Digg this post]

From my new article Nine Things Developers Want More Than Money:

“If you want to collect a paycheck for 25 years and retire with a gold watch and a pension then go for companies that have the hygiene factors nailed. Stroll in at 8, head for the door at 4:59, and count the years until you’re kicking up your feet on a beach bar in Costa Rica.

But if you’re reading this, odds are that you aren’t the kind of person who never thinks about code after 5:01; you’re more likely to have a collection of DVDs that come up in an Amazon search for “Silicon Valley.” You’re probably one of those people who needs motivation factors or you go crazy with restlessness, and when the motivation factors are in place you’ll work ridiculous hours for low pay just because it’s so damn fun.

I talked to a dozen colleagues and pored over my own experiences to arrive at this list of nine software development motivation factors – Rob’s Criteria for Keeping Your Developers Happy.”

Read the complete article here.

This article has been translated into: Belorussian.

Many of the developers I know have been programming since they were in junior high. Whether it was building text-based games on an Apple IIe or creating a high school football roster app in Visual Basic, it’s something they did for the challenge, for the love of learning new things and, oh yes, for the ladies. Ladies love a man who can speak BASIC to his Apple.

College graduates face a sad reality when they leave the protective womb of a university and have to get their first real job. Many of my friends found jobs paying around $25k out of school, and were amazed that the starting engineering and computer science salaries were nearly double that. But the majority of the engineers in my class didn’t become engineers for the money; we did it because it touched on a deep inner yearning to tinker and impress their friends. And did I mention the ladies?

Money is a motivating factor for most of us, but assuming comparable pay, what is it that makes some companies attract and retain developers while others churn through them like toilet paper?

Hygiene and Motivation
In the 1950s a researcher named Frederick Herzberg studied 200 engineers and accountants in the US. He asked them a few simple questions and came up with what is one of the most widely-accepted theories on job satisfaction called Two Factor Theory.

His theory breaks job satisfaction into two factors:

• hygiene factors such as working conditions, quality of supervision, salary, safety, and company policies
• motivation factors such as achievement, recognition, responsibility, the work itself, personal growth, and advancement

Hygiene factors are necessary to ensure employees don’t become dissatisfied, but they don’t contribute to higher levels of motivation. Motivation factors are what create motivation and job satisfaction by fulfilling a person’s need for meaning and personal growth.

Think of a large financial company like Countrywide or IndyMac. Although I’ve never worked for either, the stories I’ve heard indicate the hygiene factors are well taken care of: working conditions are good, supervision is reasonable, salaries are decent, they have good benefits, etc…

However, the motivation factors are, shall we say, incognito. As Herzberg noticed, this scenario leads to employees viewing the job as little more than a paycheck, which is probably all right for companies like Countrywide and IndyMac.

Take the flip side: a tiny startup in a dingy office with no windows, crappy benefits, little supervision (because the CEO’s on the road making sales), and no company policies (because the CEO’s on the road making sales). But the constant rush of learning, being responsible for the company’s success or failure (almost single-handedly at times), and believing in the company’s future growth makes this job much more desirable for many developers.

One of my early programming jobs was for a web consulting startup during the dot-com boom. There were 7 of us (we grew to 17 during the height of the boom) shooting each other with water pistols, throwing Nerf footballs around the office, and cranking out insane amounts of caffeine-driven code. We learned a new language every project and were always on the cutting edge.

I remember thinking that a company across town could have offered me a $15,000 dollar raise and I wouldn’t have taken it. The motivation factors were overpowering.

On the flip side, the benefits were terrible, the office was a series of tiny cubicles, gray from years of neglect – Smurf-blue network cables hung from the ceiling, and supervision was…well…non-existent. And although hygiene factors were lacking, developers flocked to work for this company and only one left while I was there. She was interested in a more stable work environment and better benefits, and went to work for a large financial institution much like IndyMac.

Rob’s Criteria for Keeping Your Developers Happy
If you want to collect a paycheck for 25 years and retire with a gold watch and a pension then go for companies that have the hygiene factors nailed. Stroll in at 8, head for the door at 4:59, and count the years until you’re kicking up your feet on a beach bar in Costa Rica.

But if you’re reading this, odds are that you aren’t the kind of person who never thinks about code after 5:01; you’re more likely to have a collection of DVDs that come up in an Amazon search for “Silicon Valley.” You’re probably one of those people who needs motivation factors or you go crazy with restlessness, and when the motivation factors are in place you’ll work ridiculous hours for low pay just because it’s so damn fun.

I talked to a dozen colleagues and pored over my own experiences to arrive at this list of nine software development motivation factors – Rob’s Criteria for Keeping Your Developers Happy.

There’s only one rule when determining your score: your vote doesn’t count unless you’re a developer. If you’re not in the trenches writing code then forward this article to someone who does and ask for their opinion. In addition to keeping management from making an unfair assessment, my greater hope is that this inspires conversation and forces management and developers to talk about these issues so we can get them out in the open.

Without further ado, here they are:

1. Being Set Up to Succeed
It’s a sad reality, but most software projects are set up to fail. Every developer has their horror stories; the “anti-patterns” of software project management. I’ve seen an architect given documentation for a legacy system that he pored over for week while designing a new interface for the product. After the design was complete he found out that the documentation was three years old and didn’t reflect several major changes the system.

I’ve spent hours preparing a detailed technical estimate only to be told that the real deadline, already set by product development, gives me half the time I need.

Realistic deadlines are a huge part of being set up to succeed. Developers want to build software that not only works, but is maintainable; something they can take pride in. This is not in-line with product development’s goals, which are for developers to build software that works, and nothing more.

The first thing to go when time is tight is quality and maintainability. Being forced to build crap is one of the worst things you can do to a craftsman. Delivering a project on-time but knowing it’s a piece of crap feels a heck of a lot like failure to someone who takes pride in what they build.

It’s critical to have buy-in to do things the right way, and not just the quick way. As one developer I talked to put it “Quality is as important as feature count and budget.”

Schedule is not the only way a project can be set up to fail, but it is the most common. Others include: being forced to use cheap tools (be it software or hardware), working with a partner who doesn’t deliver, bad project management (see #2, below), changing scope, and unspoken expectations, among others.

2. Having Excellent Management
Excellent management, both for projects and people, is a must-have motivation factor. This means no micro-managing, the encouragement of independent thinking, knowing what it takes to build quality software, quick decision making, and a willingness to take a bullet for the team when product development tries to shorten the schedule

These are the traits of an amazing software manager; the traits of a manager whose team would bathe in boiling oil to defend her, and work all-nighters to prove her right. When a manager takes bullets for the team, good developers tend to return the favor and then some. It creates an almost cult-ish loyalty, and the results are not only motivated developers, but insanely good software.

3. Learning New Things
Behavioral research indicates we’re happiest when we’re learning new skills or challenging old ones. A recent article cites a study by two University of Columbia researchers suggesting that workers would be happy to forgo as much as a 20% raise if it meant a job with more variety or one that required more skill. This research suggests that we are willing to be paid less for work that’s interesting, fun, and teaches us new skills.

This is why companies using Ruby can find experienced programmers willing to work for less than their typical salaries. The learning factor is huge when it comes to negotiating compensation.

Every developer I know loves playing with flashy new technologies. It was Perl and HTML in the mid-90s, ASP, PHP and Java in the late-90s, ASP.NET and XML a few years ago, and today it’s AJAX and Ruby (and in some circles ASP.NET 2.0). Give someone a chance to use these toys and they’ll not only be able to impress their friends, but fulfill that piece inside of them that needs to learn.

Keep a developer learning and they’ll be happy working in a windowless basement eating stale food pushed through a slot in the door. And they’ll never ask for a raise.

4. Exercising Creativity and Solving the Right Kind of Problems
Developers love a challenge. Without them we get bored, our minds wander, we balance our checkbook, check our email, hit Digg and Slashdot, read a few blogs, hit the water cooler, and see if any of our friends are online so we can once and for all settle the debate surrounding your uncle, the IDisposable interface, and that piece of toast shaped like the Virgin Mary.

I’ve watched developers on multiple occasions stay up until sunrise to solve a technical problem without being asked and without extra pay. The best developers are addicted to problem solving. Just drop a Sudoku in the middle of a group and watch them attack it.

Faced with the right type of challenge many developers will not stop until it’s fixed, especially if it requires a particularly creative solution. Faced with the wrong type of challenge and they’re back on instant messenger describing the toast.

The right type of challenge is a technical challenge that teaches a new skill, preferably one everyone’s talking about. One example could be: “Consume these five RSS feeds, aggregate the data, and display the headlines on a web page…and figure out how to use AJAX to make it cool.”

The wrong types of challenges are things like: “Fix that other guy’s code. You know, the one we didn’t fire because we were afraid he might cause problems. Well, he wrote a really crappy system and now we need to fix it and make it high-quality and maintainable. Oh, and you have until tomorrow.”

If your business doesn’t provide challenging work to developers, figure out how you can start. If there is no chance you’ll ever be able to provide challenging work, find developers who are into hygiene factors, because developers who need motivation factors won’t stay long.

5. Having a Voice
Developers are in the trenches, and they’re the first ones to know when a system or process is not working. One developer I spoke with told me:

“[I want] someone to listen to my problems and actually take them seriously. I’ve worked at a few places where more RAM, more hard disk space, or faster/dual CPUs were simply not a priority for the company, but it was incredibly aggravating to the point of impeding my work. At one place I worked, every time I wanted to compile the software I had to clear all my temporary files because I needed more disk space. Talk about asinine. Being forced to work using outdated technology is really frustrating.”

When a developer speaks, someone should listen. When several developers are saying the same thing, someone should listen and act…quickly.

6. Being Recognized for Hard Work
As engineers we love building things that impress ourselves and our friends. At least the ones who realize how hard it is to write a Perl compiler. From scratch. In FORTRAN. On a Vic 20.

Building something great is fun, but it’s much more fun when someone’s there to pat you on the back, throw you a party, sing your praises, or buy you a steak dinner. Most developers enjoy hearing praise and receiving recognition for hard work, but even the ones who don’t need it are somehow soured when they don’t receive it (or worse yet, someone else receives recognition for your work).

Recognition is one of Herzberg’s core motivation factors and it applies to software developers as much as the engineers originally interviewed.

7. Building Something that Matters
Even though we’re not medics in Bosnia or food carriers in Sudan, most people want to feel like we’re somehow doing our part to make the world a better place, both technologically and socially. Some of us might think we do it just for the sake of technology, but in the back of our minds we see ourselves as part of a grand scheme.

For instance, a friend of mine works for a financial company and cherishes every time they launch a product that helps the under-served financial community.

An Albertsons inventory software developer enjoys coming to work every day because his work ensures, via complex supply and demand algorithms, that the baby cereals are always available on the shelves.

Building something that matters makes an L.A. Times software engineer ecstatic that the trucks are now saving over 30% of their mileage and fuel costs due to his shortest path finding software implementation for newspaper delivery.

On the other hand, writing an interface to a buggy API that’ll be used a total of 15 times in the next year doesn’t seem like it matters much.

Copying and pasting an entire application and changing a bunch of labels isn’t as exciting as it might sound.

And hacking in a few more case statements in a ridiculously complex stored procedure in order to service yet another customer without creating a proper data structure somehow doesn’t seem to fulfill that part of us that wants to build something that matters.

8. Building Software without an Act of Congress
I was a contractor for three years starting in 2001, and during that time I built a ton of web applications. Since much of my development was off-site I became accustomed to writing software really quickly once we knew what to build. Another developer and I built insane amounts of software over the course of two years.

When I got my next full-time job it felt like I was dragging 50-pound weights. For every page I wanted to build I had to call a meeting with six people. Any change to the database required three approvals. It was nuts, and applications took 5x longer to build. Talk about frustrating.

The authority to make project decisions without calling a meeting is huge.

9. Having Few Legacy Constraints
No one likes developing against buggy interfaces, crappy code, and poorly-designed data models. Too many legacy constraints kill creativity, require an act of congress to modify, and generally sucks the fun out of building software (see several of the previous points for why this is bad).

If you have gobs of legacy liability, try to figure out a way to minimize its impact on future development. If you can’t, look for people who value hygiene factors, because motivation factor developers are not going to maintain the same poor-quality applications for very long.

Determining Your Score
Let’s face it, the bar has been set pretty low when it comes to motivating developers. How many companies can you think of that would score even as high as a 3?

Since this test hasn’t been administered to companies across the globe there’s no basis for comparison, but that’s where you come in. I’d like to do an informal survey so we can get an idea of how things are in the real world. Please post your company’s score in the comments (you don’t have to post the company name).

Most large companies I can think of would be lucky to score a 1. Google would probably score an 8 or a 9.

Wrap Up
If you’re a manager, when was the last time you asked your developers about these issues? If you’re a developer, when was the last time you respectfully raised one of these issues, providing examples and a possible solution?
If the answer is “a long time ago” then you have some work to do. Send this article to a few of your colleagues and start discussing how to enact change.

Digg this – Reddit – del.icio.us

If you liked this article you’ll also like my article Personality Traits of the Best Software Developers.

Thanks to Jeremy Lukensmeyer, Curtis Fields, Rick Kopitzke, Adnan Masood, Mike Taber, and a few others for their input into this article.

Special thanks to Mike Taber for reading a draft of this article.

This is part of an ongoing series centered on becoming a better software developer. For other posts in the series, see the Becoming a Better Developer heading in the right navigation.
–
In the book Joy at Work, the former CEO of an $8 billion energy company describes an experiment where he allowed a business development group to determine their own salaries over the course of two years.

The first year everyone chose their own salary but the numbers were kept private. The result was that the best people paid themselves too little, and the average and under-performing people paid themselves too much. This is in line with Paul Graham’s quote: “…people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.”

The next year the company set a total budget for the department’s salaries and repeated the exercise, except this time all of the employees had to submit their proposed pay to their colleagues for comment – not to be approved or rejected, simply for comment. When everything was said and done the department was only slightly over budget, and upon closer inspection the company determined one person was highly overpaid based on the salaries of his colleagues with similar abilities. This person had not listened to the feedback of his co-workers who had told him he was overpaying himself. After being informed of this, he reduced his salary and they met their budget.

What does this tell us?

First, people who think they are underpaid are probably not very good at what they do.

Second, people who think they are overpaid are probably pretty good.

Finally, the people you work with are the best judge of your abilities. Yes, even better than you.

If everyone at work thinks you’re abrasive, it’s time to take a serious look at your interpersonal style.

Have you ever seen yourself give a speech or teach a class? Every time I see footage of myself I’m shocked at how I look when I’m in front of a group. I’m appalled at my posture and nervous ticks I didn’t know I had.

Your colleagues are the video camera that can see your ability to write code, deal with stress, communicate your ideas, write clearly, and a whole slew of other things that are critical to our jobs as software developers. If you’re not using them as a resource you are overlooking a powerful tool that can help improve both your technical and non-technical abilities.

The moral: If you are genuinely interested in improving as a developer, ask your colleagues what they think of your abilities. Not just your development skills, but your writing skills, interpersonal style, ability to deal with stress, etc…

Then ask them again and tell them to be honest.

There comes a point in every person’s career when we have to offer criticism of someone else’s work. For software developers and managers this can be especially difficult since most programmers view the software they write as an extension of themselves, and take criticism of that software very personally.

We all know how to criticize, but the question is how to criticize well.

Be Specific
The #1 rule of good criticism is be specific.

In Freaknomics, Steven D. Levitt examined phrases in real estate listings that had a positive correlation on sale price (meaning a higher sale price), and ones that had a negative correlation (lower sale price). The results were as follows:

Higher Sale Price
granite
state of the art
corian
maple
gourmet
new
move in condition

Lower Sale Price
well maintained
fantastic
spacious
charming
!
great neighborhood
wonderful
immaculate

What you’ll notice is that higher sale prices resulted from being more specific. Tangible, real things like granite, corian, maple, new, outweigh ambiguous, possibly made-up things like fantastic, charming and wonderful.

And so it is with criticism. Telling someone their code is “total crap” is not helpful. Telling them they misspelled two variable names, have several place where they’ve repeated code, and they need error handling in all of their methods is much more helpful. It not only allows them to improve their current code, but perhaps it will help them out in the future, as well. They still may get mad, but that’s up to them.

It certainly takes more time to itemize mistakes, but it’s worth it.

Criticize the Code, Not the Person
If someone writes crappy code, talk about the code, not about the person’s ability to code. If someone doesn’t meet a deadline, talk about how that affected you and what needs to happen in the future, don’t talk about how the person is a complete slacker (at least not the first time you discuss it). Doing so will help keep the conversation less personal.

Be Constructive
Without much effort at all I can give you a list of negative things about Los Angeles: traffic, smog, too many people, and a distinct lack of trees.

I could also give you a list of bad things about the internet: spam, viruses, poorly-designed websites, and pornography. Just because I can point out a ton of negative things doesn’t mean that the internet is not worth your time, and doesn’t mean you shouldn’t live in L.A. For all the negatives there are tons of positives to outweigh them, at least for the 10 million people who live in L.A. County, or the 1 billion people on the internet.

It’s easy to be negative. It’s easy to come into a situation and complain. It’s easy to point out the flaws in everything (have you ever read the comments on Digg or Slashdot?). If you don’t have a suggested solution in mind it’s going to be difficult for people to respect your opinion. Someone who complains often will be ignored rather quickly.

Constructive critisism is helpful; venting just pisses people off. Before you criticize something stop to think if it really matters to you and needs to be improved, and make sure you’re talking to the person who can do something about it.

Developer Interview Questions: Testing Attention to Detail generated several comments that I’d like to address.

The first one is “I think that your questions test the trait on a superficial and…formal level…Give the candidate a problem which is prone to off-by-one errors; make sure that, if the proposed solution has the error, the candidate is aware of the possibility of the error and knows how to test. [Secondly, present a] problem with potential “special cases” – something along the lines of writing a function that calculates 1/x, but a little bit more complex, so it will not be that obvious.”

Those are two excellent questions for finding out if someone knows how to see errors in code, which is one kind of attention to detail.

The other kind of attention to detail is equally necessary and if you’re not interviewing for it, you’re hiring bad developers. Corporate development has tons of hoops you have to jump through to have a stable, standardized system. Things like naming conventions, a well-defined source control structure, coding standards, SQL standards, UI standards, etc…

Although unncessary in small projects, these hoops are what allow a group of 20+ developers to produce software with any manner of efficiency. Being able to recognize these hoops, understand them, and follow them all fit into the bucket of “non-code attention to detail,” which is a trait I am looking for when hiring for our team. This is why there aren’t any “find the bug in the code” questions in my list (although I do ask these types of questions in interviews).

Another comment was “These tests won’t show you if a candidate pay [sic] attention to details. They only show that, on that given moment, he was nervous. It is much better to talk to them, and bring this topic during conversation: ‘do you focus on details? are you more interested on general concepts?’ etc. Talking is much better than silly tests.”

Talking is absolutely much better than silly tests, but how can you ensure that someone is telling the truth? Here’s an example of what “talking” might look like:

Q: “Do you write good code?”
A: “Yes”

Q: “Do you show up for work on time?”
A: “Yes”

Q: “Do you focus on details?”
A: “Yes”

You haven’t learned anything from those answers. Most candidates try to give the “right” answer during an interview, which is why you have to ask questions that require knowledge to answer. Asking someone if they pay attention to detail is like asking “Can you write a method in C# that loops recursively through all the controls in a given parent control?” And taking their word for it.

On the “nervous” portion of that comment, I turn to Vince’s reply:

“I just don’t buy it. I need someone who can analyze problems and make decisions under pressure, because during the course of a multi-million dollar software project, pressure situations come up. But mostly, the line of thought bugs me because even though I’ve had plenty of interviews where I’ve been nervous, I’ve always been able to think the interview questions through and reason them out.”

Finally, Alexander said:

“[Question] #1. Ask why the company doesn’t already have a stored procedure in place for the join? Ask for an explanantion of the business process being supported to clarify if an inner join is really necessary. Finally, write the inner join using column numbers instead of names since the company hasn’t been able to normalize their spelling.

[Question] #2. Ask for a copy of all applicable HR documentation detailing the use of the information you’re about to provide. Insinuate that the company is using the hiring process as a cover for the collection of email addresses to sell to spammers.

[Question] #3. Ask for a copy of the company’s code creation procedure manual that documents this process (They do have this stuff written down don’t they?), read it back to the interviewer…”

Whew! Where to begin?

Regarding #1, I would indicate these are brand new tables and that the candidate has been asked to write the stored procedure. I would give the business justification if asked, but would definitely be wary of the candidate’s hubris. Finally, if the candidate used column numbers instead of names I would see it as a red flag. Most single answers won’t get you shown the door, but using column numbers is pretty close.

Regarding #2…Really?!

Regarding #3: Asking for the company’s code creation procedure manual is a great answer. I would take that as a sign of someone who knows about corporate development, and who is asking the right questions.

As a closing example, one of the questions I ask during interviews, since we work with Microsoft technologies, is “Tell me about the Microsoft Application Blocks.”

If someone has never heard of them are they immediately shown the door? No.

If someone has worked with every one of them do they instantly get an offer? No.

No question is an all-or-nothing game. Folks who evaluate people for a living through psychological tests, IQ tests, certification exams, college-entry exams, etc…always include multiple questions on a single topic in order to avoid false positives/negatives. The more data points you have, the more accurate your results. Keep this in mind as you interview.

If anything, this discussion has shown how difficult it is to test for a crucial trait like attention to detail.

From my new article How To Burn $6,540 a Week: Indecision and Software Development:

“These kinds of decisions come up constantly during development. Let’s say we have five developers working on a project and between them we encounter 10 in a week . If a monkey flipped a coin he’d choose the right answer half the time. Giving the manager the benefit of the doubt, let’s say he chooses correctly 60% of the time. 6 out of 10 times we break even, the other 4 we lose $420, for a total cost of $1,680 per week.

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week.

Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That’s a difference of $6,540 per week.

Give that a few minutes to sink in.”

You can read the full article here.

Indecision is a slow and painful death to both productivity and job satisfaction. A recent survey (pdf) found that three of the six main obstacles people face in performing their jobs are tied to decision making.

The sad part is that indecision is a management strategy for some (quite a few, according to this study which states “90% of Australians work in a negative workplace culture of blame, indecision and conformity.” We can only assume the numbers are similar around the world.)

In software development there are two kinds of indecision: developer and non-developer. Non-developers can be managers, internal users, marketing, or your CEO; whoever has a say in how your software will be built. For the sake of this article we’re going to look at non-developer indecision, and we’re going to refer to it, for ease of readability, as “management indecision.”

How Indecision Kills Productivity
What is the impact of management indecision on software development?

One study examined the disruptions caused by technology and resource failures in the workplace. They grouped the disruptions into two types: simple disruptions, and what they call “agenda benders.” Agenda benders “create a period of uncertainty and indecision, during which any existing plans are suspended; replanning may become difficult if not impossible. [Agenda benders] can, at worst, cause the entire day�s agenda to be abandoned, and at the very least, will leave it seriously bent out of shape.”

The study goes on to say:

“[When an agenda bender strikes] not only does she switch from doing high-priority tasks to filling in time with relative trivia, but she has no idea when her workstation will revive and must replan her day without adequate information. This uncertainty ultimately contributes to her inability to complete the �write specs � plan. Agenda benders appear to arise through a loss or breakdown of essential resources, for a period of significant but unpredictable length. Sometimes the missing resource is a person, e.g., a colleague who cannot be found for a vital meeting.” Or, I would add, information that cannot be obtained in a timely manner.

That being said, the impact of indecision is a potentially serious disruption to the development process due to a number of causes:

• The tendency for most people to freeze when faced with a question where they don’t have all the necessary information (described in the book How Would You Move Mount Fuji?)
• The effort it takes to note there’s a gap and come back to it once a decision has been made
• The mental exhaustion of feeling like you’re building a well-designed application that’s full of holes because no one will fill those holes with decisions

Why Developers Hate Indecision
If you’re a developer you know the frustration of not having the answers you need to keep working. You’ve probably experienced this more than you care to remember:

You start working on a new page, script, design, data model, etc… and realize the spec you’ve been given doesn’t have enough information for you to do your job. You walk over to your manager’s desk in search of an answer but he’s working on another issue and you have to wait.

You trudge back to your cube, realizing your deadline is not budging, but unable to continue your work until you have an answer. Your stress begins to increase and you resort to one of two things: sending an email and sitting on your hands until you get an answer (but looking busy, of course), or making the call yourself and living with the consequences. Either way your productivity is hammered and you’re now feeling the stress of having one more loose end on your mind.

“Surveys frequently rank managerial indecision as one of the top office torments, even above issues like low pay.” (source)

So why is it that no ones seems to make decisions?

Most of the time your question is a lower priority than the other tasks on a manager’s plate. Other times it’s due to corporate politics; no one wants to be responsible for a bad decision on a UI that doesn’t work for the Accounting team simply because he made a hasty decision and didn’t ask the accounting team what they wanted.

I genuinely believe that the majority or managers, internal users and yes, even CEOs, are not intentionally trying to see how much stress you can take before your head implodes. For better or worse, this is just one of the realities of working in a corporate environment.

Why Managers Should Hate Indecision: The True Cost
Summary so far: indecision is bad. It’s so bad, in fact, I maintain that most of the time a poor decision is better than no decision at all. This doesn’t hold true when launching nuclear missiles, performing heart surgery, or making software architecture decisions, but in most common software development scenarios it does. Let’s look at an example:

Developer: “The spec doesn’t say if we should show all products on this page, or only enabled products. What should I do?”

Manager: “Let’s call a meeting. We’ll get the four key people together, discuss it and come up with an answer. The soonest everyone can meet is next week.”

Developer: “But this is the core of the page. I need a decision to finish it.”

Manager: “Well, then, put it on hold and move on to something else.”

Now let’s examine the impact this has on the developer’s productivity and, ultimately, cost.

[Note: I know this next section will elicit a slew of comments like "Developers don't make that much/little," or "It would never take 2 hours to shift to another task." In the end I decided that a practical example, even one that requires some subjectivity, is such a helpful part of this discussion that it's worth including.]

To begin, the average salary of a Mid-level software developer in Los Angeles is $88,750 (Robert Half’s 2006 Salary Guide). With burden and overhead of 65% (this includes your benefits, employer’s portion of your social security and unemployment, the lights over your head, your phone, computer, software licenses and parking space) it comes out to around $146k, or just over $70 per hour (based on 2080 hours per year). A company employing a software developer making $88,750 pays approximately $70 for each hour they work, are sick, or on paid vacation.

In our example above, the first thing the developer has to do is participate in the meeting. Elapsed time: 1 hour (more if she has to prepare for the meeting). Cost: $70.

Next, she has to stop what she’s doing, add this to her to do list and come back to it in a week. Elapsed time: 2 hours to shift gears into another task then try to remember what she was doing when she comes back. Cost: $140.

After returning to the task after a week the developer is more likely to introduce additional bugs because of forgotten loose ends and a lack of familiarity with the code. Since “bug rates” per line of code varies widely this is difficult to measure. Let’s say that on an average day five bugs would show up in QA, but due to the disjointed nature of her development she introduces two additional bugs. The average cost to fix a bug based on this case study (careful, it’s a PDF) is $200. 2 x $200 = Cost: $400.

Finally, she now has another item cluttering her task list, she’s frustrated she can’t complete her work, she’s lost respect for her manager because he won’t make a decision, frustrated with her company for having to gather four people to decide how a single screen works, and she’s concerned she’s not going to remember all the details when she has to come back to the page in a week. Due to stress her productivity degrades 10% for the next 2 days. 16 hours x .10 = 1.6 hours = Cost: $112.

Total loss due to indecision: $70 + $140 + $400 + $112 = Total Cost: $822.

But wait, there are two other alternatives to this story.

One is that the manager makes a decision, and it’s the right one. In this case no additional time or money is wasted. Cost: $0.

The other alternative is that the manager makes the wrong decision. He sends an email to the parties involved indicating how they’ve decided to proceed, and finds out they screwed up. The developer has to go back and re-work the page after she’s completed it. Elapsed time: difficult to know, but assuming it’s a standard page we’re safe with an estimate of 6 hours. Cost: $420.

“Making a decision is a clear winner!” you think. But it gets worse.

These kinds of decisions come up constantly during development. Let’s say we have five developers working on a project and between them we encounter 10 in a week . If a monkey flipped a coin he’d choose the right answer half the time. Giving the manager the benefit of the doubt, let’s say he chooses correctly 60% of the time. 6 out of 10 times we break even, the other 4 we lose $420, for a total cost of $1,680 per week.

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week.

Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That’s a difference of $6,540 per week.

One approach will cost you almost five times as much as the other. Give that a few minutes to sink in.

Trying to Fix Things
Now that we’ve likened indecision to kicking puppies, terrorism and weapons of mass destruction, we’ve decided it’s bad for developers and for the company, and we’ve blamed everyone but the developer, what can someone do to move things along when the brakes are locked?

Here are three alternatives:

• Make it easy for someone to make the decision
• “Ambush” the decision makers
• Force a decision

Making it Easy
We can blame the managers all we want, but the bottom line is that leading a team is hard. As a former manager (who’s back in development by choice), the most common task I performed was making fast decisions with incomplete information. The not very surprising point is that the exact same situation that exhausts developers and kills productivity is the most difficult job of a manager, and the easiest to screw up.

The one thing I found most helpful when forced to make decisions without adequate information was to hear problems and solutions.

Here’s what I never wanted to hear from one of my developers: “Oh my gosh, we didn’t think that people would want to view the results on the blah blah page and now we don’t know what to do. Aaaah! We’re all gonna die!”

Here’s what I wanted to hear: “We didn’t think that people would want to view the results on the blah blah page. At this point we have two options: add the results grid, which is the right way to do it, and will take 2 days, or hack in a temporary table which will take 4 hours. Based on the schedule and where we are with out other tasks I think we should .”

What did the second developer just do? He gave me our best options. He turned this problem into a decision-making process, not a fact finding mission where I had to do recon to figure out the 10 possible approaches. Right away we could discuss pros and cons and make a decision quickly instead of wasting time back at the starting line. In this scenario I would likely suggest additional options, but starting with a base of 2 or 3 is a fabulous head start over the first developer, and makes me more likely to take the few minutes required to make the decision, rather than the 20 minutes needed for the first developer’s approach.

“Ambushing” the Decision Makers
This one is simple; if you need three people to make a decision, find out if they’re going to be in the same place at the same time and drop by. Or, better yet, have one of them walk with you to find the other two. Creating an impromptu meeting will only work with people who have serious buy-in to see your work succeed, or who are close to you in the org chart.

One other way is to try the ol‘ “drop by one and call the other” trick (this works best when you only need two people’s agreement). There’s no rule that specifies you have to wait until everyone’s in a meeting to make a decision (although this is likely the culture if you work at a big company). There are significant limitations to this approach, however, such as a lack of thorough discussion, visual aids, or a white board. If the topic is complex you are likely to receive blank stares and a look that says “I’ll see you at our meeting next week.”

Forcing a Decision
The third tool I’ve found useful is to force a decision. The phrase “We have to make a decision now or we’re going to lose x hours of time.” carries some weight with decision makers. Sure, they may put you off, but make a note that you said this and mention it again (as tactfully as possible) once the damage is done. Do this enough and someone may actually start listening to you.

It’s possible no one will listen to you, even after repeated warnings. In this case you have one of two choices: escalate the problem to your manager, your manager’s manager, the CEO, or whoever you think can address it, or think long and hard about how much your company really wants its software projects to succeed. If nothing changes after your best efforts, then you have little choice but to keep fighting, accept it, or move on.

The other way to force a decision is to make the decision yourself and do the work. People are less likely to change something that’s already been written. This is a back-handed way of getting things done, but it both makes your point and accomplishes something during the time you’re waiting. As with the other approaches, use this one with caution or you may find yourself pissing off the wrong people.

The Wrap Up
Indecision hurts productivity, job satisfaction, and the bottom line, and eliminating it should be on everyone’s agenda. Managers will likely be motivated by cost and morale; developers by the desire to meet their deadlines and avoid frustration.

Either way, we’re in the same boat. Hopefully someone will decide to steer.

Thanks to Mike Taber for reading a draft of this article.