Just a few things I have picked up after too damn long programming and running programmers.

1. Get used to the idea that no more than 20% of the total effort will be spent in actual coding. If you think the project takes 20 hours to write, then expect to spend 100 hours between writing code, specs, meetings, bug resolution, acceptance testing, deployment, etc.

2. Always secure a subject matter expert on the customer's side. This is the one person to go to that knows how the system has to work, down to minutiae like business rules, conventions, assumptions, nuisances, etc. Don't assume your project manager on the customer side is your subject matter expert. Don't rely on your own team for this, you need the subject matter expert from the customer side.

3. Educate your team on the politics of compromise. A lot of time is spent when the customer asks for A, then the PM turns around and tells the programmers and the programmers go up in arms for whatever reason. Get the used to the idea that saying no by itself is not acceptable. Instead, be prepared to suggest alternate approaches. If the customer asks for A and your team says well, that won't work because of C, but we are sure that we can go around that by doing D, then the customer gets the problem dealt with, and won't feel like the programmers are dictating the product, which is wrong. The customer dictates the product.

4. Teach your programmers that they are in for the money. It is OK to have pride in craftsmanship. If you have it, flaunt it, but don't make the customer feel like an idiot just because whatever it is that the customer asks is stupid, or it is beneath you. If you want to program with your conscience, go program for free for an open source project. It is OK for programmers to tell you what is wrong, but force them to always come up with a plan B. That's what they get paid for.

5. Don't let your programmers rely on testers as an excuse for being sloppy. If a tester keeps returning the same piece of code, then you need to call the programmer to the carpet and ask why he/she keeps submitting it as fixed when it isn't. The job of the testers is to find the HARD bugs, not to bounce things back because of typos or sloppy work.

6. Keep your customers away from your testers and programmers. The customer should be talking to the project manager. If things are complex, the customer may designate people to deal with the testers and programmers directly, but only within a very narrow scope. Sure, they can talk to the programmers, but only to clarify a feature, or to show how to recreate a bug. Nobody should be trying to talk to your programmers and injecting work into the project.

7. I personally like to add a feature freeze before the 75% mark. After the 75% mark for programming, no new features can be added without revising the schedule, deliverables, project costs, etc.

8. Teach your programmers that customers don't see the product from the inside, the way a programmer does. A programmer spends 20 hours writing back end code, then slaps a front end just so it works without trying to make it pretty. The programmer sees it as a functional means to test 21 hours of work. The customer sees it as 21 hours into the task the UI looks like crap. It is not the customer's fault, it is just the way things are.

9. If there's a pad on the schedule, don't tell the programmers about it. If they run out of time, make a big deal that their asses are on the line, then give them a little bit of the pad. If you spoil your programmers into relying on the pad, nothing will ever get done on time, and you will lose your profit margins.

10. Odds are that you are on fixed cost basis. If yes, burn it into your team's head so they understand that every extra hour worked in the project it means the company is making less, so they need to be really good at managing their time. And stop the hero mentality because in many cases, the guy that is working 12 hours a day is because he is screwing around for at least four. There are not many programmers out there that can put 12 billable hours a day and produce the code to prove it. Also, force them to handle their timesheets religiously, because that is the only way that you will know for sure how far you are into your budget.

Asker's Rating:

Permalink | Report