Hacker News Reader

Comment by doomlaser | Hacker News Reader

Impressive id went through development of Quake 3 with no version control.

When I was interning at Apple back in the day I had a side project of porting wolf3d to OS X, and it was the first occasion I had where I came to admire John Carmack's code directly. His game source code is something I recommend checking out to coders interested in gamedev.

Also, I have fond memories of poking around making DOS experiments in Borland C++ as a teen.

But speaking of version control — I guess that's just how things were done in the 90s. I read recently that not only was Final Fantasy 7 developed and shipped without it, but Squaresoft contemporaneously lost the final PlayStation source code and art assets. The studio contracted to port it to PC was supplied with a mishmash of non-final code and assets.

View on HN

Many times in programming, someone has given a name to something long after a segment of the population had already discovered it for themselves. This can lead to a weird effect where people who in fact approve of a technique end up sounding dismissive because of course everyone already does this it's no big deal. Not everyone is doing this and it can be a big deal.

To date myself a bit, the first time for me was Refactoring, and one of the most recent was the Mikado method (a technique for top-down refactoring). The reason I'm book-ended this way, and the point of my response, is that Mikado requires you to be very comfortable both with version control and throwing away a big chunk of code you just wrote.

I don't think I would have ever sussed out Mikado if I were trying to do Poor Man's version control. I think the cost-benefit analysis would fail.

The thing is, the Mikado method, at its best, makes you look like some sort of coding god, because you've accomplished some gigantic change to the system behavior with fifty lines of terribly reasonable code. Instead of five hundred lines of error-prone nightmare.

Version control software was a lot more primitive and less fun to use in the 90s. On Unix you had CVS, on Windows just VSS. SVN, Mercurial and Git all came post 2000.

And it took SVN a couple extra years to be performant on Windows, which at the time was still the dominant development environment in many places.

Maybe my second SVN project, we had a monorepo, Windows, and a virus scanner (multiply pull time by five). I'd come in in the morning, log in, do an svn up, go get coffee and say hi to the people I was collaborating with, and be back to my desk all before it finished.

Many days I only synced to head twice because it was a pain in the ass, and the SVN maintainers were not at all sympathetic. A new contributor consolidated the config files and cut the number of file open operations by a couple orders of magnitude. I don't think we ever properly thanked that guy.

> A new contributor consolidated the config files and cut the number of file open operations by a couple orders of magnitude. I don't think we ever properly thanked that guy.

Unspoken benefit of “new person” — eventually someone not desensitized to the crap will throw up their hands and fix it.

Sometimes it's so tiny too, but requires you to look at code that nobody else has a reason to look at any more.

I once increased performance of a CMS by 30 percent my first day in the job because I happened to spot a handful of lines of unnecessary string copying while trying to figure out how the thing worked.

Everyone else could have, but none of them had any reason to look at that part of the code because it worked.

There's definitely something to be said for occasionally throwing a fresh frog into the pot to see if the slowly boiling frogs are, indeed, boiling.

I remember using SVN in the early days and it was a huge pain. Some days it even seemed like it caused more problems than it solved. I don't think the situation really improved until Git came along and gave it a kick up the arse.

That said, modern SVN is nice to work with in my limited experience but I'm definitely firmly in the Git camp now.

Early 90s revision control flashbacks on the Windows front ... I recall living through migrations from MKS RCS (by Mortice Kern Systems) to SourceSafe (when it was a One Tree Software product before MSFT bought it) and eventually VSS.

Commandline automation of these for build or deployment scripts was painful but we were grateful for any source control on Windows at all because the alternative was still common and it sounded like this, shouted over a cubicle wall: "Hey, I'm going to edit UTIL.C on the WFW3.11 share ... everyone okay with that?" Cringe.

VMS had pretty nice version control, if you happened to be working on a VAX. It's hard to believe, but in the early 90s you still saw non unix (clone) OSes in the wild.

> Impressive id went through development of Quake 3 with no version control.

I'd say that taking a backup of the code at the end of the day and sticking it all in a directory on a server somewhere constitutes version control. Especially as Id documented everything they did so thoroughly (based on Carmack's .plan files etc).

When SVN and Git came along they basically just streamlined and improved practices that a lot of devs were already following - and added some useful features like merging with proper conflict resolution and whatnot.

Where could I find his code to take a look at? Is there a reputable source or should I just Google it?

If you're going to go down memory lane, take a detour and read John Carmack's plan files.

It's a daily blog of progress / lessons learned on whatever he was working on during the listed years.

The whole archive is at: https://github.com/ESWAT/john-carmack-plan-archive/tree/mast...

The 1990s is when it was most active.

id Software has a public GitHub and many of their classics are open sourced (Doom, Quake, etc): https://github.com/id-Software/

Awesome, thank you for the link!

Check out https://github.com/id-Software they've published a lot of things there.

I really liked reading DOOM's source code :)

Reply on news.ycombinator.com