Preventing unintentional use of Unintentional Programming

In my last devblog post, I introduced the concept of Unintentional Programming (UP). While written as a tongue-in-cheek parody of Intentional Programming, it’s a very real and frequently-encountered phenomenon.  Obviously, no good software engineer intends to practice UP — yet somehow, we still sometimes manage to write code that looks like the result of UP.  How does that happen, and what can we do to prevent it?

To answer those questions, I started by looking for trends in both “intentional” and unintentional” code I’ve seen.  (I use “intentional” to describe code which makes obvious both the problem it tries to solve and the way it tries to solve it.)  Here are some of my most noteworthy observations:

  • Otherwise bad code may still be highly intentional and thus easy to predictably fix and mentally verify.
  • Of all possible types of bad code, unintentional code is the absolute worst as it defies maintainability itself.Unintentional code often results from the compounded accumulation of minimal-change fixes (or misguided spot fixes) to a poorly-understood or already-overly-complicated area.


  • Unintentional code often results from an incomplete or incorrect root cause analysis.



  • Intentional code tends to naturally fall out from clearly and accurately understanding the problem.In an event-driven desktop application, one extremely common manifestation of UP is needlessly repeated identical executions of a potentially-expensive event handler.Unintentional code often results from a temporary scaffolding or workaround accidentally becoming permanent.


  • Every developer tends to assume their intentions will be obvious to any other developer; it’s just a common pitfall of human psychology that nobody is immune to.
  • More liberal usage of asserts could have surfaced many instances of unintentional code earlier, but reliance upon them isn’t enough, since the developer has to anticipate what to assert against, and unintentional code by definition works for reasons unexpected by the developer.Unintentional code slips through quality gates and into released software because it seemed to be working, so nobody ever thought to question what it was actually doing or how it was arriving at its results.


  • Testing (of any kind, including manual) can never surface all unintentional code, because even the most creative tests only verify that the product’s results are correct; testing cannot explain how the product arrived at a correct result.

Knowing these things, we can begin to dream up ways to prevent Unintentional Programming.  Here are some things we could try:

  • Engineering teams need to aggressively “shine a light” on “spooky” code areas that (almost) nobody understands.  Allocate time and people to efforts such as refactoring and adding true unit tests.  Do group readings/refactorings of spooky code so engineers can leverage each other’s insights and ideas to come to an understanding about how the code works and massage it into a more self-evident form.
  • Apply the “5 Whys” method of root-cause analysis to all proposed code changes, especially bug fixes, to ensure we’re always changing and fixing the right things for the right reasons.
  • Require at least one other engineer to build and step through any proposed change before calling it good.  It’s also a good idea to explicitly name the individual who performed that step in the change description, so that anyone looking through change history has one more person they know they can ask about that change.
  • If code makes an assumption, it either needs to gracefully handle any violation of that assumption, or assert that the assumption is true.  Asserts help catch problems before release.
  • Engineers should be stepping through the code in the debugger for common/core usage scenarios as part of every release’s manual test pass.  This will add confidence that the code is still working the way it’s expected to work under the hood, in a way that can’t necessarily be caught by unit tests, integration tests, UI automation tests, or dogfooding.
Posted in Uncategorized | Leave a comment

Unintentional Programming


In computer programming, Unintentional Programming (UP) is a programming paradigm inspired by the old adages, “Even a stopped clock gives the right time twice a day” and “If it ain’t broke, don’t fix it.”   It is a method for writing source code that happens to produce apparently-correct results upon cursory inspection, but without arriving at those results through any intentional, correct, sensible, or predictable internal operation.  By not thinking through all possible states, adding non-obvious dependencies on untested assumptions, not stepping through program execution, and creating needlessly convoluted workarounds to simple problems, the programmer greatly increases the probability their program will accidentally produce superficially correct results for at least some contexts.

Because software developed using Unintentional Programming arrives at correct results through sequences, states, and inputs never imagined or intended by the programmer, such software is incredibly difficult to maintain or improve.  The extreme disconnect between internal program operation and external results means that any change made to the source code can produce disastrously unexpected results.  Identifying why the program happens to produce correct results in some cases is just as difficult as identifying why it happens to produce incorrect results in other cases.  The conditions and sequence of operations that lead the program to produce incorrect results are so convoluted and difficult for the human mind to comprehend that the program’s behavior is, for all practical purposes, non-deterministic.

