Managers Views Of Developers

There are a lot of opinions in the wiki about the shortcomings and widespread incompetence of software development managers. Managers are portrayed as uneducated, technically clueless meddlers who do nothing but restrict talented developers from getting anything done.

Having spent some time with managers (and pretending to be one myself), I thought I'd share some of the opinions that managers have of developers. Rest assured that they are as unimpressed with developers' abilities as developers are of theirs.

Developers may be interested in knowing these opinions, and in thinking about to what extent these views may contain some truth.

Developers are completely incompetent when it comes to making estimates. They rely upon nothing but gut feel. Ask three different developers to estimate a task, and you'll get three widely ranging estimates. Many developers will just tell you what they think you want to hear if they do want to do the work, or will provide a wildly inflated estimate if they really don't want to do the work.
Developers have no rational way to measure progress. They'll work on something for a week, and say it is 90% finished and will take another day to complete. Then a week later, it is still 90% finished, and will take a just a CuplaDays to complete. And the week after that, it is 80% finished and needs a few more days. If you ask them to explain, they just mumble something about "unexpected issues". Many developers can give no indication of progress whatsoever, saying only "It will be done whenever it's done. Stop asking me about it.".
Developers don't take their commitments seriously. As deadlines slip, features get cut, bugs are found, and money is lost, developers just laugh. Developers accept no responsibility for such events; it's somehow all the manager's fault.
Developers see themselves as geniuses, deserving of special treatment. They will only do things that are "fun", and complain whenever they have to do any work. Dealing with their childish whining and temper tantrums takes up most of a manager's time. Their arrogance and airs of superiority are detrimental to the morale of the lesser mortals who have to work with them.
Developers are unwilling to accept suggestions or criticism from managers or from customers regarding the product. We are supposed to be impressed by and grateful for whatever crap the developers deign to deliver to us. Then, after ignoring or dismissing our suggestions and criticism, developers will then say it is our fault if the product doesn't do what we want.
Developers are not adaptable to change. Whenever business conditions change, requiring a change in the project, they either refuse to change or tell you that everything has to be thrown away and rewritten from scratch. And they blame the managers personally for the changing conditions.
Most developers are completely oblivious to the fact that the purpose of this company is to make money, in both the short and long run. They have no understanding of basic business concepts such as cash flows, profits, assets, budgets, marketing, etc. They seem to think that their jobs exist only to give them something "cool" to do, or to expand the horizons of computer science.
Developers think they don't have to follow the same rules that the rest of us do. So the rest of us have to take care of all the paperwork and administrative tasks that developers refuse to do themselves.
Developers think that "No" means "Don't get caught."
Developers cannot say "I don't know." They will make up something on the spot and state it with absolute certainty rather than let anyone believe they are less than omniscient.
For some bizarre reason, developers insist they can do an almost-infinite amount of work during one weekend. But they never do.

Sounds about right.

Developers have no rational way to measure progress. They'll work on something for a week, and say it is 90% finished. Then a week later, it is still 90% finished. And the week after that, it is 85% finished. If you ask them to explain, they just mumble something about "unexpected issues".

That's because "percent complete" of a task is a ridiculous progress metric. Tasks have only three states: not started, started but not finished, and finished. It is reasonable to ask for an estimate of the remaining (uninterrupted) time to complete a task (i.e., ETC - see Completion Headroom in http://c2.com/ppr/episodes.html), but a much better progress metric is percentage of use cases / scenarios that pass acceptance tests. Use case scenarios are either implemented, or they are not. (For more discussion on this, see PercentCompletedMyth)

Developers don't take their commitments seriously. As deadlines slip, features get cut, bugs are found, and money gets lost, developers just laugh. Developers accept no responsibility for such events.

Any developer who presents that attitude is not showing TrueProfessionalism, and doesn't deserve to be part of your team.

Developers see themselves as geniuses, deserving of special treatment. They will only do things that are "fun", and complain whenever they have to do any work. Dealing with their childish whining and temper tantrums takes up most of a manager's time.

This, sadly, is a characteristic of professionally immature developers. Hire professionally mature ones.

Developers are unwilling to accept suggestions or criticism from managers or from customers regarding the product. We are supposed to be impressed by and grateful for whatever crap the developers deign to deliver to us.

Technology serves business. Period. RealValue is defined by the customer, not the developer. Inside of that, developers can take pride in their SoftwareCraftsmanship - that is what motivates them, as AlistairCockburn insightfully describes in AgileSoftwareDevelopment.

Developers are not adaptable to change. Whenever business conditions change, requiring a change in the project, they either refuse to change or start sabotaging the project. And they personally blame the managers for the changing conditions.

