A parable about problem solving in software development (2013) | Hacker News Reader

A parable about problem solving in software development (2013)

drmaciver.com

64 pointsColinWright5 comments

Mods: this article's from 2013, can we put that in the title?

Also, I think the author missed the real point. They have a shop where designs are done in caffeinated weekend pushes without input from other developers. This sounds like a shop full of junior developers. Engineering is not just about code. It is the balance of creation with constraints. They could have know the "old-new" system wouldn't have worked if they had some idea of load, or were measuring latency. They could have used these measurements to push a better design if they bothered with a design process. People would have supported the design, and slogged through bugs if people were bought into it actually be the correct design. Instead, we had a system written twice.

There's a reason senior engineers are paid what they're paid, and it's because it saves time like this. You pay a senior engineer because they sidestep these problems.

> There's a reason senior engineers are paid what they're paid, and it's because it saves time like this

The right senior engineers, yes. The wrong ones, OTOH, would have gone further down the crazy path, inventing an all-new programming language and runtime for the server-distributed code (for 'security' or 'performance' or whatever other reason seemed to pass muster).

> They have a shop where designs are done in caffeinated weekend pushes without input from other developers.

I have a strict rule on my teams: no development outside of work hours (whatever 'work hours' means for an individual, where there are roughly 8 work hours in a day and five work days in a week). It is absolutely vital that developers get to recharge their mental batteries, in particular because a symptom of overwork is bad judgment, and a symptom of bad judgment is being less able to judge one's own decisions. Log out, go home (or walk away from one's desk), spend time with one's family: the work will still be here tomorrow, or Monday.

That's interesting, I've never heard of a stateful microservice repackaging itself into a library that directly reads/writes to the database. One of the main advantages of a service middleman is encapsulation, and enforcing rules on what database operations are permitted.

The article mentioned that there are many different teams using this service/library. With the library approach, each of these teams has full permissions to the database. As long as they all remain disciplined and only ever access the database via the library, this should be fine. But I wonder how long it'll be before another bright developer somewhere realizes that they can write stuff directly to the database, in completely unintended ways, by bypassing the library.

This was a great read, thanks for posting.

previous discussion:

https://news.ycombinator.com/item?id=5337011

Reply on news.ycombinator.com