That is such a beautiful expression. It goes straight to my list of inspirational programming quotes. I hope you don't mind that I drop "the" from my version.
Definitely a case of Less Is More. A program should be no bigger than it needs to be. First rule of engineering anything - bridges, dams, roads, software.
A major difference between software and engineering (roads, bridges etc) is in the amount of redundancy.
Bridges and such are usually made massively bigger and stronger than they need to be, just in case. Belt and braces. Of course, it's a lot cheaper to build that redundancy into a bridge than it is in software.
Writing less and elegant code take more time... I used to spend more time in perfecting my logic in as less code as possible.. But if the code is for an MVP then it should be quick and dirty.
Once you get the design down, I think this is a false dichotomy.
Also I would suggest that if you focus on more generic flexible (what I call "superset") features, then long-run the codebase becomes a lot smaller. For example, when rewriting the the project accounting side for LedgerSMB, I generalized it out, and so the same logic could also handle funds accounting.
>So how can we go about writing code that is least coding? In general, when one works out the design (as has been apparent many times from personal and anecdotal experiences) well in advance before writing code
Can't agree with this advice. Figuring out the design before writing code is not going to work because you simply don't understand the problem well enough before you try to implement the solution. It is that first prototype that helps you gain knowledge, discover practical use cases, prioretize features, etc. The design that you "figure out" without writing any code will most likely be inadequate.
The thing is - you want to minimize the amount of code you end up with, not the net amount of code you write along the way.
PS. Two exceptions:
a. your problem is trivial;
b. you've solved a similar problem before.
I sort of agree with you; Code to find the edges of the problem, design to work out what to do, and back to code to implement. Sometimes the only thing that saves my sanity is a nice process diagram in the design phase, which makes me realise that something important has been missed.
Advice from a long time ago that took me way longer than it should have to understand fully:
"Always throw the first one away."
I now consider the entire first prototype to be part of the "working out the design" process, and all the code written for that is considered disposable (quite often I write a prototype in a different language to the intended delivered product, partly to ensure I throw the first one away, but when I'm honest with myself - at least partly 'cause I enjoy rapid-prototyping in Perl.)
How about writing something quick and then refactoring aggressively? The prototype code would kind of be the design specification. After the second or third big refactor my code is much shorter and starts making some sense...
Well, I disagree with you. However by "design" I don't mean figuring all the implementation details out ahead of time. It means looking at the requirements, what solutions already exist, and figuring out the most elegant way to string together what you have and fill in the holes.
Now, IMO, this design never means writing a spec. It means thinking through things however, from an architectural rather than implementation perspective. It means thinking through the larger problems regarding how the pieces of your program will talk to eachother before you begin.
Then when you start coding, the only design questions you have left to answer are those which involve the sorts of details you won't know in advance.
Agree completely. The first thing I thought when I read this was that it was going to be talking about the old extreme programming adage of YAGNI (http://en.wikipedia.org/wiki/You_aint_gonna_need_it) - only to find that it came to the exact opposite conclusion :-)
One of the really gratifying things about hte newer architecture of LedgerSMB is:
1) How easy it is to write new code that works with the architecture, and
2) How little code you have to write to do something useful.
I sometimes joke that our codebase is shrinking as our features increase, so we should have an infinite range of features about the time our codebase hits zero lines of code!
> In general, when one works out the design well in advance before writing code.
One tool available is Behavior/Feature Driven Development which forces you to work out the design well in advance and then implement only the code that makes that design "pass".
The main reason why I don't find this principle as useful as it appears at first sight is the phenomenon of obfuscation by abstraction.
You can cut down on LOC and even make the code appear more elegant by making it very abstract. Is this better than writing more lines of code that express the intention more directly? I don't have a general answer to that and I don't think there is one. Nothing will ever free us from the burden to find the right balance.
Excerpt: "Code size reduction is a very good thing. I want the simplest, the smallest, the least code possible, with the least risk of breaking something else in the system. I don’t want big functions that touch everything in sight. I don’t want long complicated blocks of if/else statements. I don’t want monster functions which conglomerate dozens of operations in a single, fat interface. Shallow is good. Short is good. Less code is good. More code is a liability. This isn’t about typing less, it’s about owning less."
25 comments
[ 4.3 ms ] story [ 66.9 ms ] threadBridges and such are usually made massively bigger and stronger than they need to be, just in case. Belt and braces. Of course, it's a lot cheaper to build that redundancy into a bridge than it is in software.
Also I would suggest that if you focus on more generic flexible (what I call "superset") features, then long-run the codebase becomes a lot smaller. For example, when rewriting the the project accounting side for LedgerSMB, I generalized it out, and so the same logic could also handle funds accounting.
Can't agree with this advice. Figuring out the design before writing code is not going to work because you simply don't understand the problem well enough before you try to implement the solution. It is that first prototype that helps you gain knowledge, discover practical use cases, prioretize features, etc. The design that you "figure out" without writing any code will most likely be inadequate.
The thing is - you want to minimize the amount of code you end up with, not the net amount of code you write along the way.
PS. Two exceptions: a. your problem is trivial; b. you've solved a similar problem before.
"Always throw the first one away."
I now consider the entire first prototype to be part of the "working out the design" process, and all the code written for that is considered disposable (quite often I write a prototype in a different language to the intended delivered product, partly to ensure I throw the first one away, but when I'm honest with myself - at least partly 'cause I enjoy rapid-prototyping in Perl.)
"And never show the prototype to non-developers".
"So I whipped together a quick API integration yesterday evening..."
"Oh, so you're almost done then!"
No product design survives first contact with users, and it would be a waste of time if you do not use feedback that the first prototype can get.
Now, IMO, this design never means writing a spec. It means thinking through things however, from an architectural rather than implementation perspective. It means thinking through the larger problems regarding how the pieces of your program will talk to eachother before you begin.
Then when you start coding, the only design questions you have left to answer are those which involve the sorts of details you won't know in advance.
It can also be noted that a really well designed solution may require no lines of code at all.
For example, engineering away parts of a process that are no longer required within an automated version of that process.
One of the really gratifying things about hte newer architecture of LedgerSMB is:
1) How easy it is to write new code that works with the architecture, and
2) How little code you have to write to do something useful.
I sometimes joke that our codebase is shrinking as our features increase, so we should have an infinite range of features about the time our codebase hits zero lines of code!
One tool available is Behavior/Feature Driven Development which forces you to work out the design well in advance and then implement only the code that makes that design "pass".
You can cut down on LOC and even make the code appear more elegant by making it very abstract. Is this better than writing more lines of code that express the intention more directly? I don't have a general answer to that and I don't think there is one. Nothing will ever free us from the burden to find the right balance.
Code is a Liability
http://blog.objectmentor.com/articles/2007/04/16/code-is-a-l...
Excerpt: "Code size reduction is a very good thing. I want the simplest, the smallest, the least code possible, with the least risk of breaking something else in the system. I don’t want big functions that touch everything in sight. I don’t want long complicated blocks of if/else statements. I don’t want monster functions which conglomerate dozens of operations in a single, fat interface. Shallow is good. Short is good. Less code is good. More code is a liability. This isn’t about typing less, it’s about owning less."