1. 50
  1.  

  2. 4

    “Yeah, we write out one big JSON object to a text file.”

    “How? When? What?”

    Obviously “insane” decisions like these always surprise me. Hindsight is 20/20, but while building software I try my best to focus on the correct solution rather than the fastest solution. This is of course at odds with my manager who would rather me get it out by Friday. I’m constantly reminded about a comment @ddevault made regarding this dichotomy (relevant lobsters post):

    The culture of doing the wrong thing because the right thing is harder really, really bothers me about the modern software development ethos. We used to care about doing things right. It has nothing to do with being stretched thin - if the throughput doesn’t change, it just takes a bit longer to finish. Well, sometimes the correct solutions take more time.

    I think about this a lot because, as a “Software Engineer”, my job is to engineer solutions to engineering problems. The more I see engineers learn, the more I see them want to do “right thing” over the “wrong thing”, even if “it just takes a bit longer to finish.” But at the same time, as the product and demand for updates grow larger and larger, the line between “right” and “wrong” technical decisions is blurred.

    A couple of weeks later, a customer wanted to try it out. I wasn’t ready to commit to the data model yet and do it properly in SQL, so I took a shortcut: the object holding all the data was wrapped in a sync.Mutex, all accesses went through it, and on edit the whole structure was passed to json.Marshal and written to disk. This gave us data model persistence in ~20 lines of Go.

    The plan was always to migrate to something else but, uh, we got busy with other stuff and kinda forgot.

    Was this a bad decision? From a software engineering perspective, I would say yes. This data should have almost certainly been shoved in a database. JSON files as databases don’t scale and are susceptible to a number of other issues. From a business perspective, this might have been the “right choice.” The customer was able to try out the product faster than if time had been taken to use a real database.

    There are, of course, a number of things we can do to balance this, but I think it’s interesting that this problem is ubiquitous among software engineers, and as Drew puts it, part of “the modern software development ethos.”