Due to its unpredictability, source code developed via Unintentional Programming can be frustrating for all members of an engineering team to work with.  For example, any attempt to replace some portion of the source code with new code that intentionally arrives at correct results will inevitably result in “breaking” cases that happened to produce correct results for the wrong reasons before the change, but which now produce incorrect results for the right reasons, frustrating everyone who thought it was working just fine before the change, naturally motivating them to fault the programmer who made the change rather than the unintentional nature of the old code.  Developers tasked with gradually transforming an existing large body of UP source code into software that behaves intentionally, sensibly, predictably, and correctly, face higher rates of nervous breakdown and ulcerative colitis than do their peers stranded inside underground bunkers on eerily magnetic tropical islands following airplane crashes.

Posted in Uncategorized | Leave a comment

WIN+F can go WIN+FUCK itself

Some recent Windows 10 update introduced this stupid new “Feedback Hub” thing that gets triggered every time I hit WIN+F.  This is supremely obnoxious because I often do remote development on a Mac over VNC from my Windows 10 PC, and WIN+F is the key combination used to invoke the “Find” dialog in most Mac apps when operating a Mac using a PC keyboard.  So at least half the time now, when I’m in a full-screen remote desktop (VNC) session to my Mac and I hit WIN+F to search for some text, I’m ripped completely out of my remote session by Windows 10 and presented with the god-damned-mother-fucking-Feedback-Hub-yet-again!  Microsoft, get off your collective asses and at least provide an option to DISABLE THE WIN+F SHORTCUT KEY FOR INVOKING FEEDBACK HUB!!  And before anyone asks: yes, I already sent Microsoft this feedback using the fucking Feedback Hub!  *Picard*facepalm*

Posted in Uncategorized | Leave a comment

Fix for SMSL M6 DAC losing USB sync and going silent due to static discharge when you touch it

Received my SMSL M6 DAC today, and it’s everything I’d hoped — except for one nagging problem: about half the time that I’d reach over to adjust the volume, the unit would stop producing sound and the PC would seem to think the device was disconnected.  Sometimes it would even cause all the other USB devices connected to the same hub to reboot themselves! Some online sleuthing and local elimination-of-factors revealed this to be a simple design problem: there is no solid ground connection between the shield of the USB jack and the metal case. It was pretty simple to take the unit apart, solder a grounding wire to the USB shielding inside the unit, and then loop the bare end of that wire around one of the screws when reassembling the case. Problem solved! It just sucks that such a simple thing should plague an otherwise excellent product.

Posted in Uncategorized | Leave a comment

Not all DACs are created equal

One of my many hobbies, born of necessity due to playing in my own band, is audio recording and engineering.  As such, I’ve spent a good chunk of change on decent-quality entry-level audio recording and playback gear, and I’ve burned hundreds of hours at my home PC working on mixes using said gear.  Yet it seems there’s always a lesson left to be learned the hard way and another better piece of gear to purchase.

I’m not an audiophile, but I am a musician with a good ear and a BS in Electrical Engineering.  I generally understand what goes into making, manipulating, and reproducing sound, and I’ve begun to see the relationship between certain traits of audio equipment and the resulting sound.  One thing that annoys me about many self-proclaimed audiophiles is that they have no real engineering or music-making background, so while they can sometimes hear that something sounds better (while at other times simply *thinking* something sounds better due to other factors such as brand name or price), they suck at explaining to the layperson exactly why one piece of gear sounds better than another.  I’ve often noticed audiophiles using terms like “sound stage” and “resolution” when discussing the ability of an audio playback device to respond rapidly and accurately to very low-volume and/or high-frequency non-primary wave forms.  Generally speaking, the higher the quality of an audio playback device, the better it is at reproducing such wave forms, and the more indescribably detailed and clear the music will seem as a result.  If you’ve never heard the difference, it’s difficult to explain, but allow me to try: if the earbuds included with your smartphone are like looking through a foggy slightly-out-of-focus window, then the real high-end-audiophile-grade stuff costing tens of thousands of dollars and typically used by real recording/mastering studios is like completely removing that window entirely and replacing your eyeballs with Hubble Space Telescopes.

I learned a few years ago the value of a good DAC + headphone amplifier (like my FiiO Andes e07k) to drive studio-quality earphones (like my Audio Technica ATH-M50s) or earbuds (like my Ultimate Ears UE900s) for both casual listening and mixing/production work.  While the amp helps drive more power-hungry earphones, the real magic lies in the DAC, which is of much higher quality than the headphone or line-out jack found built into any PC or laptop.  With entry-level “audiophile” earphones or earbuds, it’s very easy to hear the difference: bad DACs make the music sound flat, lifeless, and muddy, while good DACs make the music sound deep, sparkly, and clear.  In fact, if you’re doing mixing/production work, having a high-quality DAC is downright necessary, because otherwise you just can’t hear your own work accurately.  Using a bad DAC to mix or produce audio is like trying to refine a photo in Adobe Photoshop on a fuzzy black-and-white television.

One other piece of gear I own is a Focusrite Scarlett 18i6 USB audio interface.  It’s meant to be an all-in-one digital interface for both solid-quality recording and playback at high bitrates, so I’ve used it for ages as the primary audio device on my main PC.  It always worked admirably for recording with my laptop, so I naturally assumed the playback side would be equally strong… but I was WRONG!

I’ve been working on some mixes, struggling to get them sounding clear across a range of different playback systems (smart phones, car stereos, Bluetooth speakers, PA speakers, etc).  I thought I had the mix balanced just right, ran a render to raw WAV files, and then settled in with my iPad Air 2 and UE900s to give them a sanity-check… and was shocked to hear how ear-piercingly loud the cymbals were and how horribly muffled the guitar was, relative to what I’d spent hours working on.  I plugged the UE900s into my Scarlett 18i6 on the PC and pulled up the exact same WAV files — dull, bland, lifeless, with none of the details I’d noticed while listening on my iPad.  I swapped out the Scarlett 18i6 for my FiiO e07k (with bass/treble set flat) on my PC and pressed Play again — and it sprung to life, sounding almost exactly like what I’d heard out of my iPad.  I plugged my reference monitors into my FiiO e07k and heard the same details I’d heard out of it through my UE900s.  Using the FiiO e07k, I was easily able to correct my mix and even improve it well beyond what I’d thought was possible.

So, lesson #1: the playback DAC in the Scarlett isn’t very good.  And lesson #2: the DACs built into the iPad Air 2, iPad Pro 9.7″, and iPhone 6S Plus all sound quite respectable.

Of course, the FiiO e07k isn’t even the world’s greatest DAC; according to audiophile reviews, it falls somewhere in the medium-low end of the quality spectrum.  The FiiO is intended for portability anyway, and I needed a better permanent solution for my desktop PC, so I did a bit of research and ordered an SMSL M6.  It should be a slight step up in sound quality in a nice desktop-suitable form factor.


Posted in Uncategorized | Leave a comment

Configure Outlook to always show meeting reminders on top but without stealing keyboard focus

  1. WIN+R, C:\Program Files (x86)\Microsoft Office\Office16\SELFCERT.exe
    1. Note: on some installations, it’s located instead at C:\Program Files (x86)\Microsoft Office\root\Office16\SELFCERT.exe
  2. Name=”Reminders Always On Top”, hit OK.
  3. Open Office 2016, hit ALT+F11 to open VBA window.
  4. In the tree on the left, expand ‘Microsoft Office Outlook Objects’ and double click on ‘ThisOutlookSession’
  5. Using Chrome (not Edge!) to view this page (because Edge somehow screws up the EOLs when you copy/paste *facepalm*), copy/paste the following code from here into the VBA editor:

    Private WithEvents MyReminders As Outlook.Reminders
    Private Sub Application_Startup()
        On Error Resume Next
        Set MyReminders = Outlook.Application.Reminders
    End Sub
    Private Sub MyReminders_ReminderFire(ByVal ReminderObject As Reminder)
        On Error Resume Next
        Call ActivateTimer(1)
    End Sub
    Private Sub Application_Reminder(ByVal Item As Object)
        If TypeOf Item Is AppointmentItem Then
        Call ActivateTimer(1)
        End If
    End Sub
  6. In the tree on the left, right-click in empty space and choose Insert >> Module, then double-click on ‘Module1’.
  7. Again using Chrome (not Edge!) to view this page, copy/paste the following code from here into the VBA editor:

    Option Explicit
    Private Declare Function SetTimer Lib "user32" (ByVal hWnd As LongByVal nIDEvent As Long, _
        ByVal uElapse As LongByVal lpTimerfunc As LongAs Long
    Private Declare Function KillTimer Lib "user32" (ByVal hWnd As LongByVal nIDEvent As LongAs Long
    Private Declare Function IsWindowVisible Lib "user32" (ByVal hWnd As LongAs Long
    Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName _
        As StringByVal lpWindowName As StringAs Long
    Private Declare Function ShowWindow Lib "user32" (ByVal hWnd As LongByVal nCmdSHow As LongAs Long
    Private Declare Function SetWindowPos Lib "user32" (ByVal hWnd As LongByVal hWndInsertAfter As Long, _
        ByVal As LongByVal As LongByVal cx As LongByVal cy As LongByVal wFlags As LongAs Long
    Public Declare Function GetTopWindow Lib "user32" (ByVal hWnd As LongAs Long
    Public Declare Function GetWindow Lib "user32" (ByVal hWnd As LongByVal uCmd As LongAs Long
    Private Const GW_HWNDFIRST = 0
    Private Const GW_HWNDNEXT = 2
    Private Const SWP_NOSIZE = &H1
    Private Const SWP_NOMOVE = &H2
    Private Const SWP_NOACTIVATE = &H10
    Private Const HWND_TOPMOST = -1
    Private Const HWND_TOP = 0
    Public TimerID As Long 'Need a timer ID to turn off the timer. If the timer ID <> 0 then the timer is running
    Public hRemWnd As Long 'Store the handle of the reminder window
    Public Sub ActivateTimer(ByVal Seconds As Long'The SetTimer call accepts milliseconds
        On Error Resume Next
        If TimerID <> 0 Then Call DeactivateTimer   'Check to see if timer is running before call to SetTimer
        If TimerID = 0 Then TimerID = SetTimer(0, 0, Seconds * 1000, AddressOf TriggerEvent)
    End Sub
    Public Sub DeactivateTimer()
        On Error Resume Next
        Dim Success As Long: Success = KillTimer(0, TimerID)
        If Success <> 0 Then TimerID = 0
    End Sub
    Public Sub TriggerEvent(ByVal hWnd As LongByVal uMsg As LongByVal idevent As LongByVal Systime As Long)
        Call EventFunction
    End Sub
    Public Function EventFunction()
        On Error Resume Next
        If hRemWnd = 0 Then hRemWnd = FindReminderWindow(100)
        If hRemWnd = 0 Then
            If TimerID <> 0 Then Call DeactivateTimer
            If IsWindowVisible(hRemWnd) Then
                If SetWindowPos(hRemWnd, HWND_TOPMOST, 0, 0, 0, 0, FLAGS) <> 0 Then ' Move it into the 'topmost' band
                    If SetWindowPos(hRemWnd, HWND_TOP, 0, 0, 0, 0, FLAGS) <> 0 Then ' Move it to the top of the Z-order
                        Dim hTopWnd As Long: hTopWnd = GetWindow(hRemWnd, GW_HWNDFIRST)
                        While hTopWnd <> 0 And 0 = IsWindowVisible(hTopWnd)
                            hTopWnd = GetWindow(hTopWnd, GW_HWNDNEXT)
                        ' SetWindowPos won't work while user session is locked, so we must double-check.
                        If hTopWnd = hRemWnd Then
                            If TimerID <> 0 Then Call DeactivateTimer
                        End If
                    End If
                End If
            End If
        End If
    End Function
    Public Function FindReminderWindow(iUB As IntegerAs Long
        On Error Resume Next
        Dim As Integer: i = 1
        FindReminderWindow = FindWindow(vbNullString, "1 Reminder")
        Do While i < iUB And FindReminderWindow = 0
            FindReminderWindow = FindWindow(vbNullString, i & " Reminder(s)")
            i = i + 1
    End Function
  8. Sign the Macro so it will run: Tools > Digital Signature… and choose the certificate you created earlier.
  9. Close the VBA window.
  10. Close all Outlook windows.  (If prompted to save the VBA project, choose to save it.)
  11. Relaunch Outlook.
  12. You should get a modal security dialog for the new VBA script you wrote.  Click “Trust all documents from this publisher”.  This is a one-time process (you should never need to do this step again).
Posted in Uncategorized | 21 Comments

NTFS pisses me off.

NTFS sucks.  The way it prevents files-in-use from being overwritten sucks.  It causes so many buggy system states due to Windows Updates being installed but the required reboot still pending.  Once in that state, Windows goes berzerk — random things crash, system slows down, network performance gets intermittent — until you finally reboot.  It’s even worse in Windows 10 with the new “silent” defaults for Automatic Updates, because now it’ll just silently download and install but then schedule a reboot for later, thus leaving your system in an unstable bizarre state and not even telling you that’s the case.  So you sit down to use Windows 10, and everything’s acting buggy and weird, and you tear your hair out for an hour trying to figure out if you’ve got a failing RAM stick or need to roll back to a previous System Restore state (which, btw, is not enabled by default in Windows 10, thanks Microsoft!), only to finally discover there’s a pending reboot needed due to Windows Updates.  You reboot, and all the problems are magically gone.  All due to NTFS sucking hairy goat spheroids.

Posted in Uncategorized | Leave a comment