Developers take pride in contribution to business success. Change nullifies contribution-in-progress.

Most developers seem completely oblivious to the fact that the purpose of this company is to make money. They seem to think that their jobs exist only to give them something "cool" to do or to expand the horizons of computer science.

That's too broad a brush. Experienced developers know that technology serves business.

Developers think they don't have to follow the same rules that the rest of us do. So the rest of us have to take care of all the paperwork and administrative tasks that developers refuse to do themselves.

It is the job of LeaderShip (management, if you must) to establish and uphold the culture of an organization or community. Good citizenship should be expected of everyone.

BTW, I really like KenMcKelvey's comments on GoodItManager. --RandyStafford (a developer-turned-manager-turned-developer-turned-TechnicalLead, who tries to see both sides)

You are truly naive if you think we work for customers. We work for ourselves and customers mostly get in the way. --AnonymousDonor

Speak for yourself, AnonymousDonor. I beg to differ. "Ourselves" don't remunerate us for our work - our customers/employers do. We participate in an economy. It is possible to work for your customers/employers, and for the software development profession, and for yourself / your family, all at the same time. --RS

You said the customer is the only definer of RealValue and we are left with just admiring our craftmanship. This strikes me as a SlaveMentality?. I agree completely with the rest of your statement. I just don't see UsWorkers? as being passive WorkerBees?. Until development is reduced to mass production, this will be the case. --AnonymousDonor

True. I brought my own baggage viz. RealValue. I guess I'd forgotten about the dream of doing something artistic :) Best Regards, --RS

The problem is developers who spend too much time admiring their craftmanship. The original statement is correct, software is a tool to be used by others to provide value. Developers need to take pride in helping others accomplish something. That is not slavery, but rather the nature of software development.

Pretty much "right on target" with all the complaints.

But I'll comment anyway.

Developers have no rational way to measure progress. They'll work on something for a week, and say it is 90% finished. Then a week later, it is still 90% finished. And the week after that, it is 85% finished. If you ask them to explain, they just mumble something about "unexpected issues".

True, that last 20% can take 80% of the time. And unexpected things occur. Sometimes people lie to you, to get a low estimate. Then, in reality, things don't turn out that way.

Developers don't take their commitments seriously. As deadlines slip, features get cut, bugs are found, and money is lost, developers just laugh. Developers accept no responsibility for such events.

I said it would take two weeks of full time effort, without distractions. Six weeks later, after 5 "fire drills," several panics, and plenty of distractions brought on by the people who extracted the two week estimate from me, I get blamed for the things they did to me. And people wonder why I have such a "bad attitude."

A manager's response to this would be that any estimate that assumes no distractions nor interruptions is not a realistic estimate. If there is a significant atypical interruption, then make a note of it when they try to blame you. But the standard level of chaos should be assumed whenever making estimates, and enough padding should be included to offset any minor atypical distractions. --KrisJohnson

Absolutely correct, Kris. As they say, however, the devil is in the details. I've seen managers assign wishful levels of time commitment to developers on the basis of "Well, those three months during the time when <previous project> had just gone in and it required a lot of support, but it won't be such a drain now". I've seen developers commit to too much because they don't really know how much time they really spend on other tasks. Then there's the case of being committed to multiple efforts but not being realistic about the inefficiency of task switching. If someone is assigned to two projects and is given a third, that doesn't mean it's possible to divide up X hours by three instead of two -- there must be some awareness of the decreased efficiency of that. The disagreements over how much time "padding" should be allowed are because there is a great deal of subjectivity. One nice thing about ProjectVelocity and short iterations is that it makes is possible to get real, usable information about how long it takes to do something. --StevenNewton

There are real problems here. But none of them will actually be fixed until we all grow up and stop looking for a scape goat to blame. It is possible to make software development more predictable. But it's not easy. And it's a cooperative effort: No one person can accomplish it, no matter how much you blame them.

Developers see themselves as geniuses, [...].

We are! ;-> -- Wile E. Coyote Supra-Genius

Developers don't take their commitments seriously. As deadlines slip, features get cut, bugs are found, and money is lost, developers just laugh. Developers accept no responsibility for such events.

Counterpoint - I have been given a set of requirements, and we have estimated the time, and the manager has developed a schedule, and I start work. Halfway through, I am told that I am needed to work on a critical customer problem, which ends up consuming a week of my time - does the schedule get pushed out? No!

Another example - I was part of a project that had a schedule. When 2/3s of the staff on that project left, was the schedule adjusted? No!

Don't tell me that developers aren't living up to their end - they've been burned too many times to blindly trust management. --PeteHardie, being quite the cynic.

I can relate. When a deadline becomes, through various means, unrealistic - I mean even working 80 hours per week unrealistic - and it gets to the point where I have to seriously reduce the quality of my work to meet a deadline, those are the times when I question my choice of profession, start thinking of going back to school, etc. That's my primary signal nowadays to get out.

That's aside from the fact that developers often bring such deadline crunches on themselves by not pushing back with a united front. When the chips are down, most managers I know are very good at dividing and conquering, usually along the lines of the implied are-you-a-team-player tactic (sure I am, except when it comes to suicide pacts).

Those people on the team who are scared to lose their jobs cave (people with kids and house payments, in my experience), and the others on the team who have spines don't want to let down the ones who caved. So the scared spineless engineering team works 80 hour weeks and then the code is crap and after the deadline people start leaving. Repeat repeat repeat.

Oh, yeah? If you can't stand up to a PHB's face and say, "CountTheHands," you're sunk. Period. A-Double-Plus for contracting consultant types, since we get paid based on results.

Unfortunately not all of life is as clear cut as this (hey, I wish it were). Sometimes you have friends on the team you'd rather not sell out when they assent to working 80-hour weeks. Sometimes the management is good enough at PrisonersDilemma tactics that you don't realize what's happening until too late. This is where experience comes in - you steer the thing early on by either taking a hand in helping out if your management is reasonable, or having the foresight to get out if they're not. In any case, the real victory when you head off a problem like this before it happens, not in being dramatic and confrontational when it comes to a head. Most of the time that backs management into a corner where from now on they want you all out, or you're just left hung out to dry. Lose-lose.

Contracting is one solution, especially for the engineer. When I'm paid by the hour I could really care less how screwed up an organization is. And you get paid indirectly based on results - you get paid directly based on how many hours you work, sometimes there's a big difference between those two things.

Hourly rates are all well and good, but don't take into account things such as completion bonuses (which can be a significant part of the overall value of a contract), customer satisfaction (which can seriously affect repeat business), and even the survival of the project (thusly negating all other considerations). A consultant is not an employee and can't think or act like one. Our responsibility to the client extends to telling him the real nature of the problems he has either generated for himself or slipped into by inaction.

If a manager is unsatisfied with the maturity level and professionalism of his developers, then perhaps he needs to hire more mature and professional developers. (?)

Of course, they are much more expensive than the younger ones. Ah! But that's the rub then, eh? YouGetWhatYouPayFor! - BillZimmerly

Another option is to train the developers in maturity and professionalism. A revolving door of hirings and firings is merely a naive belief that "the grass is always greener on the other side of the fence"; that the next programming hire will some how be better than the last.

I've seen a lot of reference here to "Mature Programmer", not to be confused with "Manure Programmer". What is the definition of a MatureProgrammer?

One that has a strong smell?

I like this, but I can't prevent myself from getting prickly about some of them. This is slightly silly, so don't take it too seriously:

