ADD and the Art of Putting It Away BEFORE it’s Finished

This is a discipline that I’ve only recently started to adopt. I really wish I’d come up with it earlier.

I have been in the habit of leaving a project out until I finish it, in no small part because if it’s put away I fear it will just disappear and never get done. The problem here is that being ADD, another project comes along and the first project gets deferred indefinitely. Then another project defers the second, then… then there’s a great pile of unfinished projects and the one you suddenly actually need to finish is somewhere in the middle of all that and your workspace is a disaster area. More than likely all your workspaces have merged into a huge, oppressive, unmanageable, crushing mess.

Now I try to put unfinished projects away as soon as I stop working on them, even if my best intention is to pick up where I left off the next day. In no small part, this has been enabled by my clear bin storage system, which prevents a project in storage from seemingly ceasing to exist because it’s no longer visible. Sometimes I’ll put the project into a clear container but leave the container on my workbench, so if I do start on it the next day, it’s right there. When the Next Thing else comes up, I can take that project container, drop a label on it with painter’s tape, and put it on a shelf. It’s organized; everything I need for the project is there in one place.

Part of my brain still rebels. The ADD me (who still thinks he can get everything done at superhuman speed) says “No way, we will get this done tomorrow! Really! Just leave it! Why are you wasting 10 precious minutes on this?” But the older, wiser me knows that the time/effort of putting it away and bringing it back out is far less than the stress of dealing with the mess when it doesn’t get finished the next day.

CBGOS, My Clear Bin Granular Organizing System

CBGOS, My Clear Bin Granular Organizing System

One of the problems with being ADD is the “If you can’t see it, it ceases to exist” phenomenon. For me, this is one reason why my desk is stacked high with piles of stuff and projects are scattered across every flat surface in my space. The mess can be oppressive, but it winds up being preferable to a void feeling I get, a sense of emptiness when everything is neatly organized and put away and out of sight. If that statement sounds completely weird to you, then you probably don’t experience ADD the way I do and the rest of this article will make no sense either.

But there comes a breaking point, where the sheer weight of the mess makes a space unworkable. The usual fix to this is to get a big box, shove all the crap projects into it and then weeks or months later wonder where “that thing I had on my desk” went, followed by the dreaded rummaging through the box(es) of stuff that used to on the desk.

I’m focusing on my desk here, but this problem isn’t just confined to desks, it’s all-encompassing. Papers, clothes, tools, cleaning supplies, stuff. I can usually spot an ADD family two seconds after entering their personal space.

There’s an organizational sweet spot, somewhere between “this place is unworkable” and “a clear desk is the sign of an empty mind”, and I’ve developed a system for getting (and staying) closer to it. My Clear Bin Granular Organizing System is based around a set of clear bins in multiple sizes, starting with “huge” (with a volume of 40 litres) all the way down to tiny, at a volume of 100 ml. Most of these I get from IKEA (at least down to the 5 l size, from there it’s more haphazard).

A problem I had was a tendency to be either disorganized or (attempt to) be hyper-organized. Naturally the hyper-organized attempts failed because something more interesting always comes up before the process is complete. One day, facing a “dump it into a box and start over” crisis, it dawned on me that just a little sorting during the purge could help immensely, so I got two large clear boxes and a couple of smaller ones. Things related to an identifiable project went into their own box. Into one large box I put “papers” (including unread books, newspapers, etc.); into the other “Electricity and electronics”. Now I had a clear desk, half a dozen boxes, was marginally more organized, and if I wanted to be done with it and move to the next thing, it was obviously already better than the one big mystery box.

Then I took that electricity and electronics box and went around the house, collecting all the stray stuff in that category. It wasn’t long before the box was overflowing, and that’s my Eureka moment. The box contained power cords, power bars, chargers, cables, calculators, a tablet, bits of computer hardware, lights… I broke it down into a large box for power bars and electrical cords, a smaller box for cables, and a smaller box for the tablet, calculators, and tools. Anything not in those categories stayed in the big box. Then I went back to the cable box and broke it down into smaller boxes: one for Ethernet, one for USB, one for everything else.

