[varunneal]

Hilarious post. I recommend people read to the end

> If Jeffries started with a different core representation, then it's likely his subsequent design decisions would also change. The bookkeeping for constraint propagation might push him towards Norvig's relational approach to the rules of Sudoku; rather than continually recomputing the rows, columns, and boxes, he could simply have a map of each cell onto its peers. He could distill every lesson of the previous posts, creating something simpler and faster.

> But Jeffries isn't in the business of starting over. He not only believes in incremental design, but in using the smallest possible increments. In his posts, he regularly returns to GeePaw Hill's maxim of "many more much smaller steps." He is only interested in designs that are reachable through a series of small, discrete steps.

Jeffries has radicalized me. This sort of puttering-around with "incremental design" is too pervasive in the corporate world. In software we have the luxury of rethinking from first principles, and we must use it. Death to MMMSS

[taurknaut]

> In software we have the luxury of rethinking from first principles

What does this even mean? I'm aware of the meaning of "first principles" and it doesn't seem to relate at all to software development at all. I can imagine using this when trying to figure out how code works, but I can't figure out how it relates to building the software to begin with. What questions are you trying to answer where first principles would even come up?

[fragmede]

One example is with databases. In the olden days, if you needed performance, you bought a big Oracle server, and that was that. If you needed more performance, you just bought a bigger one. Without revisiting the database from first principles, we'd still be using acid-compliant relational SQL databases for everything. By starting from first principles and asking what the database software is for, and considering a changed hardware landscape aka the cloud, among other factors, we now have other types of databases which are more appropriate for different kinds of workloads. Key-Value stores, document stores, Wide column stores, Graph databases, time-series databases, NewSQL databases, vector databases; all of those are an example of first-principles rethinking of the database, and being willing to throw out the rules and ACID compliance in favor of what's actually necessary for a given workload instead of continuing on with existing conventions.

[kthejoker2]

I find this post ironic in that it (unintentionally) mirrors the atticle's point.

Graph (hierarchical) databases and time series (SCADA) datbases predate your (implicit) definition of "database" as a "relational datbase."

Key values have also existed before Oracle came to be.

It's never really been a matter of "rethinking from first principles".

Like Norvig's contraint propagation in the post, it has been about choosing the right design for the problem at hand, instead of trying to fit square pegs into round holes.

[srpablo]

It's a thing tech (and tech-adjacent) people say when they rub their temples and decide to try to work out the solution to a problem from their existing ideas and biases instead of considering what anyone else has said about it.