A great way to get usable APIs is to let the customer (namely, the caller) write the function signature, and to give that signature to a programmer to implement. This step alone eliminates at least half of poor APIs: too often, the implementers of APIs never use their own creations, with disastrous consequences for usability. Moreover, an API is not about programming, data structures, or algorithms—an API is a user interface, just as much as a GUI. The user at the using end of the API is a programmer—that is, a human being. Even though we tend to think of APIs as machine interfaces, they are not: they are human-machine interfaces.

On the Edge, by Brian Bagnell, tells the history of Commodore, from their entry into and development of the personal computer industry, to their massive collapse just 15 years later.

Told mostly through new interviews with company engineer, this is a fascinating story of the good and bad management (mostly bad), internal politics, technology design, and short-sighted business practises that built Commodore up into a massive industry force, and yet led to its ultimate demise.

The book also describes how Commodore engineers created the new computers. Commodore was in the unusual position of owning a chip manufacturing company: “vertical integration” is how then CEO Jack Tramiel put it. This allowed the engineers to rapidly prototype new chip and board designs, which meant their product cycles were extremely low: entirely new systems were being created in 3 or 4 months before being demoed at CES conferences. Unfortunately, this rapid development would bake in bad architectural decisions, which following product teams would struggle with.

In some ways this is a very inspirational story. The development teams at Commodore were tiny: five or six core engineers would work on a system, and create entirely new chips, boards, enclosures, and peripherals — like the famous SID sound chip of the Commodore 64. And they would do it in extremely short time frames.

These small teams created the PET, the VIC-20, the Commodore 64, and the Amiga.

The book makes extensive use of interviews with Commodore employees; many chapters are almost entirely quotes. This, and the relatively light touch by the author, makes for an engaging and fast read. But it’s not great literature by any means.

The author does a good job of showing the differing accounts and memories of his subjects, and it is very interesting to see how differently people remember the same series of events.

The book makes a point of showing that Commodore, and not Apple, should be considered the creator of the personal computer. The case presented is good, but comes across somewhat too fervently, and makes the author seem a bit nutty at times.

This is a great read, and one that made me nostalgic for my old C-128D. Recommended.

Are there specific architects, historical eras, or urban designers who have inspired Dociu’s work? What about vice versa: could Dociu’s own beautifully rendered take on the built environment, however fantastical it might be, have something to teach today’s architecture schools? How does the game design process differ from – or perhaps resemble – that of producing “real” cities and buildings?
Of course, there are many types of games, and many types of game environments.

There’s some really beautiful concept design artwork included in the interview.