And then that’s when it became a system! I returned to the big box of papers and sorted them into stuff that needed to be filed, stuff to trash (still a bin, but not clear), things to read, and things that should be acted upon.

There it was, all the stuff on my desk (and more), no longer on my desk, but also both visible and much more organized than ever before. No Big Box of Doom, either!

Here’s the system in a nutshell:

  • Assessment: look for natural divisions in the stuff that needs to be organized. The key here is that the divisions can be huge, like paper or not paper; or small like a pile of business cards to sort through.
  • Get the smallest possible box that will contain each of the divisions of stuff. Use Painter’s tape to label each box with the intended contents. The advantage of painter’s tape is as you reassign boxes, you just peel it off and write out a new label. [This can also avoid the rabbit hole of spending a day deciding on how to create the Best Labels Ever.]
  • Put the stuff into the assigned boxes. Resist the urge to sort each category, just get it done!

You can stop right now, knowing that you’re already better off than tossing everything into a box and sticking it into a corner. That’s the key point of this system: it can be “perfect” but it doesn’t have to be. It’s a tool for incremental improvement. Best of all, you never have to start over. Now can carry the system into other parts of your space. As you go, follow these steps.

  • If a box overflows, assess the box for sub-categories. If they exist, break the stuff into multiple boxes, updating the labels if required. One of mine was “Hooks, pads, adhesives” that first got the adhesive part broken out, then adhesives wound up splitting into one for tape and one for glues.
  • If you discover that you have two boxes with the same label, merge them or sort them into sub-categories.
  • If a box winds up mostly empty, downsize it.

Best of all, because the boxes are clear, none of it ceases to exist. It’s all there, visible but with at least a minimal level of organization.

This system isn’t going to solve every problem. I’m not trying to pretend to be Marie Kondo here. I still have an ongoing battle with OFSD, but at the same time I can find a LOT of stuff that I couldn’t find before, and I haven’t thrown everything into a Box of Doom for almost a decade, either.

An Argument for Complex User Interfaces

Boeing 747 Cockpit

A Boeing 747 cockpit, a functional complex interface

Note: This was originally published on a Joomla blog in 2013. The details are outdated, but the principles remain the same.

User Experience (UX) design is an important aspect of almost every software application. Most users benefit from having a simple, easy to understand interface that offers intuitive choices to achieve their goals. Advocates of the simple approach point to surveys that measure how users respond to the design of an application, where simpler interfaces almost always garner a better rating.

The challenge is that not all applications can be reduced to a simple model. The current trend in UX design is to break a complex task down into a set of smaller, simpler interfaces, and then give the user a method of selecting or stepping through each of these interfaces. In some cases where a lot of this input is required, the user is guided through a sequence of simple steps to achieve a complex goal. This doesn’t work. It’s the opposite of the one-step checkout process that works so well for commerce sites, and we need a better solution.

This simplification and the drive for a “clean” user interface has become even more pervasive with the rise of mobile devices. User interfaces are dropping mouse-related functionality and adapting to smaller screen sizes.

While all of this is generally good and something I support, I think we’re losing something important. When we build a single interface designed for the broadest range of users, we leave other users out. The distribution of user requirements isn’t even. Every user base breaks down into clusters based on skills, needs, abilities, and equipment. Every time you tune your UX for one cluster, you run the risk of making it less useful for another cluster.

As a case in point, let’s take the administrator interface for Joomla 3.0. This interface is based on Twitter Bootstrap, which makes it responsive and touch friendly, which is a good thing. But let’s look at it from the perspective of a content creator/manager. After all it’s a CMS:

Menu navigation: In Joomla 2.5, when you hover a mouse cursor over a top level menu item, the submenu automatically appears. In Joomla 3.0, “mouse hover” is not a touch interface concept, so nothing happens. Desktop users just have to click, click, click. While the majority of new devices sold are mobile and touch, I think it’s safe to assume that most web sites will be administered from desktops for some time to come. This is not an improvement.

