4 ms·

If I had more time I would have written less code

46 points by suprgeek 15y ago

bdfh42 15y ago
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.
noonespecial 15y ago
I put in "#TODO - Come back and make this shorter" all the time.
- syaz1 15y ago
  And of course it's left there for ages to come, never to see the light of day, ever again.
  - jpitz 15y ago
    The diff command that I run before I commit highlights all those TODOs ( along with whitespace damage )
  - noonespecial 15y ago
    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.
mweibel 15y ago
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.
chipsy 15y ago
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%20FinalVersion.pdf http://www.oru.se/PageFiles/15389/Yan%20Wang%20Lic%20FinalVe... )
mattgreenrocks 15y ago
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 15y ago
  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.
skatenerd 15y ago
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.
bambax 15y ago
> 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%3AOCLC4604933&hl=en&pg=PA271 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...?
- mitchty 15y ago
  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.
PaulHoule 15y ago
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.
Hisoka 15y ago
I thought this article was going to be about someone in his deathbed who wished he would have coded less in his life

46 points by suprgeek 15y ago

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.

noonespecial 15y ago

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

syaz1 15y ago
And of course it's left there for ages to come, never to see the light of day, ever again.
- jpitz 15y ago
  The diff command that I run before I commit highlights all those TODOs ( along with whitespace damage )
- noonespecial 15y ago
  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.

mweibel 15y ago

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.

chipsy 15y ago

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%20FinalVersion.pdf http://www.oru.se/PageFiles/15389/Yan%20Wang%20Lic%20FinalVe... )

mattgreenrocks 15y ago

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 15y ago
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.

skatenerd 15y ago

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.

bambax 15y ago

> 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%3AOCLC4604933&hl=en&pg=PA271 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...?

mitchty 15y ago
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.

PaulHoule 15y ago

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.

Hisoka 15y ago

I thought this article was going to be about someone in his deathbed who wished he would have coded less in his life