
Write Less Code - mccarthyjm
http://mikegrouchy.com/blog/2012/06/write-less-code.html
======
sophacles
Any day that has a negative LOC count is a good day :)

This usually means I found a good refactoring, or a good abstraction that
removes a lot of stuff that is now boilerplate.

If I can also add a feature with a negative net LOC count, it is a gold-star
day :)

That being said, sometimes just dumping a pile of code that passes tests, but
is large (bloated), unwieldy and redundant is the right move. It give me
something to refactor and abstract, and gets things done.

It's all about balance.

~~~
evincarofautumn
I’m with you. The most rewarding thing about diving into a large codebase is
that you have many opportunities to refactor while you add features. At my
current job I add only marginally more code than I delete. Feels good. :)

~~~
getspeedly
Sure -- as long as there are tests and some semblance of order. Trying to add
new features to an untested ball of mud is just about the worst possible thing
one can inflict on a poor programmer.

~~~
evincarofautumn
Yeah, luckily, the guy I’m working with is quite good about testing. If that
weren’t the case, then I’d have a different opinion…

------
hcarvalhoalves
I would go even further: to be a good developer you have to hate programming.
If you like to fiddle too much, you'll waste time messing around and
bikeshedding instead of taking your time to think about the problem at hand at
a more fundamental level. Sometimes you solve a programming issue without
writing even one line of code, but challenging the business requirements
instead. It's important to be holistic.

~~~
jiggy2011
I wouldn't say "hate" programming, people who hate programming tend to write
the worst overcomplicated code because their idea of re-use is copy-pasting
the same bit of code they found online into every place they think it will fit
and changing it around in various ways in different places so it becomes very
hard to abstract later. They also like to stick with the same set of now
deprecated APIs they learned 10+ years ago which means that it becomes hard to
take advantage of newer libraries which were not built with these in mind,
meaning that you will do a lot of wheel re-invention or shimming. They tend to
think of economizing on effort and brain usage _right now_ rather than
economizing on technical debt in the long run.

There is also sometimes a trade off between saving time for the programmer and
saving time for others. For example a manager might want a feature that saves
them 10 minutes of time once a month when they want to produce a particular
report but may cost programmers several hours a month just keeping this
feature up to date. In this case it comes down to who's time is more valuable.

The best way to explain this to people is in terms of "tax" (since everyone
hates that). I was once asked by a management type "I used to get all my
changes turned around same day, now I seem to wait weeks or even months.
What's going on?"

Of course the simple answer to this question is that a year ago the program
was about 10Kloc , now it's more like 200Kloc. It's also much more "mission
critical" than it was. A year ago the program was small enough that I could
easily imagine all the consequences of making a change in my brain so I could
do basic testing and push to production, now a small change can have many
consequences so it has to be thoroughly tested first.

So the analogy to make would be the government building infrastructure for say
the road network. The upfront cost of building is $x , but when doing that you
commit to $y spending per year (in terms of cost+time) to keeping that going.

Persuading people not to add functionality they don't need is a good idea of
course, but this isn't always going to be practical. Firstly it assumes that
the developer understands every aspect of the business well enough to evaluate
this, in which case they really may as well just put the developer in charge
of the whole thing.

It's also partly a political issue, I've spent months adding features to
codebases that I know for a fact are not required because somebody with enough
influence simply insists that it will be important. There is only a certain
level of argument you can get into before you get to "do as you are told",
that level will of course depend on many non-technical factors.

Another interesting point is that I find sometimes people will request feature
X because they are perusing a line of though that will eventually lead them to
conclude that they actually need feature Y. In many cases feature Y may be
easier to implement (or maintain) than feature X but they simply haven't
reasoned that far ahead yet so will insist that they want feature X now but
acknowledge that they may change to feature Y a few months down the line.

~~~
hcarvalhoalves
"I wouldn't say "hate" programming, people who hate programming tend to write
the worst overcomplicated code (...)"