Article Manager: It’s clean, it’s pretty, it’s missing information. Want to find out how many hits an article has? Edit the article, then go find the right tab. Want to sort by hits to see what content is most popular? Go fish. Sure the control panel has a nice display of most popular articles, complete with a colour scheme that’s supposed to mean something intuitive, but if you want to filter by category you’ll have to find an extension for that.

Article Creation/Editing: Let’s look at the evolution from Joomla 1.5. Joomla 2.5 linearizes the title / category / publishing status fields. While this is useful for tab order (what, users with keyboards?) it creates a pile of white space that crushes the area available for the article. Various other details are retained in the accordion style tabs on the right. While I’m on the accordion tabs, the fact that you can’t open more than one tab at a time still irks me – why can’t I see the author name and the metadata at the same time? Meanwhile in Joomla 3.0 we have the title and category selection above the editor, a much wider edit screen, publishing details in a narrower right column, and image details below the editor. Everything else is now in tabs. Click a tab, the editor is replaced with the fields on the tab. While this is probably great if you’ve got a hobby blog, it’s got a lot of other issues. For me the most significant is that you can no longer see the article when entering the meta description. If you want to get it right, you wind up tabbing back and forth, cobbling it together a few words at a time. Visual simplicity is not user simplicity.

I hope these examples illustrate the point. What works best for the biggest cluster of users probably doesn’t work best for other clusters. It’s common to hear that one of the reasons WordPress is more popular than Joomla is because it has a simpler user interface. So we simplify the Joomla interface to address this, and not only do we have a pile of tabs that will still have users calling it too complex, we make it more difficult for content creators who know what they’re doing. It’s a lose-lose scenario. It’s also not particularly informed by looking at WordPress closely. With a SEO plugin installed, the WP post creation page has all the relevant information displayed at once. No accordion, no tabs. Lots of information in your face at the same time. Where WP has the advantage is that if you don’t care about SEO, it’s just not there. The interface gets more complicated as user requirements get more complex. It’s this scaled functional complexity that’s the key to the positive impression, not some UX magic.

Joomla should be offering configurable interfaces targeted at each user group, so that those of us who run with a huge desktop screen can see everything we need at once – just like the cockpit of a jet aircraft – and at the same time someone with less complicated requirements can have the iPod interface.

Image credit: SWF Photography used under a CC-BY-SA License.

Use an Ad Blocker to Improve your WordPress Dashboard UX

Easily one of the most irritating things about WordPress is the continuous attempts to up-sell in the dashboard. Here’s how to get rid of them.

It’s one thing to have a gentle hint, like Updraft Plus saying “hey you can get more features with the pro version” and a dismiss function that makes the reminder go away for a year. It’s more irritating to have something that pops on every login, and even more irritating to see something show up every time you are on the dashboard.

I can tolerate most of these. Sometimes they’re irritating enough that I just switch plugins, especially when they try pushing related plugins you don’t give a damn about. This is one reason why there’s no Yoast on my sites. The SEO Framework is just as capable, a lot less pedantic, and it doesn’t nag. Yet.

But what to do when there’s no alternative and the plugin is persistently nagging? Use your ad blocker to make it go away! Since it has just recently pissed me off, I’m going to use WPCode Lite, an otherwise useful plugin as the prime example. With a recent update, this plugin has elected to add a widget to the post edit page with the title “WPCode Page Scripts”. Cool! That’s a welcome minor convenience. Click on the widget though and what do you get?

Page Scripts is a Pro Feature

That’s nice, but for me it’s not worth subscribing. How do I dismiss this? Surprise, surprise, I can’t. Well, F*ck you, WPCode! I’ll do it myself. Now this takes a little knowledge of HTML and custom AdBlock Plus rules, but the general process goes like this:

  • Right click on the widget and choose inspect. This will highlight the general area in the code you want.
  • Look for the highest level element that uniquely identifies your target widget. In my case, inspect took me to a div with the id “advanced-sortables”. We don’t want that. There are a bunch of useful elements on the page that are enclosed by that. Drill down a bit and we find another div with the id “wpcode-metabox-snippets”. That’s the one!
  • Click on your AdBlock icon.
  • Click on the gear to get to settings.
  • Select the advanced tab from the left.
  • Scroll down to “Your Custom Filters”.
  • In the box below “My Filter List”, enter this rule, substituting your domain for mine:

You can also leave off the domain if you have multiple sites, but in my experience more specific rules help prevent long periods of “WTF” until your realize that the ad blocker is doing something you didn’t expect.

I’m picking on WPCode here because the arrogance of this has really ticked me off, but you can apply the same method to most other notices like this. At some point, plugin developers will take defensive measures to make this even more difficult and then we’ll have a discussion about writing user scripts in TamperMonkey and it’s kin.

Docker, Explained for “Old School” Developers

Docker, Explained for “Old School” Developers

Anyone writing code has probably seen a bunch of references to Docker by now. It’s like this new toy that’s all the rage, but for people like me — where picking up new things takes a crap-load more work than it used to — the general reaction is “I’ll learn that when it’s unavoidable.” Alas, a few weeks back it became unavoidable, and I’m here to report back.

If you’re even mildly inquisitive, a quick scan of Docker says a lot about containers and it’s pretty obvious that a container is some kind of virtual environment, but there’s not much that tells you why you should give a damn. I’m going to try to fix that. I’m not going to describe how to use Docker here, just what it’s for. There’s lots of great resources on making use of it elsewhere.

If you got into development in a time when your workplace had a nice air-conditioned room with raised floors and racks of servers and keyboard/console switches, then this post is for you.

The TL:DR on this is the learning curve here is a lot less than it seems at first, and the flexibility it gives you to set up and change configurations is truly powerful. Invest a few days in learning the basics and you can build, rebuild, and reconfigure virtual server rooms that significantly reduce the amount of time needed to maintain your own local environment. As a common example, if you’ve ever sworn at LAMP/ XAMP / MAMP configurations only to start from scratch or if you’ve tried to get two versions of just about anything running on the same system, then Docker definitely is for you.


Recollections of Depression

I’ve got this old, slightly torn and patched 100 dollar bill up on a desk shelf where I can see it. A few months back we found it between some papers and I didn’t have the slightest recollection of how I got it.

But now it’s coming back to me. I think a friend and business partner gave it to me to acknowledge the work I was putting into our project. I hope that externally I was suitably grateful, appreciative, and said “that’s not necessary”, all of which would have been true.

The project, and the acknowledgement, came at a time when my extended period of “mild to moderate” depression was well into “moderate”, but likely before I truly realized what was going on. I might have put all I had into that project, but what I had wasn’t much. My effort yielded a bunch of prototypes and some ambitious code that never saw completion. I might have been doing my best at the time, but I was all too aware that my best was a fraction of what I had been capable of in the past.

My internal dialogue compounded my funk. Was I now just too old to write good code? Was the passion I’d had since I was a kid just done with me? If so what next? I certainly didn’t think my efforts were worth much, certainly not $100. After launch and the first sales, now that’s worth a pat on the back and a nice dinner! Thrashing at a solution with nothing of production quality… not so much. No matter how sincere the effort, effort without results is difficult to distinguish from no effort at all.

No, this was an undeserved reward. Another testament to my failure to perform, something else to highlight the pervasive feeling that I had: I was afloat on a large body of still water in a deep fog, with a pair of good oars but no idea of where I was, where I was going, how far it might be, or in which direction I might proceed to find anything. There I sat, adrift. I might row from time to time, but it was never clear if the effort was pointless or not, if my limited transit was changing anything or just Brownian exploration. I am sure I stuffed that $100 someplace where I knew the chances I’d run across it again were slim, where it couldn’t remind me how adrift I was.

