Fog Creek Software
Discussion Board




Bad code - My problem or not

what do you think about the following:

we have around 20 developers. I started to take a look at the quality of their code and I'm very very dissapointed. so called "experienced" guys make the most basic mistakes a programmer can do, but basically most of their code is a non commented copy & paste code. On one project I even searched for a 5-line code pattern and found 39 occurances. Withing 15 minutes of code review I saw enough to stop viewing their code more.

basically my problem is that I'm not involved in those projects however it makes me very angry as I see this as one of the reason our company is not professional. the PM of the project knows about it but do not care.

our CEO cares about issues like this at least verbally however if there is a time to act in that case his support is not real.

so I'm just embarrased what to do. I can try to involve myself into these projects but I do not want to teach others for the minimal level. I can also stay away and forget it, but next time those people will be within my group.

Any suggestions?

na
Wednesday, January 22, 2003

What's your position in the company?  That's an important thing to know.

And when you say they're going to be in your group later, will you have a position of authority?

anon
Wednesday, January 22, 2003

The problem here is cost!

Ask your self if you gave each developer as much time as they wanted on a task, how long would things take?

In the ideal company, taking as much time as the programmer needs is in fact the BEST WAY to ensure quality. This is why projects with loose deadlines actually get completed sooner! (yup, it is true, projects with no, or less of a deadline actually get completed in less time!).

Most managers simply think that if you give someone 20 hours to do a 10 hour task, that the person will in fact use 20 hours to do the job. This in fact is wrong thinking. Most developers actually know exactly when the code or product is JUST RIGHT. There is that additional urge to tinker, but that really is not the norm. The best approach is not to think short term, and I got to get this done by Friday. If you get it done by Friday, and cut corners, you accomplish nothing! You also damage the project if you drop coding standards down to a crappy level *just* to meet a deadline.

It is no stranger that the Countries like Japan that think long term also are known for high quality products. Thus, the motivation is to do things correctly , and not necessary meet a silly deadline.

However, first rate products usually have a first rate price. Many, if not most people think that  a Mercedes Benz car is over priced. This is totally different idea then the cost of the product being out of reach. I am not talking about the fact that average Joe can not afford the product. In other words, I am not taking about affordability, I am talking about what that product will cost in the marketplace.

Thus, to me, a Mercies Benz is NOT overpriced (the top dog high end models most certainly are!!). However, their basic products are not overpriced at all. They simply are very good cars, and you have to pay a very good price for that kind of product.

If your company is selling a product with a  Chevrolet price, then you can in general only afford to do Chevrolet work. However, even today, basic products in the market place have high levels of quality.

If you can afford to spend more time on your software development process, then you will get better products. However, you will also need to charge better prices! You also *will* be able to charge better prices with high quality!!

Those developers should be given more time, and they will naturally reach that high level of quality of work. It is not that you don’t need deadlines, but they must be given adequate time to do the best job.

It should be noted that those same counties that don’t think in terms of daily, or weekly deadlines are also known for very high productivity also! In other words, letting the development time expand to get the job done right will actually improve the bottom line.

If the people in your company are not interested in improving the software development process, then either you have to change them, or move on.  Or simply live with a company will produce sub-standard products. Eventually this means that your prices in the Market place will also be sub-standard. There is simply no way to avoid this fact.

Thus, the one thing you really do want to avoid is cutting too many corners in the quality of the code and development. The reason is of course is that cutting too much will cause the product to be too poor, and in fact cost the company more! In other words, poor code and designs will cost more!

Most managers believe that chopping away that idea of the “extra” time that developers need is the key to being a good manager. A good manger will NOT chop time, but chop features. In other words, what you keep in the product must be first rate!

So, I actually believe that giving the developers some guidelines and more time to improve their work is the best solution. If the work culture at your company is NOT open to the above concepts, then it is up to you to start that change!

You have to be come the change master!

Why not start down the path of allowing these people to start writing better code?

(note I said allow,..not force or "get" ! A good manger provides that environment that ALLOWS these people to do first rate work. You don't force them to do good work...you *allow* them to!).

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Wednesday, January 22, 2003

Only one way to lead....  only one...

just one.....

of all the ways people might think there may be... to lead, that is..  if fact... there is only one....

BY EXAMPLE.

Wait until people start saying 'Hey, that's a great widget, can we use it ?'.  Wait until they seek your council before you give it. 

Rule 1 of the Jedi.

Try and learn where you can, give praise and act suprised and impressed when these incompetants do manage to do something well.

They have learned that there is reward for finnishing early, there is no reward for finnishing it well, show them there _IS_ reward from quality.  Even simple praise from the new lowly  positioned guy can be an amazing motivator.

Anway, if that fails, strap on your armour and ride out to meet them, If this be the end, make such an end of it worthy of rememberance.

Braid_ged The White.  (previously The Grey).

braid_ged
Wednesday, January 22, 2003

> Wait until they seek your council before you give it.

I too have learned that "you can lead a horse to water but you can't make it drink".

I used to show everyone all the new classes I'd made, or a neat regular expression I'd devised. But people don't like to be told what to do, so now I wait until someone asks before I tell anything.

Matthew Lock
Thursday, January 23, 2003

I'm one of the 4 PMs in the company, but I do not have the real power to choose the people I want to work with.

na
Thursday, January 23, 2003

If other people are screwing up and they're not your responsibility, it isn't your problem.

This doesn't mean you shouldn't do anything about it, it means you have to go about it indirectly. If their code doesn't look well designed, there's probably several things you can see that will cause it to fail. Report them as bugs. (Of course, the danger then is that a bad development team look at the bugs, decide they're all low priority because they're not reported by a paying customer, and never fix them....)

What I've discovered is there are two sort of development teams in the world. The first pride themselves on doing things well, getting stuff out on time, and having the kudos of customer praise. The second just do development cause it pays well and couldn't give a monkeys about quality just as long as they can all have a good laugh and earn some money.

Sounds like you've got the second variety.

Better than being unemployed...
Thursday, January 23, 2003


I would use an aggressive managerial path. Write a proposal, use words like "downsizing", "revenue", "savings". Fire useless people. Get 5 superstars, and start refactoring things (do not rewrite). Evaluate how much money you are saving to your organization, and _post it_, write evaluating docs and make sure of mention that you have saved the company lot of bucks.

Not a "nice" way, but certainly effective.

Leonardo Herrera
Friday, January 24, 2003

Leonardo, to do that, you need some sort of executive type powers. A mere PM does not have the power to fire his own staff without jumping through hoops, let alone touch another PM's. Sometimes, we can't just bomb our way through. We got to slowly snipe all the little things one by one to steer things around. And even that might not be possible. It is also important to notice that while the quality of the work is being critiqued, the fact of the matter is that it is functional. Management in most companies are expert at being ostriches, at the first indication of trouble, they bury their heads in the sand thinking it will go away.

Alex
Sunday, January 26, 2003

Good call, Leonardo.  Instead of helping lift people up or teaching them to do things the right way, just fire a slew of them to make the others nervous.  _Investing_ in your employees is so outmoded.  I'd say you're a shoo-in for CEO.

Kyralessa
Thursday, January 30, 2003

*  Recent Topics

*  Fog Creek Home