My new software quality metric is: If it looks like I can write it in half a day, it’s good software.
Of course I can’t write it in half a day. But have a look at the following numbers for the original version of my current project and the current version (all numbers generated by generated using David A. Wheeler’s ‘SLOCCount’).
Original version
SLOC Directory SLOC-by-Language (Sorted)
6509 src java=6509
Totals grouped by language (dominant language first):
java: 6509 (100.00%)
Total Physical Source Lines of Code (SLOC) = 6,509
Development Effort Estimate, Person-Years (Person-Months) = 1.43 (17.16) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.61 (7.36) (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 2.33
Total Estimated Cost to Develop = $ 193,122 (average salary = $56,286/year, overhead = 2.40).
Current version
SLOC Directory SLOC-by-Language (Sorted)
2306 src java=2306
Totals grouped by language (dominant language first):
java: 2306 (100.00%)
Total Physical Source Lines of Code (SLOC) = 2,306
Development Effort Estimate, Person-Years (Person-Months) = 0.48 (5.77) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.41 (4.87) (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 1.19
Total Estimated Cost to Develop = $ 64,960 (average salary = $56,286/year, overhead = 2.40).
So it appears that I’ve decimated the source base. And I have. I’ve culled two thirds of the source code and that has had a similar effect to the dollar value of the source base. The original soucebase had a gourad lighting model and an OpenGL renderer that I currently don’t have, but I think my version of the codebase is much cleaner….and I think I could rewrite my codebase in half a day.
I’ll repeat, of course I couldn’t rewrite it in half a day, but the codebase looks simple. Maybe I’ve worked with the source long enough to target it at the right level of abstraction. Which has lead me to the conclusion that a simple looking codebase can have more value than a complicated codebase, even if the metrics seem otherwise.
I agree. One of the greatest joys of being a developer is taking your finished product, and then trying to refactor the code into an almost human-readable format. This has the effects of reducing the source size, allowing the code to be extended much easier, and clearing up your own ideas of how the source works.
If I get to the point where the code looks extremely simple, yet still works, then I’m happy – I love to read powerful code that is simply written, as it is a sign of an uncluttered mind. One thing that I really detest is fugly obfuscated code, where comments are an absolute necessity because there is no abstraction.
I agree that the simplest code is usually the best code, as debugging it is certainly cheaper and working with a small precise codebase is desirable.
So I think any tool that judges value based on locs is going to be fairly flawed
All programming languages are the same…
I overheard this one in the coffee room in work and it reminded of a table I had seen recently in "Code Complete".
Someone studied a lot of programming languages measuring productivity, read about it in this paper An Empirical Study of 7 Pro