Busywork

Published 14 September 2017

My first small business wasn’t actually in the software industry. Back when I was a student, I did contract office jobs in the summer holidays to pay for things while I was studying. I got a feeling that I’d be happier self-employed than someone else’s employee, so after graduation I experimented with registering an Australian Business Number (ABN) and using it to do maths and sciences tuition. I went back to working for other companies eventually, but I learned a lot from the experience, and that know-how was extremely valuable later when I quit my full-time job to start my own little consulting business.

I might write more about that experience some other time, but for now I want to write about what’s been hardest for me to get used to: when you’re self-employed, no one cares how much work you do.

Compression, Complexity and Software System Design

Published 25 June 2017

Tags: Computer Science , Software Engineering and Systems Design

Information theory gives us a way to understand communication systems, by giving us a way to understand what happens to information as it’s transmitted or re-encoded.

We can also study what happens to complexity in a software system as components depend on or interface each other. Just like we can make rigorous arguments about how much information can be compressed, we can make arguments about how much complexity can be simplified, and use this to make better choices when designing software systems.

If You Need Lifeboats, That Means Your Ship is Sinking

Published 25 April 2017

Tags: Reliability , Ops and Software Engineering

It’s 1912 and Captain Edward Smith is boarding the RMS Titanic. He sees the lifeboats on deck and shakes his head with a heavy sigh before turning to the crew. “In my experience, I’ve never needed lifeboats. They’re not best practices — if you need lifeboats, that means your ship is sinking!” The crew members are enlightened and eagerly throw all lifeboats overboard. The Titanic begins its voyage to New York.

Update

Published 02 April 2017

Tags: dlang , Low Level , Software Engineering and Me

Just a quick update because I’ve been too busy to write much recently.

I’m giving a talk at DConf 2017 in Berlin! D’s been growing strongly in the past five years, and DConf’s been growing dramatically since the first one in 2013, so it’s pretty exciting to get involved. No, really. I often give tech talks at no-name events here in Sydney, but I’m half scared I’ll wet my pants on stage with a lineup like this — in my university days, I used to read all the C++ books by Andrei Alexandrescu and Scott Meyer that I could get my hands on.

If you have a DConf ticket, I look foward to seeing you there. If not, then you can look forward to watching the videos :)

Instead of writing a real blog post, I’m dropping a link to this classic about backwards compatibility nightmares, which you might like if you thought the mess that’s x86 BIOS booting was interesting. It’s a chapter from The Old New Thing, a book by Raymond Chen from Microsoft, based on his blog. Raymond Chen has spent a lot of his career making sure new versions of Windows can still run old software, no matter how badly the old software abused APIs and deserved to crash. Most of the technical details belong to the 90s, but there are plenty of morals for software development in the real world today. If you can read that chapter without ever wanting to weep for the industry, you’re stronger than I am.

On Not Optimising for Last Century's Hardware

Published 20 November 2016

Tags: Performance , Software Engineering , dlang and Low Level

Once upon a time I wrote a super-optimised algorithm for rotating data in an array. At least, it was meant to be super-optimised, but its real-world performance turned out to be terrible. That’s because my intuition about performance was stuck in the 20th century:

Break a program down into basic operations like multiplication and assignment
Give each operation a cost (or just slap on an O(1) if you’re lazy)
Add up all the numbers
Try to make the total in step #3 small

A lot of textbooks still teach this “classic” thinking, but except for some highly constrained embedded systems, it just doesn’t work that well on modern hardware.

Function Attributes and the D ABI

Published 05 October 2016

Tags: dlang , Software Engineering and Low Level

The D programming language has a bunch of built-in attributes like pure and nothrow. I was wondering how things like libraries might break if function attributes changed between versions, so I gave it a try.

A Tale of Three Server Caching Architectures

Published 30 July 2016

Tags: Systems Design , Servers , Performance and Software Engineering

Exactly where you put caching in a distributed system has a significant impact on its effectiveness, in ways that aren’t always obvious during the design phase of development.

DConf 2016 Talks

Published 24 July 2016

Tags: dlang and Software Engineering

The DConf 2016 talk videos have been released.

Here’s my (very short) list of special recommendations. They’re worth watching even if you don’t use D.

Code Versus Data

Published 21 June 2016

Tags: Software Engineering and Systems Design

Some years back I wrote a program in C++ using an obvious object-oriented architecture. Then, later, I had to rewrite it in C, and I learned some pretty good lessons about software design.

The Enterprise Pushbutton

Published 11 May 2016

Tags: Software Engineering , Anecdotes and Low Level

Let’s talk about a hardware driver for a pushbutton. A pushbutton driver isn’t as completely trivial as it might sound because you need debouncing logic to ensure a crisp on/off signal, but it’s hard to imagine how it might need more than about 100 lines of C code.

After working on this particular embedded system, I didn’t need to stress my imagination any more. This pushbutton driver was modelled as an explicit finite state machine, and all the possible states and transitions were specified in a spreadsheet. Then there was a python script that processed this spreadsheet and generated state table data as C code. This was linked to an FSM evaluator in C. The FSM was controlled by a bare-metal driver and triggered callbacks on each state transition.

Most of the callbacks were marked “not yet implemented”. In fact, only two states were even reachable: BUTTON_UP and BUTTON_DOWN. Eventually the entire project was canned, but not because of missing support for BUTTON_TIMEOUT or any of the other states.

The FSM didn’t do any debouncing, so the low-level driver had to do that before passing button up/down events to it.