He asked what else and I replied with a quick list. Below is “why” these don’t work. I offer this recognizing engineering is also a social scien

Hardcore Software by Steven Sinofsky

submited by

Style Pass

2024-12-30 09:00:03

He asked what else and I replied with a quick list. Below is “why” these don’t work. I offer this recognizing engineering is also a social science and what works/does not work is context dependent. One life lesson is that every time you say to an engineer (or post on X) that something won’t work it quickly becomes a challenge to prove otherwise. That’s why most of engineering management (and software architecture) is a combination of “rules of thumb” and lessons learned the hard way.

I started my list with “let’s just” because 9 out of 10 times when someone says “let’s just” what follows is going to be ultimately way more complicated than anyone in the room thought it would be. I’m going to say “9 out of 10 times” a lot below on purpose because…experience. I offer an example of two below but for each there are probably a half dozen I lived through.

Let's just make it pluggable. When you are pretty sure one implementation won’t work you think “I know, we’ll let developers or maybe others down the road use the same architecture and just slot in a new implementation". Then everyone calling the APIs magically get some improvement or new capability without changing anything. There’s an old saying “the API is the behavior not the header file/documentation”. Almost nothing is pluggable to the degree that it “just works”. The most pluggable components of modern software are probably device drivers, which enabled the modern computer but worked so poorly they are either no longer allowed or modern OSs have been building their own for a decade. The only way something is truly pluggable is if a second implementation is designed at the exact same time as the primary implementation. Then at least you have a proof it can work…one time.