How to teach someone that less is more?

Question

I work in a shop where the mentality/culture does not have any sense of the concept of "less being more" (i.e. the less code you have to maintain, the more flexible you can be, and the faster you can fulfill customer requests). There's also a strong copy-and-paste mentality around here.

The backend code base being used is written in rather verbose C++ (the code base is 1.5 GB), and I have inherited some Javascript/HTML/CSS code from one of these C++ programmers that I have been tasked with "cleaning it up". The code was written to quickly appease some customers and is therefore not production level code (dispite the fact that it is being used in production-level systems).

The code has alot of document.write statements contained in <script> tags scattered throughout the html documents. It is some very obtrusive Javascript.

It also contains many style attributes in the actual HTML code itself rather than in a logical place like a stylesheet.

Also nobody seems to know what the code actually does, it's not commented, and this is why I've been tasked with cleaning up the old code rather than just trying to re-write it into a smaller, faster, more maintainable code base.

May I please have some advice on how to drive home the concept that "your should code smarter and smaller, rather than code more"?

Update

I've just added another question related to this one and @Joel's Answer bellow.

Answer 1

Hire good developers and get rid of the bad ones.

My experience shows it is next to impossible to explain people that they're doing it wrong. They will only mode when a major breakdown happens, not until that. They will only see your "initiatives" as extra costs but not as a good investment.

Answer 2

You should challenge your own assumptions. You state that

You should code smarter and smaller, rather than code more.

Why do you think that's true?

If you can answer this question, then you know how to explain it to someone else.

Answer 3

Introduce the concept of 'Technical Debt'. Just throw the term around now and then, along with a line about being smarter about accepting it, and let them figure out what you mean by it.

The point here is that while the idea of a term like "Technical Debt" should be obvious, it's also purposefully vague. You don't want to find yourself explaining what it is to any of the other developers; they should already know.

The idea is to subtly encourage them to explore the issues on their own, because that's really what you need to happen. As much as I like (and voted for) @Bill's answer, you'll never "win" this debate. It's just not how human brains work; people, even and especially programmers, are surprsingingly illogical about such things.

Eventually it will become a mechanism you can use to push back against bad implementation ideas in a way the other developers will accept: "It seems like this approach is taking on a lot of Technical Debt. Are we prepared for that?"

Answer 4

Personally, I think the fact that you have been tasked with cleaning up that mess is enough of a message. Even more so when you can prove that the time (read: money) spent on cleaning up the bad code, is more than the time that would've been spent writing good code in the first place.

To most managers, money speaks the loudest. To fellow developers, well, the one sure way to drive home the message is to have them maintain their own code. If they don't have to maintain it, there's simply no way you'll ever get programmers to change their ugly coding practices.

Edit: As Piskvor (in the comments to this answer) stated, responsibility is they keyword I was looking for. If programmers aren't responsible for maintaining and/or extending the code they're writing, it'll be extremely hard, if not impossible, to get them to accept better coding practices.

Answer 5

The only way for your company to get out of this rut is to think that if there isn't enough time to do it correctly, then there isn't enough time to do it at all. Spend more time doing it correctly the first time. Push the deadline back. Your company is spending a lot of money maintaining old code, when you can be creating features for other products.

Answer 6

There's an interesting article on this topic from Jason Fried of 37signals where he discusses this very concept (as well as other topics on running a successful business).

It's a good read.

http://37signals.com/svn/posts/1998-link-jason-fried-the-way-i-work

Answer 7

Make them write unit tests for it. Insist on 100% (or even 95%) coverage. Insist all tests pass on check-in.

I find that, while coding is lots of fun, testing takes the fun out of it and really makes you think about whether you want to add that feature.

Answer 8

I know this type of situation. I've also had some daunting tasks which involved "cleaning up" other people's work. Some of those people weren't familiar with the environment and they wrote really ugly code.

My recommendation is the following: in the places where there is the most of the code smell, convince your boss and co-workers that it is so screwed up, that it actually takes LESS time to rewrite than to figure out how it works, what it does and how could it be fixed. After that, writing the new code should be straightforward, and then you can delete the obsolete code.