No, this is just being slopy. Developers who "hate" code will __always __push
to deal with the smallest amount of it, so they think twice before they touch
the keyboard.

"Persuading people not to add functionality they don't need is a good idea of
course, but this isn't always going to be practical. Firstly it assumes that
the developer understands every aspect of the business well enough to evaluate
this, in which case they really may as well just put the developer in charge
of the whole thing."

If he doesn't understand the aspects of the business and doesn't have any
stake on the final product he's not a developer, he's just a programmer doing
repetitive work at a software factory - "code monkey" on jargon - and is not
in a position to provide the kind of disruptive, ten-fold improvement software
is able to produce.

In fact, I can only feel sorry for any business which depends fundamentally on
software and doesn't have a developer as the main stakeholder.

~~~
jiggy2011
_No, this is just being slopy. Developers who "hate" code will always push to
deal with the smallest amount of it, so they think twice before they touch the
keyboard._

I guess it depends on how you define "hate". The amount of effort you put into
your job tends to some function of how much you enjoy it and how much money
you are paid. At a certain point the money tends to tailor off in
effectiveness too.

If you hate your job then your main motivator is "how soon can I go home
today?" or "how little brain power can I invest in this?" you will not be
interested in the LOC count of the project at all. If you enjoy programming
then you are more likely to want to expend more effort thinking about how you
could write the same thing using less/more maintainable code. There are of
course programmers who will over architect solutions but this is usually
because they believe that they are creating a structure that will keep LOC
count lower over the long run.

After all code saving things like MVC/ORM frameworks were originally used by
the early adopter more enthusiastic programmers.

I would say it's better to hate large bloated codebases, but I can't think
there are many programmers who create these on purpose, it is usually a by
product of flawed assumptions made in earlier stages or less skilled
programmers.

 _If he doesn't understand the aspects of the business and doesn't have any
stake on the final product he's not a developer, he's just a programmer doing
repetitive work at a software factory - "code monkey" on jargon - and is not
in a position to provide the kind of disruptive, ten-fold improvement software
is able to produce._

Again this is sort of semantics, most companies will advertise positions that
are repetitive "factory" jobs as "developer" positions. In fact some of the
better programmers I know refer to themselves as "code monkeys" so I guess
this is really a cultural thing.

It's an interesting point about automation and how much stake a developer
should have in a business. Most businesses now depend fundamentally on
software in one way or another, for a glaring example of this see the UK banks
that have had to cease pretty close all activity for the best part of a week
because of a software problem. Also pretty much also businesses above a
certain size have _some_ custom code running somewhere.

Does this mean that all businesses should have a developer present at board
level? Also should that board level person simply be someone with development
experience or should they be involved in the day to day code production so
that they can understand all of the decisions made?

This also ties into the debate about who should learn to program, for example
do you get that experience at board level by teaching executives to write
programs or instead do you promote programmers to board level and teach them
about "business stuff"?

~~~
vibrunazo
You don't have to love the ride to enjoy the trip. Programming is just a means
to an end. We love the end, not the mean. He's not talking about worrying "how
soon can I go home today". You do have a powerful motivator, which is the
awesome software you're gonna build. You wanna write code because you wanna
see your own thing built and working. Not because you love writing text on the
editor.

If I could build great software without writing code I would. Unfortunately
we're not there yet. As you said it yourself, most businesses now depend
fundamentally on software. So being inside and working to make your code base
as good and maintainable as possible, and understand those processes is
important. So we do care about writing good software. But not because we love
writing code, but because we hate that.

~~~
jiggy2011
Right, but that's not an especially incitefull distinction to make. I imagine
there are very few programmers around who love programming because it means
they get to type lots of characters into a text editor in the same way that
nobody enjoys sex because it means they get to exercise their hips.

In fact this is probably a big motivator in the number of open source
libraries available now, they were developed by somebody who wanted to achieve
thing X but they needed to create byproduct Y in order to do that.

