

If I had more time I would have written less code - suprgeek
http://blog.activelylazy.co.uk/2011/02/09/if-i-had-more-time-i-would-have-written-less-code/

======
bambax
> _In a a blatant rip-off of the T.S Eliot quote: “if I had more time, I would
> have written a shorter letter”_

This is actually a rip-off from Blaise Pascal, French scientist and
philosopher from the 17th century who wrote in the 16th "Provinciale":

"Je n'ai fait [cette lettre] plus longue que parce que je n'ai pas eu le
loisir de la faire plus courte".

(December 1656)

which would translate as "This letter is longer, only because I couldn't find
the time to make it shorter".

[http://books.google.fr/books?id=5dk8AAAAcAAJ&dq=related%...](http://books.google.fr/books?id=5dk8AAAAcAAJ&dq=related%3AOCLC4604933&hl=en&pg=PA271)

It's a very famous quote that is used constantly in French, so I'm kind of
surprised T.S. Eliot could claim it as his own...?

~~~
mitchty
It is possible that both quotes are cases of "convergent evolution" if you
will and both are correct. Given how many people there are I don't think its
unheard of for two people to arrive at the same idea despite one being much
older.

That or he never attributed it, and speakers of only English attribute the
phrase to his first use because of it.

------
chipsy
With game programming there's a definite apogee of "code that needs to be done
right," reached as the majority of the game features are integrated and
gameplay is proven.

Before you hit that point, you're mostly getting things wrong, so you build it
to 80% correct and when it breaks you refactor to 90%, 95%, etc., until you've
hit the needed quality bar. (With experience you can get it "righter" on the
first pass, of course.)

Once you cross the apex you can start doing a mix of "cowboy coding" and pure
low-level maintenance(bugfixes, optimization) to tighten things up for the
user, because you have confidence in it being stuff that builds on a stable
core. The hacks end up being the lowest-cost solution because the proper thing
would effectively be a "99.xx%" refactor, getting more correct than you need
and disturbing tons of decent, working code to fix the one problem. The game
ships and then you rip it all apart for the next one anyway, so you never need
that last bit.

The trick with the code written for the 48 hour game jam games is to set the
apogee point much earlier than normal, and live with lower quality
implementation where possible(since you have control over game design, it's
typically easy to find areas to sacrifice quality). It is very much in the
Forth philosophy - do more by doing less.

However, I get the feeling that improved - and especially more domain-specific
- languages are the next step, because they allow the early stages of the
project to be more correct from the start with less trial-and-error. You would
reach more 9's in fewer iterations. This is borne out by the TCP/IP DSL paper
(
[http://www.oru.se/PageFiles/15389/Yan%20Wang%20Lic%20FinalVe...](http://www.oru.se/PageFiles/15389/Yan%20Wang%20Lic%20FinalVersion.pdf)
)

------
mattgreenrocks
The most dangerous managers can be the ones that are able to code, but never
had to maintain their code for long periods of time. So you cannot _ever_ talk
refactoring with them.

~~~
petervandijck
I give my developers a week of refactoring (ie. no new features or
improvements, let's just focus on refactoring a few things) every month or so.
That plus refactoring-as-you-go, of course. It's not much but it makes them
happy :) I may not know much about coding, but I know happy developers matter.

------
noonespecial
I put in "#TODO - Come back and make this shorter" all the time.

~~~
syaz1
And of course it's left there for ages to come, never to see the light of day,
ever again.

~~~
noonespecial
The way I work actually sees lots of these get done. Minor refactoring is a
great way to get your zone on at the beginning of each day.

------
PaulHoule
Code bulk is an indicator of complexity but it's not the only one. In some
cases it makes sense to build a system with "less architecture" even if this
means "more lines of code."

It's a situational thing, and it's particularly true when you (i) need to
develop a quick prototype, and (ii) don't understand the problem very well.
Sometimes there's no more efficient way to learn about (ii) other than doing
(i). In a case like this, however, you are "building one to throw away.

Overall there's a balance between systems that have (A) "lots of pieces that
have simple relationships" and (B) "a few pieces that have complex
relationships".) Type (B) systems are more reusable, but introduce the risk
that bad architectural decisions are going to be made. Adding time to the
schedule, which is spent on thinking about design, can sometimes lead to a
good design, but with some teams it leads to overengineered systems that have
fundamental design flaws that prevent project success.

Early confrontation with reality is important, so early phase development
should focus on resolving risks.

------
skatenerd
two things you might hear in this situation are "be entreprenurial with edge
cases" and "if you write robust edge-case-ignorant code, the modifications
later should be easy". It's not immediately obvious how to respond in these
situations.

trying to work through things on your own before coding, the fifteen-minute
clarification process can start looking like a few days. and there's also no
guarantee that you'll think of everything.

as for writing code that doesn't break when you work in the edge case you
hadn't thought of, well, i guess that comes with experience.

------
mweibel
Really true. I'm currently working on a project where the deadline is fix but
the code upon we build is bad :/ As a result, code doesn't get better, more
code is being done and refactoring is not top priority.

------
bdfh42
Twice this week I thought exactly that. Each time I consoled myself that my
lengthy code would be easy to understand even if (marginally I hope) less easy
to maintain.

