We can't measure productivity?

Some people argue that measuring productivity is the wrong approach because people always find ways to subvert the system, that is, even if you measure everything and you know for sure what the objective is, people will find ways to have good scores while doing a lousy job.

Other people argue that measuring performance is impossible.I bet they would like it to be impossible, but it certainly is possible. Maybe not 100% accurate, but that is not my problem. Nothing is 100% accurate. Not even the distance between 2 objects if you use lasers to measure the distance, because errors are inherent to every measure. Sorry about that.

The point I'm tryign to make is that given the option of measuring and not measuring, you should measure, automatically, using tools, not humans. So that instantly you can know how people are doing. It sounds bizarre. Numbers can't tell yoy why people are having a problem, but they can tell you they are having a problem. And you can step in and help. That's what good managers are for.

About subverting the system

If people subvert the system, cal them in private and tell them you found out and you expect them not to do that again. If they lie, fire them.

If they do that again, fire them or, if they are in the middle of something important, wait for them to finish and fire them. Keeping people with a bad attitude only destroys the morale of the team.

Doing exactly the opposite

Some compnaies do the exact opposite. They keep the bad apples and fire the good apples.

Why? Why would anyone in their right mind do something like that?

Some companies are full of incompetent people. When somebody who is competent arrives, he usually finishes first his duties. He then is assigned with helping others and the rest just hates him. People say he is arrogant and he gets fired. Sometimes it is the other way around, but it doesn't matter, since he is just one guy. The incompetent guys are all over the place, remember?

What is the benefit for the manager? If the manager sees that the project is late, he may ask people to work till 11 pm everyday, to schedule meetings as 12:20 am, to harrass people who arrive late, to ask people to work on weekends, etc. Sometimes all this at the same time.

The benefit is that the manager puts all this in an Excel spreadsheet and then tells his manager that he saved the company $XXX becaus epeople worked for free, so he deserves a bonus...

So a manager that creates a sense of lack, a sense of "we need people to work more and I'm delivering it", even if people organized in a different way would produce more with less effort, obtains more income, while managers who are effective obtain nothing.

Martin Fowler is right. If you measure, you can show that you can produce 10 uses cases per day, while the industry average is 1.5 uses cases per week. But it doesn't matter, because where one use case is needed, analysts will produce 10 just to subvert the system, in which case the developers will do exactly the same amount of work, except that they had to read very boring and repetitive documents to understand something that could be said in just one use case.

How to tell

How can you tell if the company you are woking at has that little problem? Do they are the worst people they can find so that projects take longer than expected?

1. Do they make you an exam to asses how much you know before hiring you?
2. Do they provide courses?
3. Do they pay for your certifications?
4. Do they do review meetings or walk throughs over design documents and code?
5. Do they demo the products at the end of the development cycle?
6. Do they test throughly the code?

Serious companies devote half the time to the above activities. Ok, the exam probably is a one time chance to avoid you, but the rest should be standard part of your daily job. yet some companies want you to simply "code", as if that were a magic word that let the world revolve.

Success

Do you want to be succesful?

First, resolve meaningful problems.
Second, do no work unless you know exactly what is being requested. If nothing is clear, a meeting may help. Other times, you need to read documents. Other times you need to build screen mockups, and other times you need to build prototypes. No matter what, do not begin to "code", because code = cost. What you need is to deliver functionality with the least possible code.
Third, ask for real requirements. Countless times I've found requirements that were just made up. You always need to analyze the requirements to realize which are real and which are not possible or useless. Once this is done, 80% of the problem is solved.
Forth, number the requirements and sort them according to business value.
Fifth, imagine design decisions for every requirement. Less design decisions solving more requirements is the best design. Write down which requirements you think might change. This is really important and you will not find out from the beggining, but you will improve with time.
Sixth, implement those design decisions as prototypes, to make sure they are implementable and there are no strange border cases you didn't know beforehand.
Septh, work with business use cases instead of user use cases. Business use cases do not consider the internals of your company, but only the clients. Your company is only a solid block. this should give you ideas for the clients to attend themselves on your site. Once this is done, divide them in user use cases.
Eight, draw context diagrams to see that every operation enters and leaves the system.
Ninth, integrate the prototypes.
Tenth, avoid repetition both in the design and in the code.

I could go on and on. Use SVN, LuntBuild, ant, JUnit, Selenium, etc. Use abstraction layers. Do not allow information to be lost. Permissions and performance are customized at the end. Etc.

That has nothing to do with success

The only way to be successful is to promote what you are doing. It doesn't matter if your project is a piece of fecal matter. You need to explain why your project is so hot and so cool, and this apparent contradiction means your project rocks. Better than anything!

Trust me on this one... Most managers have no idea about technology. They fundamentally do not understand, they just live in a world of Excel spreadsheets, where information is delayed at least 3 weeks, but might be more. It could be 3 years for example, especially if they follow RUP.

So rule #1: Promote yourself and your product internally. Explain why techinically is cool and explain why economically it is cool.

And rule #2: PPTs are so nice, but the real numbers are in Excel. You need to affect those numbers. In order to do that you have 2 options:

1. Option number 1 is to lie and say everything is so expensive that 1 use case per month is really fast, so beat it. I can't recommand this option, it is too risky and not very well rewarded. At the end you know you will fail miserably, for too many reasons to mention, but imagine when people find out you lied.

2. Option nuber 2 is to not lie but tell the truth. Press the pedal to the metal and let managers know exactly what you are doing, if the project compiles, etc. EVERYTHING! If you show just a number, they will be tempted to ask you to improve it, but if they see more than 10 numbers, they won't know what to ask. Show them all the data so that they can't make any decision, so that you would be safe. This is important because later you need to defend what you are doing now.

At the end you will have all the information and you will be able to make informed decisions on ho to work. You will detect causes. That is important, much more important than the small risk that managers will get in the way.