So it makes sense to share by byproduct Y with the people who need to make
thing Z.

------
luriel
Some of my favorite quotes about programming (
<http://quotes.cat-v.org/programming/> ) make precisely this point:

" _One of my most productive days was throwing away 1000 lines of code._ " --
Ken Thompson

" _Deleted code is debugged code._ " — Jeff Sickel

And probably my favorite (because this doesn't apply only to lines of code):

" _The cheapest, fastest, and most reliable components are those that aren't
there._ " -- Gordon Bell

~~~
jim_kaiser
"The cheapest, fastest, and most reliable components are those that aren't
there." -- Gordon Bell

Just to clarify. I think what he means by that statement is that, we assume
that components not yet built would be cheaper, faster and more reliable than
they would be in reality. Which is almost always true.

[EDIT: Just realized, it's true the other way around too, if you eliminate the
need for a component, it becomes the cheapest, fastest and most reliable
component.]

------
jiggy2011
I find as a general rule, the more that my application tries to abstract and
protect the user from the "technical" nature of the platform the more code I
have to write.

For example I produced a CMS that was intended to be used by content writers
who were not technical. However as the complexity of the website increased
(more dynamic content on pages etc) I had to write a lot of code because there
were a lot of exceptional cases "I want this side bar to appear on all of
these types of pages apart from these 3 because of condition X and this other
one because of condition Y". This means that my code ends up being an enormous
pile of if statements with a huge number of database flags at the backend and
checkboxes on the front end.

In the end it proved more effort efficient to produce a simple tag language
for the front end and expose that to the designers and content writers, this
took a lot of complexity out of the back end which could then concentrate on
providing the primitives for the tag language.

You do move some complexity to the front end here for sure, but people are
often better at specifying what it is they mean if they can actually generate
and tweak it to some extent themselves and show the result rather than trying
to explain everything in an email.

Another great example of this is Unix command line utilities , the basic
interface for many of these has remained relatively unchanged since the 80s
whereas GUI applications seem to be continuously redesigned.

~~~
jz
Part of the zen of Python is "Flat is better than nested". Until recently, I
always thought of this at a code block/function level. Recently I realized
that this is also important when modularizing and adding layers of
abstraction. The more layers of abstraction (from foo.bar.baz import Baz) you
add, the more code you write and have to "keep in your mind". This
presentation by Jack Diederich at PyCon 2012 really opened my eyes to the
potential problems of adding layers of abstraction via modules and classes:
<http://pyvideo.org/video/880/stop-writing-classes>

~~~
hackinthebochs
Interesting you say that; I would argue (and have) the exact opposite. Good
abstractions, by their very nature, reduce the amount of moving parts you have
to keep in your head at any one time. When the number of "moving parts"
created by your abstractions outnumbers the actual bits its abstracting, then
you know your design took the wrong turn somewhere.

~~~
jz
> When the number of "moving parts" created by your abstractions outnumbers
> the actual bits its abstracting, then you know your design took the wrong
> turn somewhere.

This is an interesting point which I agree with and is usually where I end up.
In the past I've started from the opposite end, creating multiple modules,
class hierarchies, etc. This future proofing has made things harder for me to
follow/understand when reading at a later date. It has become tiresome and now
I consciously start at the other end, making the simplest thing that could
work. Layers of abstraction then come naturally as needed.

~~~
jiggy2011
This is the best approach , but it is best combined with fairly comprehensive
re factoring otherwise you end up in a situation I have been in a few times
where you have new code that runs with a nice abstraction and old code that
works with less abstraction.

At that point you can introduce bugs because somebody modifies the old code in
a way which would not be allowed under the new abstraction and then the new
code ends up reading data produced by the old code leading to a cascade of
failure.

------
alttab
Code you never write never breaks. It has astonished me how much code people
can crank out. It does not astonish me that they spend most of their time
maintaining things they've written.

~~~
crusso
> Code you never write never breaks.

... but doesn't do anything either. :P

~~~
alttab
You are jumping to the assumption that the code you _do_ write does anything
at all.

~~~
crusso
Such a short sentence I wrote. How do you make such assumptions about my
assumptions.

~~~
alttab
Because I've been around the block enough to know that if you think code not
written doesn't do anything, then code you write MUST do something. The
reality is most code does nothing (other than push data around), and the
actual code that really drives the value is primarily an innovation that lives
in one component of the code-base. All other code is expendable and most of it
is putting a pretty face on the raw functionality or adding usability,
options, etc.

All code needs to be taken into account holistically. Sure, you added some
code that sends alerts. It actually does something. Well, do your customers
care? Are they willing to upgrade to the latest version? Does that piece of
code actually change the business strategy, market penetration, or mindshare?
90% of the time code is checking boxes against competitors or providing some
benefit that does not have a huge impact to the bottom line of the business.
Again, MOST code.

So I make assumptions based directly of years of experience. Most of the code
anyone writes barely does anything. The amount of code that is written
compared to the amount of code that actually makes meaningful changes to the
business or the world at large is probably 50:1.

~~~
crusso
Honestly, as a data point... you were wrong. I was just being a smart ass.

If I had any thought in mind besides just to be a contrarian it was, to quote
Voltaire, "A witty saying proves nothing.".

I've been around the block a bit too and I know that these articles on HN and
the one-line summations of "write more code", "write less code", "write purple
code", "Code you don't write doesn't have bugs", etc. don't really mean
anything more than my stupid "... but doesn't do anything either. :P".

It's like throwing people random tools out of a toolbox. "When you do
carpentry, use a chisel", "For building houses, a hammer is what you need",
etc.

If the carpenters you're throwing a chisel to don't know how to properly use a
chisel, then just throwing one at them isn't helpful. If they already know how
to use a chisel, then you're not helping them either.

Maybe you were just trying to give them a clever-sounding quote with an
obvious rejoinder to throw out on HN and thus promote a little discussion? In
that case, I guess it worked well enough. :)

~~~
alttab
Everyone enjoys a little conversation and a little snark :)

