5 ms·

How Not to Write Code

15 points by fogus 17y ago

mcantor 17y ago
I'm really torn by this article. Part of me wants to dispassionately bark, "They should have obeyed the Single Responsibility Principle and the Open/Closed Principle from the start!" and coldly click on to the next link that tickles my fancy. But another part of me feels an inexplicable sympathy for the original developers here. Everyone has worked on that one app or library that organically evolved into a monster. I almost feel like it's impossible to "judge" what happened as described by the author without understanding more context: How brutal were the requirements changes? Could they have been predicted? How much was the app designed before that fateful first revision was written? I think this also has to do with the framework or language being used. If the app was written in Python, maybe it would have been less ridiculous to create an explicit "fix our stupid mistake" TimeDelta and pass it around. I definitely think that someone, at some point, should have had the sense to take a step back and say, "Maybe we shouldn't be fixing this by manually modifying the second count and checking for DST edge cases." The libraries exist for a reason, but without knowing which one they were working with, one can't really say definitively what they "should" have done. In summary, it sucks that the author FTA has to deal with this date/time kluge that he didn't create, but... that's software development.
- roc 17y ago
  Anything that was worth writing will grow and change. It only grows into a monster if you allow yourself to write duct tape code.
  - mcantor 17y ago
    I was meaning to imply more than I did by saying "organic". IMHO, "organic" growth spells disaster for a codebase, because it means (to me, specifically) growing without conscious curation on the part of the developers. I should have explained myself fully instead of using such a loaded word; it seems that the only question these developers asked was "How do I make this new feature work?" instead of "How does this new feature change the silhouette of my application?"
mquander 17y ago
You try and cut corners, it'll come bite you sometimes. Oh no, not every time -- then you'd learn your lesson. But sometimes.
jerf 17y ago
There is no such thing as a time without a timezone. There is no such thing as 11:23 am. There are in fact at least 30 11:23ams on any given day. If I was designing a datetime library, it would raise an exception if you tried to give it a time without a timezone. There would be no implicit timezones, no default arguments. If you think this is being pedantic... you've clearly never worked with times coming from multiple timezones at once, and, as this article shows, you probably live in UTC since even within one timezone you tend to get different defaults between localtime and UTC. And everybody gets incorrectly-set machines with just-flat-wrong timezones and correspondingly skewed clocks. If you ever parse a time without a timezone, that's a bug. If you have a time and you can't parse it because you don't know the timezone, that's a bug in whatever is emitting the time. IMNSHO, this is right up there with "there is no such thing as a string without an encoding" in importance.
- mbrubeck 17y ago
  I agree with the sentiment, but there are a lot of more complicated scenarios in real-world applications. For example, most calendar apps need the concept of a "floating timezone": I may have one item on my schedule called "nap time" with a time of 15:00 (no time zone). I want my computer to tell me to take a nap at 15:00 local time, no matter where in the world I am today. But I have another item on my schedule called "conference call with CEO" with a time of 13:30 PDT. I want that call to happen at a specific absolute time (not local time).
  - jerf 17y ago
    'For example, most calendar apps need the concept of a "floating timezone":' Ok... but that's a timezone, too, at least from the point of view I'm talking about. It's not an ill-defined 11:00am, it's a specific 11:00am. The root problem is specifications that match more than one uniquely-defined time.
  - arohner 17y ago
    Joda time has this concept, it calls it a partial http://joda-time.sourceforge.net/key_partial.html http://joda-time.sourceforge.net/key_partial.html . A partial is a datetime without a time zone, so it only partially specifies a time. You can combine a partial with a timezone to get an instant, a fully specified date time. It's also interesting to note that some operations cannot be performed with partials. For example, you can't add an instant and a partial (because that would be buggy). In order to add them, you have to first convert the partial to an instant (by specifying a timezone). In the parent's example, nap time would be a partial of 15:00, and your calendar app would notify about nap time by specifying the current timezone of the computer.