That was almost 20 years ago now. I had no way of knowing that I’d be in that ugly fog for more than 15 years, although with thankfully few bouts of moderate during its course.

Now I sit here, three or so years clear of the battle. [There is no way for me to say “there, that’s when I beat depression!” I just gain increasing confidence that it’s not coming back anytime soon.] I look at this old bill, not even knowing if it’s still a negotiable instrument, wondering if I should try to deposit it, frame it as a reminder that sooner or later if I simply persist it is possible to be free, or just slip it between a few papers and see if I rediscover it on a much later purge.

Whatever I do, there is no way to describe how I feel knowing that I am looking at this ugly beast in the proverbial rear view mirror.

Laravel 7/8, Behat, Mink, BDD, Netbeans 12, and subdomain testing!


  • Verified no changes with Laravel 8.
  • Added some details on running with Chromium.

There’s a mouthful. There’s two parts to this post. The first part is the story of how I arrived at using Behat, a tool that facilitates Behavioural Driven Design (BDD). The last part is the TL;DR configuration I used to get it working. If you just want to get this configuration going and don’t care about the background, skip down to it. I won’t be hurt.

First an admission: I’m really, really late to the BDD camp, and it kind of pisses me off. If I’d been using this approach for the past 15 years, there’s no question I would have gotten more done in less time.


My Test-Driven Design (TDD) Experiment

Test Driven Design

Photo by Helloquence on Unsplash

Is a Test-Driven Design approach effective, even when working on a medium scale personal project? Yes, and here’s why.

I’ve long been an advocate of Unit Testing in software development, having found that even though the work is often tedious, the investment in good tests significantly reduces overall development time. In my experience, the time invested in unit testing pays back by a factor of ten or more.

For my latest as-yet-unreleased project, I decided to try a Test-Driven Design approach. In short, the TDD method requires that you write tests for your code before writing the code. This has some significant benefits from a design/architecture perspective:

  • It forces the developer to think more about the external interface for a package and less about the implementation details.
  • It requires a more precise definition of what the inputs and outputs of a functional block are. This can expose flaws in the overall architecture. In the case of my project, I was working on the principle that the module would take one input file and generate an output. While creating the third test case, I realized that I was duplicating content from one input file to the next, that a far better approach would be to break that information into a second, common file that could be used multiple times.
  • It assures near 100% code coverage for tests. In theory it guarantees 100% code coverage. In practice that’s more difficult. More on that later.
  • Writing a test for everything forces you to to become a user of your own code. This serves to highlight problems early, before they become deeply embedded in code. When designing something, it’s easy to oversimplify. The only easy part of the “that part will be easy” trap is falling into it. In this project my “easy” trap required no less than three refactorings and a partial re-write before it was actually easy for the user. If I was coding first and testing later, backing out of the initial design would have been much more difficult and required throwing out a significant amount of code. Code is time.
  • It reduces useless code. I have a distaste for missing functionality. This means that when I write a method to do something, I’m inclined to generate similar methods that do parallel things at the same time. TDD puts an end to that.
  • It highlights common functionality that may not have been evident in the requirements phase. This makes it easier to spin out that functionality into independent classes early in the implementation.

Software Engineering Purity and Test Structure

Although I’m a strong advocate of automated testing, it turns out I’m far from a purist. Even though there are some clear benefits, I’m not likely to build a suite of mock classes just to isolate a subject class. 100% coverage is always a good thing, but I’ll take 80% coverage, knowing that some abstract class I don’t have an explicit test for got a pretty thorough run through by other tests, metrics be damned.

If tests require some expensive operation to complete, such as accessing a database, then creating a data provider is worth the effort, but doing so purely for the sake of correctness? Not so much.

It’s a little too easy to write code for something obvious, like checking for a null value, without writing a corresponding test. Sticking to Test-Driven Design requires a level of discipline that’s difficult to maintain, particularly when you’re the only developer on a project. Because of this my test suites tend to be a mix of unit tests, integrated tests, and some kind of ugly hybrid between the two, and I’ve decided that I don’t really care. Generating sample output in a bastardized test that ends with assertTrue(true) is still useful. Even though that test always passes, every once in a while the “real world example” test exercises an unexpected pathway and throws an error that would otherwise sneak by. I’ll take that find over purism ten times out of ten.