------
jim_kaiser
My principles with software development are simple. Code should be clean,
beautiful and do exactly what you want it to do.

I agree with the advice doled out by the author about spending more time on
thinking than actual programming. This is something most good developers
eventually learn as they get more experienced. To immediately dive in and
implement as you find issues would cost you more time in the longer run.

Also, putting it on paper always helps. Especially when you're dealing with
large software or changes to complex algorithms. It helps to visualize it on a
more permanent medium than the brains fickle whiteboard.

Ultimately, unless you work on the software like you have a stake in it, you
wouldn't spend enough mind on it to do the continuous re-factoring and
improvements it takes to make great software. This is especially true in a
commercial environment where deadlines and releases and user visible
improvements are the focus of the management. It is upto you to care about
what happens under the hood and eventually you will wish you had.

------
primitur
One of my favorite reads lately:

"The problem is largely philosophical: as software developers we're trained to
think in terms of rigid systems of objects, design patterns and re-usable
code. You might set out with the great idea to build a system of classes with
clearly defined interfaces that inherit from one another when specialized
behavior is needed. You might model all this in Lua using any number of class
and inheritance patterns to try and enforce your vision. But, if you're
perceptive, you'll soon start to suspect that all of the work you're doing to
build an architecture really doesn't add much practical value. You may find
yourself in the situation of having spent a lot of time defining a traditional
OOP-style inheritance hierarchy and a big pile of fancy data structures only
to realize you've created nothing more than an especially convoluted way of
initializing tables.

Fortunately, there's an easy solution: don't do it. "

