Lesscode Is Not About Quantity
By Alex Bunardzic under Talk on 28. September 2005A number of people that are making the painful transition to lesscode seem to misunderstand the underlying philosophy of the movement. For some reason, some of them get hung up on the quantity (read: number of lines of code). But, by doing that, I’m afraid they are completely missing the boat.
Let me state it in no uncertain terms: lesscode is not about the number of lines of code. In other words, we can revisit some legacy app and rewrite it so that in the end it results in dramatically smaller amount of lines of code, and still not produce an app that would qualify as being ‘lesscode’ worthy.
So if not the number of lines of code metric, what then would qualify an app as being a bona fide lesscode product?
The thing that often gets overlooked when we’re talking about the lesscode discipline is that there is a qualitative aspect to it. Yes, the most obvious factor that hits us upon inspecting a typical lesscode app is the drastically reduced number of lines of code, but that phenomenon is merely the outcome of some deeper, less visible causes and conditions underlying the discipline. We need to now expose and examine those causes and conditions (and stop fixating on mere symptoms):
Je ne sais quoi (“I know not what”) – the indefinable quality. Christopher Alexander calls it Quality Without A Name
This sounds like a bailout answer; however, it’s actually very true. Lesscode is qualified by something that is utterly satisfying, yet no one can put their finger on it.Language choice – the language we choose for writing the code determines how we think about designing and programming. Choosing to write code in Assembler or in COBOL would not be very conducive to producing the lesscode app that would be utterly satisfying.
Smart Servant – if the platform/language of our choice is very needy, very fussy and expects us to exert exorbitant amounts of effort just to keep it from throwing a fit any time something changes, that situation will not be very conducive to producing a lesscode worthy product.
What we really need if we are to practice the discipline of lesscode is a Smart Servant product. What that means is that such a product must be very non-intrusive and very supportive of our flakey short term memory. The only realistic way to develop a truly lesscode app is to work in an environment that minimizes the cognitive friction.
Nico:
It’s “Je ne sais quoi” :)
comment at 28. September 2005
Mike Champion:
“Je ne sais quoi” is a bit of a copout … I hope it’s not just an “omygod, the damned VISUAL BASIC people are stealing our meme!” reaction from y’all :-)
But seriously, I agree that the Quality Without A Name we seem to roughly agree about is not about minimizing LOC per se. I think it’s more along the lines of:
Elegance: Simplicity and power combined. A language/API with thousands and thousands of pre-packaged little widgets that could be strung together arbitrarily to get a lot of work done in a few LOC would be powerful, but it would be harder to figure out which little widget to use than to just write the code in an elegant language.
A core set of non-leaky abstractions: I definitely got this feeling the first time I played with Python. Watching the LINQ / XLInq stuff evolve did give me an appreciation for how hard this is to create.
Conceptual Integrity: (Read THE MYTHICAL MAN MONTH if you don’t understand this term). I think the “Je ne sais quoi” loss for words often comes from the sense of understanding without explicit learning that a system with real conceptual integrity provides.
comment at 28. September 2005
Laurent Szyster:
Because programming is both litterature and mathematic, elegance and style do indeed matter.
For instance, compare the original Medusa sources with the first version of Twisted or look for its sources in Zope 3. Or search the web for Greg Stein’s qp_xml.py and find out how old the ElemenTree model actually is.
There are good reasons why Medusa has not changed much since it was written and why Zope or Twisted API are so unstable. These are the same good reasons why Greg’s unorthodox XML model was finally adopted as a defacto general purpose API for CPython.
Elegance, Style and … Application.
There is no “je ne sais quoi” for me: it is the quality of the code’s purpose. It is the ultimate metric of a source code library, adoption by programmers for an application.
For software mathematical elegance is simplicity of design. Programming styles translate as sources with a real “lever effect”, that get the job done with less code. Yet programs must also be usefull, rewarding to read and libraries must achieve a practical purpose.
Asyncore.py and qp_xml.py are the perfect examples of smaller, simpler sources that to do more of something usefull. They are elegant, well articulated and have many different applications.
In conclusion, less code is a good metric for programming practical and powerfull applications.
Programmers, who like acronyms, called that rule KISS.
It takes an educated fool to like Java’s sophistication, and most programmers learn to use C, C++, ObjectiveC, Perl, Lisp, Python or Assembler if they can match its simplicity. And apply them without superstitions and prejudices.
You can write with style an elegant application of Excel in VisualBasic.
As long as it does more with less code.
comment at 28. September 2005
colinramsay.co.uk:
Lesscode and MonoRail
I think I know now why my initial impressions of MonoRail weren’t very good. While they were adhering to the letter of the Ruby On Rails ideas, they weren’t really getting with the spirit. And example would be the MonoRail…
trackback at 29. September 2005
Ryan Tomayko:
Nice post, Alex.
If I had to pick a defining trait for the lesscode mindset, it would be that you are forced to consider simplicity above all the other ilities. It’s throwing your hands up in the air in the realization that you can have perfect scalability, reliability, extensibility, generality, modifiability, etc. and it means fuck-all if the design does not meet a basic level of simplicity and understandability.
This is in sharp contrast to what a lot of people outside of the discipline will tell you (e.g. marketing, management, tech press, analyst firms, etc.) and perhaps that is responsible for putting us off the track.
I get the feeling from reading various early computing literature (SICP, IETF works, Peter Gabriel, etc.) that this was once a well understood aspect of software design. At some point it fell out of the discipline or was pushed down the priority list. lesscode is all about making simplicity cool again - it requires accepting that we’ve made a huge mistake in allowing our ambitions to get ahead of our discipline and then trying to do something about it.
comment at 29. September 2005
Ryan Tomayko:
Michael Champion said:
It’s quite likely many of the contributers here were “VISUAL BASIC people” at one time or another. VB is not what it once was.
comment at 29. September 2005
james governor:
smart servant - Patrick Dryden and Jonathan Eunice coined a couple of nice terms in that regard when I was at Illuminata
client-servant or client-savant…
regarding the lesscode mindset, i would say a commitment to modularity is inherent. thus lesscode, because you don’t have to swallow the whole damn ball of toenails.
comment at 29. September 2005
xtian:
Ryan said:
And, given the LINQ stuff, hopefully soon it won’t be what it once is!
comment at 29. September 2005
Bob Dionne:
“I get the feeling from reading various early computing literature (SICP, IETF works, Peter Gabriel, etc.) that this was once a well understood aspect of software design. At some point it fell out of the discipline or was pushed down the priority list.”
I believe it fell out when we started calling programmers “developers” and started viewing the writing of code as the smallest piece of building software, something trained monkeys could do if everything else was done properly.
comment at 29. September 2005
Mike Champion:
” believe it fell out when we started calling programmers “developers” and started viewing the writing of code as the smallest piece of building software”
Hmm, the trouble is that writing code is a diminishing percentage of what it takes to actually ship commercial quality software. Or more precisely, writing test code and documentation is an increasing percentage of what it takes to ship software of acceptable quality these days. That’s not to say that coding can be done by trained monkeys. To me it means that as much as we as programmers might value simplicity over the other “ilities”, we as commercial software developers have to value security, reliability, etc. more highly, even though (at the current state of the art) all those *&^%$ checks to filter input and validate output tends to make code uglier, more complex, etc.
comment at 29. September 2005
Richard Dyce:
Ryan Tomayko said :
Back in the day, when I used to write magazine columns, we used to joke about a particular school of calendar-based journalism - “If this is January, it must be disk storage” - one of the more popular column topics was software bloat, and usually more specifically, M$’s need to add new features to Office in order to persuade them to upgrade every year.
I think perhaps that the “je’n sais quois” of lescode is actually ‘refinement versus expansion’, or as Oxford has it:
vs.
Just a thought.
comment at 29. September 2005
Aristotle Pagaltzis:
It’s a known phenomenon.
This is a bailout answer, because you aren’t even trying to at least describe it, en lieu of putting your finger on it. :-) But I think Mike Champion had a decent stab at it.
comment at 29. September 2005
Aristotle Pagaltzis:
Oh, and it just occurs to me that maybe one of my favourite quotes, by one John Carter, is a good way to describe what lesscode really means and how that “je ne sais quoi” comes about:
comment at 29. September 2005