Developers are completely incompetent when it comes to making estimates.
- Don't ask us to do unreasonable things like estimate how long it will take to complete a task that we've never done before. Every time a developer faces a task, it's almost invariably the first time they've done it before. Otherwise, it's just gluing old bits of applicable code (in which case it usually takes much, MUCH less time and a developer will say so). It's not reasonable to ask, so don't expect a reasonable answer.
- This seems to agree with the original statement. The response says, developers are not competent to make scheduling predictions, so don't ask. The underlying rationale for a software task, however, is that the predicted cost of developing a software solution is less than the predicted cost of relying on a manual solution. This prediction is the basis for a company's decision to fund or continue to fund software development. One cannot absolve developers of the responsibility of making these predictions and then later complain that the decisions were made by someone outside of development.
Developers don't take their commitments seriously. As deadlines slip, features get cut, bugs are found, and money is lost, developers just laugh.
- They laugh if they feel it's not their fault. Usually, these deadlines are based off the estimates that Developers are asked to give (see GuessTheNumber). More often than not in the business world, Managers then snip a bit off the edges. Throw in the paperwork factor and you have a recipe for disaster. Most developers laugh as a defense mechanism, working with such uncertainty would drive most people crazy.
Developers see themselves as geniuses, deserving of special treatment. They will only do things that are "fun", and complain whenever they have to do any work.
- This is a fundamental misunderstanding. Developers want to do RealWork?. This means coding, you know, actually making the product. All Engineers hate the "work" that tends to get lumped on them by the bureaucratic engine of big business. Most of the time, it's totally ridiculous anyways ("Tell you in advance where my bug is??! If I knew, the bug wouldn't be there in the first place, just give me change rights to the source tree!"). Some developers are geniuses anyways. Computer Science isn't science. It's cowboy art with a hint of engineering and a generous portion of math.
- The "explanation" seems to be a restatement of the original criticism. What is the definition of "Real Work"? Most often it is what the developer wants to do rather than what others expect the developer to do.
Developers are unwilling to accept suggestions or criticism from managers or from customers regarding the product. We are supposed to be impressed by and grateful for whatever crap the developers deign to deliver to us. Then, after ignoring or dismissing our suggestions and criticism, developers will then say it is our fault if the product doesn't do what we want.
- Probably, YouGotWhatYouAskedFor?. If you say you want a bridge, and we build a bridge just like you describe, but 6 months down the line you say, "No no no. What I really meant was I wanted a Suspension Bridge!" then you're going to have to pay more money while we rebuild the bridge. Maybe we planned for this and made some provisions, maybe not. It's a guessing game. Mostly, we're very flexible, but we don't have crystal balls and magic spells that let us see the future. This is why we're starting to ask for onsite customers.
Most developers are completely oblivious to the fact that the purpose of this company is to make money, in both the short and long run. They have no understanding of basic business concepts such as cash flows, profits, assets, budgets, marketing, etc. They seem to think that their jobs exist only to give them something "cool" to do, or to expand the horizons of computer science.
- Most companies seem completely oblivious to the fact that the purpose of this company is to provide a quality product at the agreed-upon price. They have no understanding of the fact their ponderous supply of red tape greatly inhibits our ability to provide a product customers want. We're not adverse to keeping a paper trail, but some companies take it way out of hand. *cough, no names mentioned but see my employer*.
Developers think they don't have to follow the same rules that the rest of us do. So the rest of us have to take care of all the paperwork and administrative tasks that developers refuse to do themselves.
- Exactly what is your job anyway? My job description says Developer. If the Manager can't provide meaningful input on the project, then pretty much all they have to do is paperwork. Remember our end goal here is a product, and we probably goofed on the schedule. How many people out there have technically savvy managers who can help in the project design or testing? Anyone? You in the back maybe?
- This response seems to be a restatement of the original criticism. Declaring managers as incompetent does not absolve "Developers" from doing the required paperwork and administrative tasks. It is this narrow definition of "Developer" that is at the heart of the initial complaint.
  - Developers rail against the rules because in many cases, the rules are ones that make their jobs impossible. Decisions about which source control system to use are made by Executives during their golf games with vendors, instead of by the people who will actually use the system; Desktops are locked down by IT, and they won't allow the installation of needful things requested by developers; and so on.
    - Developers rail against the rules because they didn't make them. In my experience they rail against the rules even if other developers (in another group made them). See GeeksHateAuthority
  - Ah, the secret is out. Just last week at our meeting of the Delightful Managers Down The Lane, we had that very discussion. Our jobs depend upon the successful completion of projects, so we were discussing the most effective hurdles we could throw at the developers. I have heard rumors, though, of another group, the Managers Next Door, who tend to view selection of a source control system as very low on the list of things that affect the success of a project. There are things far more important to spend time on than the selection of a source control system. If the developers cannot come to consensus rather quickly, then I will just mandate one and move on to more important matters. If there is an existing system that has been successfully used by others, then I fail to see the value spending any time at all reviewing the past decision.
    - Well, that's where a lot of the problem lies. Maybe the existing system sucks and people use it with great relucatance, and that's why the want something new. You don't know, because you dismiss the choice as not important. If the choice of source control isn't important to you, you have no business making the decision - let the people who DO care, ie, the people who actually have to use it every day make the choice. I have personally watched this happen more than once. As a case in point, I'm currently using a source control product called Harvest, which seems to basically be a less feature rich version of Visual Source Safe. Nobody here likes it. Nobody really understands it. We don't have many of the advantages of using source control because the product is cumbersome and painful so people work around it instead of with it. It cost an enormous amount of money. Why exactly should I not be upset about this?
    - (sarcasm noted, and nifty pop culture reference, btw) I wasn't speaking about a case where the developers were deadlocked, but rather a case where the decision was made by someone with no technical experience, and made for reasons other than schedule, such as "My golfing buddy sells it", or "My company rival uses X, so we can't use X"
Developers think that "No" means "Don't get caught."
- So do most people.
Developers cannot say "I don't know." They will make up something on the spot and state it with absolute certainty rather than let anyone believe they are less than omniscient.
- Oddly, I associate this trait with management and especially salespeople.
- Damn straight. We wouldn't want you getting uppity now.
For some bizarre reason, developers insist they can do an almost-infinite amount of work during one weekend. But they never do.
- Maybe I'll get to it next weekend.

See GoodItManager, HelpYourManager, EstimationWoes

CategoryEmployment