From :
[http://getmoai.com/wiki/index.php?title=Structuring_Your_Moa...](http://getmoai.com/wiki/index.php?title=Structuring_Your_Moai_Game_in_Lua)

------
jacobr
From a product owner's or designer's perspective this would be "add less
features" which is an equally good idea and also requires less code.

------
gruseom
_If we wish to count lines of code, we should not regard them as "lines
produced" but as "lines spent": the current conventional wisdom is so foolish
as to book that count on the wrong side of the ledger._ \-- Dijkstra

(I got this from akkartik but can't remember where.)

------
kolleykibber
'Spend more time writing less code.'

I think that quote, or something like it, is from the 80's.

I've found this is the hardest thing for non tech business partners to
understand, because most of the time, it appears as if you are doing nothing.

------
InclinedPlane
I think this applies on every scale. Not just writing more elegant code but
also just writing code in smaller units and having a prejudice against large
methods/classes/components. I've noticed a lot of devs have a mental block
about things like one-line methods or extracting a single conditional test
into a method and other trchniques that really do help make your code clearer.

The more experienced I get the more I come to view big code as an anti-pattern
/ code smell.

------
dodothelast
the job of a designer is it, to let things look beautiful in different ways:
in the way it looks, it feels, how to use it and so on. i wouldn't say that
i'm only a software engineer, but also a software designer.

    
    
      code == ui
    

code has to look beautiful, it should feel good to work with, easy to use,
etc.

maybe this is all about the zen of coding.

------
ilaksh
If you find a way to avoid writing ASCII codes, or avoid it most of the time,
then you aren't programming. And therefore, you are no longer a programmer.

Arranging, configuring and connecting components/widgets with GUIs is a very
powerful way to solve all sorts of problems in many application domains.
Unfortunately, the more powerful a system like that is, the less attractive it
is for 'software developers' because it means they mostly aren't writing code,
but rather are dragging around widgets.

I'm building a system like that anyway, for my own personal sanity. It is
definitely a tool for advanced software developers to create, publish and
configure widgets, not just for users or designers, although its also
specifically for users and designers as well. I expect that most software
developers will not appreciate it because it will make it too easy to build
powerful applications without writing code.

The biggest thing holding back software engineering right now is source code.

The problem is that the definition of programming and software development is
outdated. Programmers write colorful ASCII codes.

<https://github.com/ithkuil/cureblog>

<https://vimeo.com/43784316>

------
gojomo
The obligatory relevant bit of Apple/Bill Atkinson folklore (posted to HN
previously):

[http://www.folklore.org/StoryView.py?project=Macintosh&s...](http://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt)

------
wildtype
"Code is a by-product", remind me to Atwood's Please don't Learn to code.

~~~
hcarvalhoalves
Code is a by-product of software development in the same sense as a blueprint
is a by-product of engineering. Teaching a programming language doesn't turn
someone into a software developer just as teaching technical drawing doesn't
turn someone into an engineer.

~~~
anthonyb
I think you're being a bit free with the metaphors here.

A blueprint isn't a finished deliverable if you want something that you can
actually use. Code, on the other hand, mixes design and building - if you
delete the code, what are you left with?

~~~
hcarvalhoalves
Yeah, I'm playing with metaphors here. The point I want to get across is the
code itself is just a means to an end. _Just_ the code is often not a
deliverable, unless you make money from software patents. Google doesn't make
money because they sell a lot of code. Facebook doesn't get investment because
they wrote a lot of code. That doesn't mean their code isn't valuable - it is.
But it's the actual computation (e.g. execution of this codebase) that has
real value. Get it?

~~~
anthonyb
That attitude leads to devaluing software, followed by bugs, a legacy codebase
and not being able to extend your software when your competitors catch up.
Programs and the problems that they solve are intertwined. You can't easily
separate them - which is why your metaphor doesn't work.

------
joogernaut
there is no universal truth other than balance and careful judgement. Say
"write less code" to the wrong person, and they will go off and create six
months of meetings where they decide what they should decide what they should
decide to decide to do. Analysis paralysis will creep in and kill you.

