|
I came up with a three-tier model myself: 1. API or API-like things (grep)
2. Highly configurable app (Photoshop, Word)
3. Default-heavy app (Instagram)
The tricky thing is that 1 and 3 are the easy slices, relatively speaking. If you only need the 80% case, it can probably be automated into something as simple as a selfie app, with a finite, well-understood level of design and engineering. And if you need something extremely custom, you want the data model exploded into its smallest parts so that you can put it back together again - and the small parts can again be relatively simple, well documented, and easy to maintain.But the middle part, the product that is complex and configurable, but not really "programmed" with code except through a limited script layer, is the fat middle, because it demands so much more UI, and an experience that is well-integrated, amenable to default workflows, and yet also very easy to customize. Over time, big software projects always drift towards the middle. The article specifically fits my model's type 1. A type 1 product is nearly ideal for the hacker who wants to glue together a bunch of different technologies. It only falls down when the abstractions are too crude or mismatched to the problem. But the operating system itself is more like a type 2 product - there are numerous assumptions about what the environment, services, access methods, etc. look like, conventions that were established early on in computing and haven't yet been revised. Every programming language makes accommodations for working in that environment, and not your weird custom operating system. |