

Principle of Least Coding - rmord
http://ramblingsoullt.blogspot.com/2012/03/principle-of-least-coding.html

======
azov
> _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.

~~~
bigiain
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.)

~~~
barefoot
An important corollary to that statement is:

"And never show the prototype to non-developers".

~~~
debacle
This is probably my biggest fault.

"So I whipped together a quick API integration yesterday evening..."

"Oh, so you're almost done then!"

------
ericHosick
_> When one designs a solution well, the amount of code that one has to write
becomes minimized._

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.

~~~
einhverfr
Absolutely.

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!

------
dchichkov
Every line of the code is a constraint working against you.

~~~
sjmulder

        /* I have only made this method longer because I have
           not had the time to make it shorter. */

------
fauigerzigerk
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.

------
greenyoda
Another, similar take on this idea is this article, written in 2007:

Code is a Liability

[http://blog.objectmentor.com/articles/2007/04/16/code-is-
a-l...](http://blog.objectmentor.com/articles/2007/04/16/code-is-a-liability)

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."

------
Akram
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.

~~~
einhverfr
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.

------
ericHosick
_> 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".

------
jimfl
Rule of thumb: run test coverage. Consider deleting any code not covered
before writing a test to cover it.

------
Craiggybear
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.

~~~
bahadden
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.

