I read most of the print version of this (which is very nice and I can recommend). One thing that really sticks out about this is just how much work in such a project ends up going nowhere — you record something, you try using it weeks later, you realize it's useless, you do it again differently/better, lather, rinse, repeat. I'd somehow forgotten about this and started feeling kind of bad whenever I was working on something creative-ish (using it very broadly here) and didn't know exactly where each step would lead me. This sort of firsthand account of large projects goes a great way in reminding you that that's just part of the process.
We often forget that if something took one hundred attempts, then we've learned ninety-nine ways something won't work. Those failed attempts do go somewhere in the progress of project, they're just not apparent to the observer.
And while this happens at the company scale (1/100 startups succeed) I’m wondering why it doesn't happen at the software scale. Why aren’t product teams trying out many ways to meet users needs, scrapping, iterating, prototyping, and then finally building? Most of the time it’s: I want this feature, build!
And it’s not just that perfection takes longer to achieve; the estimate of how long it will take to reach it will be less reliable than that of multiple smaller steps.
Because of that, I think one can even argue good is the enemy of good enough.
As a simple example, a product is more likely to see the addition of, first, one report, than a second, a third, etc, than the addition of a good report builder.
For the former, each step is relatively simple, and first value will be delivered sooner. For the latter, you’ll have to answer questions about what the full range of to be supported reports would look like.
Even if you, up-front, know you’ll need to support tens of different kinds of report, it may be hard to argue that you need a report builder even if that seems to be the better choice to get to the end result.
If you do end up with a report builder, it likely will be one designed by and written for developers. As an example, look at headers and footers in Excel, where, I think to this day, you have to type && to get a single &: https://www.journalofaccountancy.com/issues/2018/sep/excel-h....
I suspect this might be why most open source software struggles to reach the quality of commercial products. If it takes 10 attempts to get the major design questions right a company will either get there eventually or get outcompeted. Open source projects typically grow out of somebody scratching their own itch, and that doesn’t involve the scrapping and iterating necessary to make a product that fits many users’ needs.
Asana does (and Dropbox did) do a bunch of A/B testing all the time, usually with smaller features, to determine what works best, and will quite often evolve on the existing product and remove features they think they can do different or better. But of course one of the limiting factors is you can’t be too disruptive to your users (that’s why A/B testing is the slightly more gentle approach)
I also bought a print copy of this a while back from Stripe Press, along with a few other books. Haven't gotten around to reading them yet (I've been bad for reading lately) but gosh are they beautiful-looking books. They taunt me from the shelf every day.
I was at a friend's halloween party around 2010 (with a bunch of ex-USC people) and there was a guy quietly sketching in the corner, I walked over and immediately recognized his drawing style. "are you Jordan Mechner?" I followed his sketch blog at some point. we had a short conversation, I told him how much I loved The last express (he joked I might be the only one) and I didnt mention how young I was when I discovered prince of persia. Really great guy, quiet, unassuming and just nice.
Interesting party that night, I met another game industry person I admired as well as some other fascinating folks.
The Last Express seems to have some kind of a renaissance in the past few years. It's about 25 years old buy now, which definitely fits the "retro" category, and as part of that people into computer gaming history rediscover it and laud it for what it is.
true but also in many ways it was successful, within the limits of what could be done at the time. the way every event on the train keeps going regardless of whether you're there or not is something that nowadays you'd associate with a game like Outer wilds, a wonderful physics sandbox of a puzzler, but Last express did it with FMV and point and click! it's damn impressive and I bet a remake using something like metahumans could be interesting.
A lot of effort had gone into the motion-capture of the characters. Having played the game back in the day, it was well worth it - the movement was so realistic.
Quite funny thinking about the amount of effort required to get the equipment for this, when you consider I can literally just pull something more capable out of my pocket now.
A true masterpiece. Journals of this type is what we need, to understand the actual inner thoughts of people going from 0 to 1. Much better than marketing nonsense filled by survivals bias.
I’ve got the hard cover version from Stripe. As someone that also moved to the Bay Area fairly young to start his career, I identified with the author. It’s a cute book and really does a great job of putting you in his head.
I found it funny that he wasn’t sure that the video games industry would last.
I've bought a few books from Stripe Press and they are all high quality. My only complaint is that some of them use a very small (to my old eyes) font. I bought The Dream Machine from them and ended up finding an electronic version for my ereader.
Yeah I have a few books from them including Human Puzzle and one other I'm blanking on just now. All have been things that feel nice in the hand. I can see how the font would not be great if your eyes struggle with their font size choice though.
If you like it, check out other books from them. They're a small publisher but what they decide to print aligns pretty well with the interests of many HN readers.
Thanks for linking to this, it let me look at the list and remember Hamming's book was the other one I bought. I really need to finish reading it, but it is so dense it takes a while to get through.
> I found it funny that he wasn’t sure that the video games industry would last.
At the time, video games seemed to be overly saturated, the marketplace was way down in sales and yes, people didn't know if video games were a passing fad or not. Computers were still more a hobbiest item rather than a thing everybody had.
ArsTechnica did an awesome "War Stories" edition with the same Jordan Mechner on how they got around memory limitations on the Apple II. It's like a video side bar to this PDF.
But I said: “No advance, no salary, and a
20% royalty. That would be my ideal.”
He came right back with: “My ideal would be
no advance, no salary, and a 15% royalty.”
Today, can an indie developer command much larger royalties than this? I would think/hope so? What kind of a cut do stores like Steam take? ~30%? Does that leave the other 70% for the indie developer?
I suppose the indie is still responsible for marketing and all kinds of other stuff.
Just wondering do we have similar books for more modern games that more or less focuses on the technical/design details? By saying "modern" I mean games in the 90s and beyond.
I have already read the following books:
- Masters of Doom
- The three Fabien books (just briefly as I'm not very technical)
Andy Gavin has a fairly extensive series of posts on his blog about the creation of Crash Bandicoot that I quite enjoyed. Goes over the process of even choosing to be on the PlayStation at first (over other systems), the design process, limitations they ran into, and some of the ingenuity put on display to pull off some fairly impressive technical feats.
Thanks! I did read his blogs but forgot to mention in the original post. I must say, I find these "Game dev in restrained env" books/blogs really fun to read!
Had a lot of fun playing this back in the day on the PC. The game was relatively simple as far as content goes, but it never felt repetitive or monotone.
The making-of also reminds me of Eric Chahi and his work in Another World, and how pioneering it was.
There's some real superheroes in game dev for anyone out there looking for inspiration -- Mechner, John Carmack, Lucas Pope, Chris Sawyer. They seem to be not just good at programming, but _everything_. I absolutely love reading dev diaries from folks like this.
I recall reading it, and strangely I felt that making of the game is just a side-happening, while the author was on pursuit to get into movie industry rather.
Am interesting contrast, given most people know and are amazed by the game in retrospect.
I liked his journals from Karateka better than those from PoP. He was much less cocky then and his innovations seemed more novel and exciting, plus you know he was squeezing a lot more out of the hardware from that time.
MoD was really an amazing book, though. Highly recommend for anyone who played the game back when it was still new (or anyone interested in a case study in product management).
Second on Masters of Doom; my favorite part is near the beginning, when Carmack showed Romero the smooth scrolling on a PC, and Romero is running through the office trying to show everyone, only for most of them to be largely unimpressed. I thought it was telling that the only person who really understood what Carmack had made was Romero, and it showed why they (initially) made such a good team.
