Thursday, June 21, 2007

Developer Weasel Words

As a development manager or project manager, you here a lot of weasel words and excuses from your staff or from external consultants who are trying to hose you into believing things are better than they are. In many cases, developers use these phrases to even convince themselves that things are better than they are, resulting in chronic late delivery and poor quality.

So beware the following phrases from your teams:
  • It should work: this usually means that it doesn't. It also means that it was probably not tested properly as the result is current undetermined. The word "should" should be taken out every developer's vocabulary - it either does or it doesn't.
  • I just need: beware of that word "just". Its a belittling word meant to make things smaller than they are. Just take the phrase "I just need to write this component" to be "I need to write this component" and already the magnitude of the work involved grows. Developers tend to be chronic under-estimators and the use of the word "just" is a sign of that mentality.
  • Almost done: this is also a weasel word. When a developer tells you things are "almost done" ask for the specific tasks that are left over immediately. In addition, keep in mind that projects do not progress linearly - the last 10% is always about 40-50% of the work of the total project. I've seen projects that are chronically late be "almost done" for 3 months.
  • It was tested: this also usually means it that wasn't tested properly. Ask for a test plan and the specific tests that were done. If the developer cannot produce these with sufficient evidence that PROVES that it was tested, then it wasn't tested.
  • It must be an environment/configuration/deployment problem: this may be actually true, but it usually points to a larger stability problem. If you cannot build and deploy reliably then why would you have confidence that the code works?
  • If things go smoothly: this I hear a lot, e.g. if we don't hit any snags then we can be done by Friday. Guess what - you're likelihood of hitting a "snag" by next Friday is probably high and given the lack of risk based management, the team has probably got no mitigation or contingency strategy. Then next week, you'll hear the next phrase in our list, "Yes, it could have been done if it weren't for that Snag we had".
  • Yes, but, as in "Yes it can be done, but": this means it cannot be done. Tell your staff to just come clean and say, "No it cannot be done". Another variant on this is, "Yes it could have been done, if it weren't for marketing, requirements, technical risk, etc." This simply shows that your developers work in an idealistic world where things never go wrong.
  • We'll make up the time at the end: if you're already late by the end of requirements, you're likely going to be even later by the end if you simply keep going on the same track. In my experience, teams don't dramatically faster as they hit their stride. Even if there is some efficiency, its nowhere enough to make up for lost time.
  • I've got it done, but I need to build a few more components for you to be able to see it: then its not done! Encourage show and tells, code reviews, unit tests, etc. so that code is visible as soon as possible. Use slicing models so that you can see pieces of the application in weeks, not months. In addition, code that isn't checked in should never be counted - that means that someone cannot build it sufficiently to share it. It only counts if you can verify it. Ideally, its not "done" unless there are sufficient unit tests, a build script, and a document that someone walking into the code repository could check out the project run a build and have all the unit tests pass. Then the code is done - anything less is mythical.
  • I've got it done - I just need to integrate it: The word "Integrate" is a big weasel word. Think of a web service that adds two numbers together. The algorithm is one line of code. But the integration work is huge. In addition, integration usually means the first time that disparate teams are bringing code together which is always cause for issues. Don't under-estimate the integration, especially in today's world of distributing computing, web services, etc.
  • It Worked on my Machine!: programmers use this excuse to downplay a bug. The reality is actually the opposite - it means that you have an intermittent bug which is by far the worst kind of bug to have in your application. You want bugs to fail quickly and consistently - any variant such as "That's Weird", "That didn't happen yesterday", "That must be a data problem", etc. is admitting you have a bug that cannot be easily duplicated.

My recommendations to reduce the amount of excuse making from your team:

  • Encourage a culture of honesty and team work: You get these excuses when developers are hiding things, and sometimes this is because you've created a culture that encourages hiding because you don't want an honest answer.
  • Be ruthless with your quality and talent standards: don't excuse poor talent, bad management or chronic late delivery. If you create a culture where talent isn't rewarded the bar isn't kept high then you'll be excusing the team to continually strive for excellence.
  • Expect more than just code: measure performance based on estimation, quality, delivery and team work as well as pure code quality. If you have a developer who produces great code but cannot deliver on time then that's not a great developer.
  • Increase visibility and shrink delivery cycles: if you have to show your work on a constant basis and deliver on 2 week iteration cycles, your excuses tend to go away. You either deliver or you get found out pretty quickly. Use show and tells, code reviews and continuous integration to see what people are doing on a constant basis.
  • Don't give half credit for 50% done - its either done or not done: If your tasks cannot be managed this way, then you should split up your tasks until you can work this way.
  • Establish what "Done" really means: for example, at a minimum "Done" should mean checked into source code control and able to build into the current branch. If you're doing Test Driven Development, it should also mean all tests run successfully. If you have specific performance criteria, then its not "Done" until the performance tests pass.
  • Use counting techniques to measure wherever possible: this is a great suggestion from McConnell's book on estimation. The more you can count in units, the more accurate you estimation. So if you can count the number of pages, web services, objects, databases, tables, stored procedures, tasks, etc. that are left to accomplish then you can measure them more easily than if its a big blob of work. If your requirements aren't well defined enough to count objects, e.g. you don't know how many web pages you're building in your web site, then you're really not in a position to estimate your ship date.
  • Don't sucker, manipulate or bully your team: If as a project manager, you resort to traditional management tactics such as playing games, being political, establishing a blame culture, or bullying your team you'll lose your credibility and simply encourage lying. A tortured prisoner will tell you anything you want to hear - the same goes with development teams.

