What If There Were 7 Principles For Software Development?

Yesterday I got asked What are my principles for sofware development ? Not just my strategy and tactics, but the high level rules that determined them. A bit of a challenge eh ?.  Uber-rules or something like that.

Kept it to 7, more than that and it's not principles. How's this ?

1. Publicly maintained software trumps privately maintained software.
2. Clean design trumps just about any other good feature.
3. Generated code trumps hand written crapola.
4. Code that doesn't have to be written trumps generated code.
5. Obviousness trumps documentation.
6. Simlicity trumps complexity.
7. Testing trumps acting surprised.

Like anyone else in software, I'm a hired gun so I rarely get to work by my principles, more often than not I'm asked to set them aside in favor of the hiring entity's principles or lack thereof. So here they are, ignored or not.

Publicly maintained software trumps privately maintained software

Open source can be a religious affair, which misses the point. Open source is great when it works because it can mean hundreds and thousands of people exercising the code and working out the bugs.

Because I have an ego the size of a house (doesn't any good developer?) I want to write my own instead of using someone elses. The problem with this approach has nothing to do with religious arguments. It is purely a practical issue. It leaves you with the job of code maintenance, which is (at best) a very stupid job to have.

Clean design trumps just about any other good feature

Zillions of programmers working with and arguing about the failed EJB design for years and years is a perfect example of crappy design taking it's toll. Spring Framework (for example) cleans up in the marketplace because it's a cleaner, dumber, simpler design. EJBs is a crappy design ? Well, only if you compare the design to what was really needed.

Most developers spend most of their time on projects that are soon axed or never even deployed. We do what we are told to do, and the results end up being questionable. We reinvent because the design was never clean enough to warrant the subsequent implementation.

Generated code trumps hand written crapola

If I am hand writing miles of code to keep M, V, and C layers linked together to the same entities, for example, then I am either by hand or by Control C, Control V basically doing copy and paste operations. The argument against copy and pasting misses the point.  If it must be done at all (itself a very good question) then it should at least be generated code ( such as Grails ).

This keeps things consistent, even if it's still somewhat questionable.

Code that doesn't have to be written trumps generated code

It seems ludicrous to say that the best developer writes the least code, but when isn't that true ?

My own personal hero and long time mentor Michael Nash puts it best. "If I have to generate code in the first place, that is a really good indication that my design is AFUd."

Once again Grails is nice example, in it's use of skaffolding. I can generate the code if I must modify the default action, or just use skaffolding if no mods are required.

Obviousness trumps documentation

Extreme Programmers sometimes say "All comments are lies" but that is just one of dozens of sub-rules to this underlying principle.

Yes, document where you must, just as we must code where no other alternative exists.

But documentation and instructions and every other like form is a symptom of the problem, not the cure. The problem is that something wasn't obvious enough in the first place. The Ipod comes with a manual but I doubt anyone has ever looked at it.

Simlicity trumps complexity

Speaking of extrapolating from the obvious, my new personal hero is Rod Johnson of Spring Framework for his 2004 coining of the phrase "the complexity industry".  This two word phrase says it all. Who among us doesn't try to create a complexity industry with ourselves at the center ?

Testing trumps acting surprised

It is fun to watch all the arguments over testing approaches, be it unit testing, test first, true unit testing etc etc. The real focus is not testing, but "the act surprised method" which has been the elephant in the living room for decades.

There is no surprise. If I didn't test for it, I don't get to act surprised.

Summary

I love to go to conferences and watch people spar about languages and platforms and frameworks and disciplines and other issues that are downstream to these principles. Very smart guys, and very smart points. And they are important points, let's make the best choice in each of these areas, please.

These and maybe other principles that I left out, trump lower level concerns such as languages and platforms and frameworks. Or maybe the principles advise of which to use.

If I want to always be the best developer I can be at all times, I might filter first by these principles.

What do you think I missed ?