deleted 17y ago
[deleted]

15 points by fogus 17y ago

I'm really torn by this article. Part of me wants to dispassionately bark, "They should have obeyed the Single Responsibility Principle and the Open/Closed Principle from the start!" and coldly click on to the next link that tickles my fancy. But another part of me feels an inexplicable sympathy for the original developers here. Everyone has worked on that one app or library that organically evolved into a monster. I almost feel like it's impossible to "judge" what happened as described by the author without understanding more context: How brutal were the requirements changes? Could they have been predicted? How much was the app designed before that fateful first revision was written? I think this also has to do with the framework or language being used. If the app was written in Python, maybe it would have been less ridiculous to create an explicit "fix our stupid mistake" TimeDelta and pass it around. I definitely think that someone, at some point, should have had the sense to take a step back and say, "Maybe we shouldn't be fixing this by manually modifying the second count and checking for DST edge cases." The libraries exist for a reason, but without knowing which one they were working with, one can't really say definitively what they "should" have done. In summary, it sucks that the author FTA has to deal with this date/time kluge that he didn't create, but... that's software development.

roc 17y ago
Anything that was worth writing will grow and change. It only grows into a monster if you allow yourself to write duct tape code.
- mcantor 17y ago
  I was meaning to imply more than I did by saying "organic". IMHO, "organic" growth spells disaster for a codebase, because it means (to me, specifically) growing without conscious curation on the part of the developers. I should have explained myself fully instead of using such a loaded word; it seems that the only question these developers asked was "How do I make this new feature work?" instead of "How does this new feature change the silhouette of my application?"

mquander 17y ago

You try and cut corners, it'll come bite you sometimes. Oh no, not every time -- then you'd learn your lesson. But sometimes.

jerf 17y ago

There is no such thing as a time without a timezone. There is no such thing as 11:23 am. There are in fact at least 30 11:23ams on any given day. If I was designing a datetime library, it would raise an exception if you tried to give it a time without a timezone. There would be no implicit timezones, no default arguments. If you think this is being pedantic... you've clearly never worked with times coming from multiple timezones at once, and, as this article shows, you probably live in UTC since even within one timezone you tend to get different defaults between localtime and UTC. And everybody gets incorrectly-set machines with just-flat-wrong timezones and correspondingly skewed clocks. If you ever parse a time without a timezone, that's a bug. If you have a time and you can't parse it because you don't know the timezone, that's a bug in whatever is emitting the time. IMNSHO, this is right up there with "there is no such thing as a string without an encoding" in importance.

mbrubeck 17y ago
I agree with the sentiment, but there are a lot of more complicated scenarios in real-world applications. For example, most calendar apps need the concept of a "floating timezone": I may have one item on my schedule called "nap time" with a time of 15:00 (no time zone). I want my computer to tell me to take a nap at 15:00 local time, no matter where in the world I am today. But I have another item on my schedule called "conference call with CEO" with a time of 13:30 PDT. I want that call to happen at a specific absolute time (not local time).
- jerf 17y ago
  'For example, most calendar apps need the concept of a "floating timezone":' Ok... but that's a timezone, too, at least from the point of view I'm talking about. It's not an ill-defined 11:00am, it's a specific 11:00am. The root problem is specifications that match more than one uniquely-defined time.
- arohner 17y ago
  Joda time has this concept, it calls it a partial http://joda-time.sourceforge.net/key_partial.html http://joda-time.sourceforge.net/key_partial.html . A partial is a datetime without a time zone, so it only partially specifies a time. You can combine a partial with a timezone to get an instant, a fully specified date time. It's also interesting to note that some operations cannot be performed with partials. For example, you can't add an instant and a partial (because that would be buggy). In order to add them, you have to first convert the partial to an instant (by specifying a timezone). In the parent's example, nap time would be a partial of 15:00, and your calendar app would notify about nap time by specifying the current timezone of the computer.

deleted 17y ago

[deleted]