Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Ill-fated code rewrite crusades often seem to be linked with the Second System Effect (https://umich.instructure.com/files/884126/download?download... ... page 55).

Excerpt:

An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint. As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used "next time." Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system. This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

And from the OP, frill by frill :-)

I wanted to try out new, shinny technologies like Apache Cassandra, Virtualization, Binary Protocols, Service Oriented Architecture, etc.

To OP's credit, he took a step back and learned from his mistakes.

Also related... Second System Effect may not only apply for your second system ever. It may also bite you designing the second system in a new problem domain you're unfamiliar with. I can admit I've built a few second systems in my time ;-)



I hope/like-to-think that the second-system that focuses on architectural-features is better than the second-system that focuses on new user-features.

Stuff like "no global variables" or "actually use database transactions" or "support UTF-8"...


"Remember that time zones are a thing and not everyone is in America/Los_Angeles..."


That’s why I personally love most european companies, as most just assume UTC.


The gold standard is software designed to be run near the North and South Poles, like snowmobile and ICBM navigation systems, which need to be able to switch between all time zones quickly.


Why would an ICBM need to use local timezones at all?

I can't imagine any teams up their using more than one timezone anyways. Perhaps UTC + their home zone?


After a 15-year career programming, I'm pretty sure the only sane way to handle timestamps is everything UTC server side, and let the UI convert to localtime on display.


Yup. That’s also my solution. Sadly, we’ve had to deal with doing other things recently, too, as our software was run on servers with the timezone set to UTC, but the hardware clock being 3 hours ahead of UTC (this is common especially on old Windows installs).

The result was that the displayed time on the server was local time, but if we sent it to the client, we got 3h offset there as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: