Bootloader Design Pattern

Make a clean start with extensibility and integration

Extensibility is a lofty goal for software design, and difficult to achieve. The Wikipedia article notes: Extensible design in software engineering is to accept that not everything can be designed in advance. That’s a paradox because it entails that extensible design does not accept that extensibility can be designed in advance! Fortunately, there’s at least one solution that can be intentionally designed and implemented in advance. I call it the “Bootloader” design pattern. Read more...

Database Scalability: Contention and Crosstalk

Do more with less

New engineers might not know and experienced engineers might not believe that database systems do not and cannot scale gracefully to 100% system capacity but, rather and counterintutively, exhibit retrograde performance at some point less than 100% system capacity. The reasonable presumption is: We presume that a database can scale to almost 100% of system capacity, and max performance is a small fraction at the very top (right, orange slice) because, after all, the system itself needs some resources to run itself. Read more...

Crash-safe MySQL Replication

A Visual Guide

MySQL crash-safe replication is an old feature (~4 years as of MySQL 5.6), but it’s not consistently understood or applied. The MySQL manual on the topic, 16.3.2 Handling an Unexpected Halt of a Replication Slave, is correct and authoritative, but unless you grok MySQL replication that page doesn’t make it obvious why crash-safe replication works. Other blog posts explain why, but sometimes add other considerations, making it unclear which settings are necessary and sufficient. Read more...

Tech Workers Are Good People

Maybe A Few Are Villains

The Other Tech Bubble is a provocative and interesting read. The author clearly has a lot of experience with Silicon Valley and has done their homework. There are many good insights, like “They’re still asking if it’s possible to do something, and not whether they should.” But there are two claims and one ambiguity that need to be addressed. Villains The first claim is: In 2008, it was Wall Street bankers. Read more...

Approaching a New Software Project

How to start and where to go

Approaching a new software project is difficult for two reasons. First, there’s no “guiding star”, no objective starting point. The developer can begin from and proceed in many directions, which makes choosing difficult. They want to proceed in a good direction from the start, not wasting time or effort, but how can they make a good choice without a guide or the benefit of experience? Being forced to choose and move ahead, the choice is often made randomly rather than methodically. Read more...

Ideas, Leaders, and Engineers

The Senior Engineer’s Guide to Helping Others Make Decisions is a good read and good advice. I would summarize the advice as: “Seek first to understand, then to be understood” (Dr. Stephen Covey) Lead and guide, don’t micromanage Embrace change, which entails embracing other people’s thinking and way of doing things In the first dialog, the senior engineer fails those three points. Av’s blog post made me think… Read more...

Five-Point Checklist for Excellent Software

Five ways to make your code excellent

I’ve never met a developer who hasn’t read or reviewed a lot of code written by other developers. If there’s one truism in the field of software of engineering it’s that the process is collaborative. Unless you write and never release software, other people will read the code, and they’re most likely reading it not for a fun bedtime story but because they need to understand and probably fix or modify it. Read more...

Designing Tools for Integration

Using factories, hooks, and context to make tools extensible and customizable

When we write a new tool to do X, it’s common to program the tool to do X in one way. When X is trivial or very narrow in scope, this makes sense, and programming any more would fall prey to over-engineering. However, when the tool does many things (all logically related, else it falls prey to bloat and/or feature-creep), there quickly becomes many ways to accomplish those many things. Read more...

How To Test the Database

It's important but not special

“How do I test the database?” is a question I’ve been asked by colleagues many times. There’s a good, clean solution, but let’s first step back from what seems to be the problem to unpack why “testing the database” is not special (but nonetheless important). In other words: colleagues don’t ask, “How do I test such-and-such package?”, because that’s common and well understood. The question about testing the database implies that the database is a special beast that, if not treated properly, will devour the developer in their sleep. Read more...

Design Before Implementation

Why great software design requires form before function

Like most software engineers, I review my colleagues’ code. I rarely provide feedback on implementation details because developers rarely choose obviously bad implementations. I focus my attention on design rather than implementation for one simple reason: implementation details are easy to change when software is well designed. Or, from the business perspective, design is the most costly aspect of software to change, so I review for great and therefore cost-effective design. Read more...