My approach to building large technical projects (2023)

From what I've seen it's standing up. His original statement/hypothesis is often misrepresented.

"there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."

If he had also included "volume" then AI would have disproved him! More anecdotally, the hands-on experiences of senior+ developers seem to firmly fall into the accidental camp, with the essence of software problem solving getting marginally easier as you'd expect with a new, powerful tool, but far from "solved".

> i.e. ones that can run offline and fake apis/databases

I can see a place for this, but these are no longer e2e tests. I guess that’s what “hermetic” means? If so it’s almost sinister to still call these e2e tests. They’re just frontend tests.

> A) refactor pretty much everything underneath them without breaking the test

This should always be true of any type of tests unless it’s behavior you want to keep from breaking.

> B) test realistically (an underrated quality)

Removing major integration points from a test is anything but realistic. You can do this, but don’t pretend you’re getting the same quality as a colloquial e2e tests.

> C) write tests which more closely match requirements rather than implementation

If you’re ever testing implementation you’re doing it wrong. Tests should let you know when a requirement of your app breaks. This is why unit tests are often kinda harmful. They test contracts that might not exist.

Interesting, especially the "Build for Yourself" section!

Building software for yourself can help you solve a problem you have. If you're also using the software yourself, you can fix bugs in the software. I found some bugs in a web server I'm building by trying to use it myself.

Couldn't agree more. Quick feedback is so important, it requires its own post.

When I want to try/fix something, if the setup itself takes hours, I lose heart and move on.

Thats why I love lisp (or anything with a decent Repl). Instant gratification.

Maybe I’ll get maligned for saying this, but as someone who’s managed and successfully delivered software projects of all sizes, I’ve become somewhat of a convert to the Scaled Agile Framework. I treat it exactly as intended, as a framework. It’s a strawman to adapt based on context, and what I value most is how it led me to explore deeper source material and form my own conclusions.

Over the years, I’ve learned that true success starts with clearly understanding why you’re building something. Without clear goals, it’s impossible to prioritize or even know where to start. That clarity drives better sequencing, and sometimes the wisdom to not build something at all.

The next critical factor is empathy. You have to see through your customer’s eyes and validate that what you’re building actually solves their problem. That doesn’t mean giving them everything they ask for, but rather understanding their pain points well enough to deliver real value.

Ultimately, most projects go over budget or underdeliver because teams spend too much time building the wrong things. If we instead focused on continually steering toward desired, valuable functionality (things people genuinely want or will pay for), more software projects would appear like successes.