TDD and Over-engineering

I’m also more relaxed about software engineering principles when it comes to testing. I’m more likely to copy and paste test code than I am to carefully craft a hierarchy of test classes. I may be more relaxed but I’m not lax… as it turns out this project has a bunch of test cases that are common across multiple classes. I initially just copied the first class, with all the cases, which are fairly elaborate. Then I needed to copy them again for a third class. Three is the magic number when you realize you just screwed up. It took a fair bit of effort to go back and decouple the test case generation from the expected results, but there is an immediate payback: tests that exercise more sophisticated features in the latter classes are now automatically passed to their predecessors. If a simpler class can’t handle the new case in a reasonable way, it’s evident immediately.

While I have clearly strayed form a pure Test-Driven Design methodology, starting out with TDD gave my project an obvious lift.

Reducing gold plating and improving the design

On more than one occasion I found that I was inclined to embellish code with things like getters and setters that looked useful but actually had no use case. All the “I should add this” moments were converted to “I need to write a test for this first” and it’s not long before you realize that you don’t need a test because nothing will ever need to use the method in this way. Better yet, it makes you think about how that task would ever be used. The end result of this was twofold.

First, entirely removing functionality that seemed like a good idea early in the design process but in reality was just useless baggage. Second, if the functionality was useful, it was usually in the wrong place. This led to a series of code refactors that extracted that functionality into a conceptually clean solution, either a trait or a stand-alone class, in either case useful in many places. Less code or better code. Both excellent benefits of starting with TDD.

TDD Offers Measurable Progress

When working on a project of significant complexity, particularly when working alone, it’s easy to lose track of where you are. That’s not a problem if you have a client deadline looming in the not too distant future, but when it’s a personal project, and particularly if you’re blessed with a healthy dose of ADD, it’s easy to lose momentum.

For me, loss of momentum is the death of a project. I’ve got a long list of unfinished projects that I thought would take a few weeks when I started, but in fact they needed many months. Nearly all of them died from a momentum deficit.

Test-Driven design, with it’s focus on top level functionality, really helps with that. Even though my current project is perhaps 50% complete, it’s generating useful results. The implementation is partial, but it’s functional, and needless to say it’s tested, well structured, and robust. Instead of substantially complete code that winds up with significant problems when put to actual use, I have working but functionally incomplete code that I expect will be a joy to keep working on. All of these things are giving me enthusiasm for implementing the next level of features.


Even though I have strayed form the TDD methodology as the project progressed, starting with TDD was the best thing I’ve ever done when working on something of significant size.

If I was working in a team, not only would I start with TDD, I’d be far more strict about sticking to it throughout the development cycle. It highlights architectural issues very early in the development process, when it’s far easier to adjust and fix the problem. A dozen minor restructurings when the code base is small is a thousand times easier than rewriting thousands of lines of code after the mistakes have been baked into the project.

It’s hardly an objective measure, but I think this code represents some of the best work I’ve done. My three week project has extended to five months so far, but I’m still excited about it. Best of all it’s still fun. It also has the unexpected benefit of spinning off Configurable, which has proven itself to be very useful in other projects (not to mention that it’s just cool, IMO).

Morning Coffee

What I particularly like is the days when I’m standing in front of all the bits required to make coffee and there’s this internal dialogue:

L: Okay, make coffee now.
R: Wut?
R: How?
L: Oh FFS all the bits are there, just DO IT!!
R: Something about this round thing, right?
L: Aughh!! WAKE THE F*CK UP!
R: I need coffee.
L: Yes, YES! You need to MAKE it, you do this every f*cking day!
R: Ugh, ok, right. Push grind button.
L: There we go! F*ck me.
R: Water.
L: Yes, yes, you’ve got this!