First of all, you really need one of these.

Second of all, my general philosophical argument in favour of code brevity goes something like this: you can represent a program as a mapping from inputs to outputs. Said mapping could be a simple table... well, perhaps not so simple, depending on how many inputs we're talking about, but the concept holds. The point is that no computation aside from lookup is really strictly necessary: it's really the ultimate space-vs.-time tradeoff. The entire point of programming is not to produce these mapping tables, but to create the methdology for doing so - to codify the underlying rules of the system. So the discipline of programming is fundamentally just data compression (though, as some have shown, this line of reasoning can be taken too far).

From a purely pragmatic point of view, though, how can your coworkers argue against improved comprehension, limited points of failure (and repair), better understanding of the flow of control and data, and fewer chances for program errors?

I'm no code poet myself, though I aspire to one day be, but it seems to me that the prime goals of a program are to be (a) as correct as possible, (b) as clear as possible, and (c) as short as possible. I suppose a business environment would add the fourth goal, (d) written as quickly as possible.

It seems like you're bang on the money, though. Code bloat works against almost all of these goals simultaneously. Where's the win?

You do know about XP (eXtreme Programming), don't you? Excuse the cheesy name; it's a collection of programming and management practices that address, among other things, projects that suffer from bloated, poorly designed code.

Programmers vaguely know that large volumes of hastily written code will be a bit more difficult to maintain than more carefully written code, but I think they under-estimate just how expensive maintenance on crap code is. But then perhaps that's the only sort of programming they know, and they don't realise how much faster they could go if they changed their habits. Also, if they don't have to maintain their own code, then there's no incentive for them to produce maintainable code (they don't have to swim in their own shit).

Duplicated code is the root of all evil (as is highly coupled code, and premature optimisation...) If your colleagues and/or managers are too ignorant to see the damage done by their style of development (i.e. their bad habits) then you need to educate them. There's a huge volume of information on c2.com, and refactoring.com is a great book for indentifying and fixing poor code. These resources might help you get "traction".

You could explain to you colleagues that if the code was initially developed test-first, with automated unit tests, then that would (1) improve the quality of the code, which in turn would (2) make subsequent maintenance much cheaper. Of course, if a project manager decides that producing lots of poorly designed and poorly tested code as fast as possible is more important (time-to-market pressure), then fine, but make them aware of the trade-off: any subsequent changes will be very expensive. Not taking the time to keep your code clean is a form of technical debt; you're borrowing against future development effort to get something done faster now. You have to pay it off; if you don't you'll eventually be unable to meet the "interested payments" - code inertia.

I'm reminded of your post on Programmer Productivity: I felt my productivity plateau a few years ago (perhaps this is the point at which many programmers get bored and leave the profession or move into management), and then I discovered XP. As I've adopted their practices (i.e. improved my habits), I think the quality and speed of my work has improved. But then, perhaps you already have good habits, and there really is no further for you to go.

What about the old reward and punishment routine? I'd say that it's very unlikely that your programmers will change their behavior on their own. The way they work now is fine by them, I'd go so far as to say that the way they work now is being rewarded. Is producing a lot of code regarded as a sign of being a code stud? Your comments imply that it might be. Are the people who write more lines looked up to, are stats maintained about how many lines each person wrote? If you're keeping track of lines per programmer, even if no formal reward is associated with it, then I suggest you stop. Instead track something associated with the behavior you want to promote. One thing would be to track number of tests created and have some target for number of tests per lines of code, the more code written the more tests required. Of course it's very difficult to measure the amount of reuse someone introduces :) Another angle is to make it easier to do the right thing. If you use Java then IntelliJ IDEA or Eclipse with their refactoring support make it easier to reuse than to copy and paste. Instead of copying the code for a method from one subclass to another it's easier to automatically move the method to the superclass.

Introducing XP is a way of adding a set of rewards and punishments that favour a particular style of development. I'd take a good look at the programming culture in your shop and see how it could be tweaked so that reuse becomes seen, and rewarded, as more important than lines of code produced.

Well, I am all for the brevity of code. There is no need to have 20 lines if you can do that in 10. It's like mathematics at school ... you could do a sum with 5 lines or 15 lines - result was always the same - but our teacher used to repeat over and over again that the longer versions do not have the right to exist.