See this:

http://stackoverflow.com/questions/1674915/how-to-teach-someone-that-less-is-more

TDD can also help you with “getting the dang thing to work”. I try my hardest too keep my feature-envy at bay, and not add code that isn’t going to be used, or that’s not pulling it’s own weight, which usually makes me get to working code faster.

In the end it comes down to personal style. For me it’s all about making the dang thing work given specific set of constraints. Finding these constraints is usually the tough part.

This line of thought easily leads to ideas that have been encapsulated in the fifth generation programming languages. By definition these languages should be able to generate a solution based on a given set of constraints as it happens. This works well for certain AI problems (CSP and such). It does not appear to be a workable solution for any “real” problems, however.

Related to this problem I have been pondering about code generation based on tests. It’s probably easy enough to come up with simple tools to generate classes and simple methods with right return values but the whole thing breaks down at one specific point: tests can cover only a limited set of the functionality desired. To paraphrase “Absence of proof is not proof of absence.”.

Still, even in a limited form, some sort of interactive code generation/validation system might be a fun thing to play around with. At least it should give some boilerplate code that can be then expanded to a proper solution.

Regardless, I do think that the right layering can make the difference between a ball-of-mud architecture, and something well designed. But, I also think that TDD really has a lot to do with designing. Just as DSLs allow you to write your code in the domain of the problem, TDD allows you to write tests that use the code as you’d like it to be, instead of letting it transform to whatever it feels like. That’s a major part of design – knowing how you want your interfaces and classes to behave, and then making sure they do so.

If you are dealing with inadequate “grammar” it becomes ankward to solve problems on lower level. Sometimes the programming language chosen constrains this. There might not be an easy way to bypass the limitations set by the language.

DSLs try to solve this in their own way. Essentially the idea is that instead of modeling the problem using classes, you come up with a language using constructs pertinent to the domain. I haven’t played around with DSLs but there’s something very intriguing about the idea.

TDD is not a design methodology by definition. Extensions such as BDD and ATDD take it closer to the user but I don’t think even those solve the problem of design. They do help you to keep track of quantitative constraints. I consider this a very important thing.

Design is something you should sort out separate of actual implementation while keeping given constraints in mind. I suppose the YAGNI principle should help in this. A proper design should be as lean as possible on the very highest level. You should be able to build the complexity on the lower levels.

I know it’s hard, sometimes impossible, to come up with a good design at first. Prototyping and tracer bullet type approaches may provide a good starting point in this case.

So just to summarize I think your very point is correct. In my view the way to “less code” consists of proper design (software as an onion ) and a disciplined implementation that states the constrains set on it and conforms them. In terms of LOC a nice design might actually cause you to have more code than a “flat” one. That’s not the point, however. On the very high level you code should be extremely simple and straightforward. Let the lower levels hide the complexity.