If you have a project that operates in the open, has a culture of honesty and establishes a high performance bar, you'll find that peer pressure as well as some overall guidance will get risks, problems and bugs out in the open. If when you discover these problems people work as a team to fix them instead of blaming each other then every problem solved becomes a victory and not a blame opportunity. You'll get better answers and improved morale on the team as you set clearer performance expectations.

10 comments:

Richard said...

Developers will often respond with "That's Weird" or "That didn't happen yesterday" because they find it hard to articulate an explanation for the bug while standing in front of their peers and employer.

They don't say things like this to "weasel" their way out. 90% of the time they will go back to their workstation and fix the bug within 1 minute. These things happen, nobody is perfect.

Anonymous said...

"Developers tend to be chronic under-estimators"
Quite the opposite, its the moronic managers that work to a time line rather than reality that underestimate.

Craig Andrews said...

A lot of what you consider "weasel words" are sometimes the result of the developer trying to be honest. Take "If things go smoothly ..." for example; this is a legitimate thing to say if the develop in question has dependencies on other parts of a system, but no visibility of control of that dependency. If something goes amiss, it might not show, and he is highlighting that fact.

"Yes, but ..." is a similar one. Sometimes a proposal can work, but it requires consideration of one or more side effects. Would you rather he just said "Yes" and then implemented it without questioning those side effects? Or conversely, would you rather he said "No" and miss out on the entire feature because you were unwilling to consider the options?

Quite often the developers use cagey language simply *Because* they know the manager will think they are just trying to weasel out of work. If your developers feel that you don't trust them and think they are all basically dishonest, maybe some of the problems you are seeing aren't through "weasel words" from the developer, but from the attitude you portray to them?

Michael Schaffner. said...

The "It worked on my machine" one is my pet peeve. It's gotten to the point everyone in IT and not just the developers use it. Call the HelpDesk and report problems accessing the internet and your likely to get a "It works fine on my machine" as if the problem was all in my head.

I like your recommendations. They are excellent, especially the part about not bullying them. Forcing them to give you the answer you want to hear won't make it happen.

Mike

Tedd said...

Wow... I feel bad for the developers that have to work on your team.

Christopher Woodill said...

Re. Articulating issues - this is what developers are being asked to do, or else simply say "I don't know." On my team, developers are encouraged to say "I don't know" without pressure or manipulation from me. In addition, I would expect to see a plan to get to a solution, e.g. "I dont know but here is what we're going to do to find out."

Re. Developers being under-estimators, this is not simply me saying this. This is based on pretty strong research. See Steve McConnell's book on estimation or his various blog posts on this issue - the software industry in general has a problem with estimation and developers are part of that cycle.

Re. Developers on my team - I encourage developers (or anyone else for that matter) to have an honest approach to risk, options, etc. This allows them to stop second-guessing their communication, e.g. to put in covering language, euphamism, optimistic deadlines, etc. Read my last recommendations - if you have a managerial culture of manipulation, dishonesty and politics then you are going to definately get more "weasel words" from any team you are managing.

Bill said...

You say you know programmers always underestimate ... why do you ask them? Do you know from experience the multiplier for each of your workers? Did you ever press someone to decrease an estimate?

No one in the airplane business would ever ask an engineer how long something was going to take. Where it's important, they have estimaters.

Regards,
Bill Drissel

spurton said...

Hillarious, I used a few of these the other day. Turned out, it wasn't my problem and it did work on my local machine because something happened on the staging server which caused the problem. Not my code.

Goes to show you, sometimes weasel excuses are the truth.

"Cause I'm the weasel" - Pauly Shore

Christopher Woodill said...

Re. Bill's comment on professional estimators, I think this is a great idea especially for projects that are quantifiable. The tricky part is the debate in software development is whether software is really engineering at all, e.g. is software coding a systematic repeatable act or is it more like a craft or an artwork or story writing? Can you estimate how long it takes to write a song?

In general, my experience says that its somewhere in the middle - certainly we have not matured as an industry to be able to estimate in anywhere near certainty.

Re. Weasel words actually happening. My response as a manager is basically it may be true that it happened on your machine, but its not really a reasonable excuse. In the case where it actually was the case, then its still within the perview of your job to solve the problem (which it sounds like you did). In addition, environment issues are always possible but if they're happening on a regular basis then something's probably not quite right. They do happen despite the best attempt to preserve the environment - I have seen bugs because one version of Oracle was on 9.216 and one was on 9.210.

Managers are hiring developers to solve problems. That's what you're paid to do. And in most cases, 90% of coding is pretty straight forward and 10% is ridiculously difficult. But that's the nature of the development business. So as a manager, I can sympathize when I'm hearing such things from my team and help try to solve the problem, but I don't want the team using it as a reason to give up on a problem. A really good developer is one who likes the 10% of the work that is ridiculously difficult - these are the ones you want on your team.

federica said...

and... "beauty that works"?
Is it considered weasel word?