How Software Development has changed in 20 or so Years

A conversation with a workmate made me think back to my early programming days, and how things have changed in the eighteen or so intervening years, so I thought I'd share a time from my early history. No punch cards though (I'll spare you my school days).

Back in 1986 I worked for HiSoft, and my product was DevpacST. This was a development system for programmers, who in those days were almost all assembly-language users. It included a graphical window editor, debugger, assembler and linker, and ran on the Atari ST, a 68000 8MHz machine with 512k of RAM. (A review of the American-licensed version 2 is here)

When I say this was 'my' product, it really was. HiSoft was about seven people total in those days, and every byte on the floppy was mine (except for the linker). I created the 68k assembler and a disassembler as my final year project at University and these ended up a few years later as the cornerstone of Devpac. The assembler got a lot more complicated (macros and conditionals) and the disassembler turned into a fully blown debugger (well as fully blown as 30k of code permits). Everything (except the linker) was written in assembler, and it assembled itself. In fact that was the most rigourous test we had for the assembler: could it build everything, and could everything then run? If so, ship it.

Classic bug: if the same person writes an assembler and a disassembler, from the exact same dog-eared processor spec, look out for bugs. I remember one rare opcode (CMPI?) which assembled to the wrong bytes, but I didn’t notice for the longest time because I made the same mistake in the disassembler. I had misread the spec page in the same way for both sides of the tool, and as I used the disassembler output to verify the assembler codegen, I never noticed. Eventually a customer did and we fixed it.

I remember the day that the source file for the assembler got too big to fit into the editor (over 200k of source) so I had to split it into two files. The assembler could run from within the editor doing everything in memory, so splitting the source meant that build times went from less than 10 seconds, to maybe 40 as it had to hit the floppy. That seemed like an age. (No need for grep in those days: the entire source fit into two files!).

The linker I inherited from one of the senior developers (who left) and was written in C. The debugging of that linker taught me the C language. The hard way: we didn’t have source level debugging back then, all debugging was at the asm level, though we could read global symbols at least. Local variables? Callstacks? Source debugging? I didn't miss those features as I had no concept of them in a debugger: asm was everything then. If you couldn’t figure out the locals from the disasm and the registers, you had no business writing C. If you couldn’t figure the callstack by manually walking though the memory, then either you were stupid, or you had trashed the stack somewhere.

It didn’t stop after the product had been built and tested by me. I wrote the docs too (~200 pages for the 2.0 version using Mac Word), made the master floppy (everything fit on a single 400k disk) and designed the cover (using Pagemaker). At busy times I also loaded and unloaded the floppy duplicating machine, stuck labels on the disk, and packed it all together.

Tech support was also me: we had an hour every afternoon set aside for phone support. We had to set aside a special time else we'de never get any work done. Foreigners, especially our few American customers, tended to call a lot later, and we'de usually break our rule for them. I did mail support too. (That's mail, not email - we didn’t have email then). When bugs were reported, we'd fix it right there and then, and produce a new version to send to whoever reported it. Other users could get the latest version for 5 pounds, if they returned their original floppy. Every now and again we'de get a great suggestion and add that in too, and put the details in the readme file.

So that's how it was, and to be honest it was really great. To be so involved in a product from owning every line of asm code to packing the things in boxes gave me an appreciation for every level of software production. However it was hard work: we worked late almost every night and many weekends, and would rush down the A5 at vast speed to get to our local pub before it closed at 11pm each night. We usually only had time for a single, very enjoyable pint of real ale.

Fast-forward to 2004. Still in the software business, still producing debuggers. However that's where the similarity ends. I work for the biggest software company in the world, and my dev team is the size of the entirity of HiSoft back then. I hardly code at all now (being a manager-type).

The Visual Studio debugger is written mostly in C++. It contains no asm code, and a little bit of C#. It plugs into an IDE and editor supplied by other groups in VS. The minimal spec machine for VS is 500MHz, 128M of RAM. Source code for the debugger consists of thousands of files and generates tens of binaries. I have declared arrays that are larger than an entire .exe was in Devpac.

Building the debugger takes maybe 10 minutes on my machine for one flavor (eg Debug). Building all versions of all of VS takes the build lab maybe eight hours across multiple machines, if it all goes well.

I don’t test the debugger per se (the QA team do that), though I dogfood it and run checkin tests on it. I don't write any docs (sans this blog) though I do review much of what User Ed produce for us. I have never made a CD with VS on it and don't have any idea where VS product is put together, nor do I have a desire to help out in that regard. I do a bit of external support, via this blog and some issues that come in from Product Support. I do a lot of internal support, helping dogfooders using the debugger at Microsoft.

Is it as much fun as it was at HiSoft? Probably not to be honest, but the business is so different, software development has changed a huge amount, plus I'm old now: zooming down the freeway to the pub late at night after a hard day at work isn't on my Must Do list any more. Plus there are no 'pubs' really in Redmond. Plus American cops are a lot more interested in such activites than UK ones ever used to be...