Undoing things is also unnatural to many of us, and it can be hard to un-genericize (specialize) code that was made too generic in the first place; so I try hard to not write code that isn't needed in the first place, sometimes fighting with myself. But it's easier to follow that rule yourself than explain it to someone else in a code review!
This week, we'll be sharing a four part series on software design flaws, featuring and . Today, in part one, they discuss the first Flaw of Software Design, "Writing Code that isn't Needed," from Max's book Code Simplicity: The Fundamentals of Software.
You can also view the full presentation: http://goo.gl/h73nY3
I mean, it's all good advice. But it's like other high level maxims of software development (or any art, I suspect); they boil down to "do just enough X, not too much or too little", where X is "designing for the future" or "refactoring as you go" or "optimizing for the present" or whatnot. The trick is in knowing what is too much and what is too little. It's true many journeyman (journeyperson? medium-experienced) programmers tend to err on the side of too much framework and abstraction, and beginning programmers tend to err on the side of rigid special cases, but those are generalizations and may not apply to individuals. So advice of the form "you're probably doing X too much, when in doubt do it less" (or the opposite) may have semi decent results on a certain target audience, but...
Not that I know how to teach the subtle art of taste, nor do I have crystal balls to sell.
I do love seeing a CL that's all red though.