If I had more time I would have written less code

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

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

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

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.

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.