When I was traveling a while back, I grabbed a small white metal tube out of my toiletry bag. Opened it up and then squeezed a small amount of this white cream on my toothbrush. A few seconds later my power toothbrush was whirring along and I had a thought. \u201cThis isn\u2019t as foamy as I expected. Did I not put enough toothpaste on my brush?\u201d The lack of a minty taste should have said something, but let me say one thing here:<\/p>\n\n\n\n
This story is 100% true.<\/em><\/strong><\/p>\n\n\n\n So, still completely sure it was the toothpaste\u2019s fault, I put more on the brush, as one does. Then I try again. Still not doing what I had hoped. At this point, because I am not completely stupid (and my mouth was starting to feel funny), I realized\u2026know what? This may not be toothpaste, and it wasn\u2019t. Maybe don\u2019t try this again.\u00a0<\/p>\n\n\n\n But why did I do this? Pure muscle memory. That tube of face cream looked so similar to my toothpaste that I just grabbed it without thinking and kept going about my business.\u00a0<\/p>\n\n\n\n Glossing over my borderline dangerous real world organization skills (I wish this was first time I have made a stupid mistake with my travel bags), this problem of muscle memory pertains to the process of creating things like software and devices as well. In this case I don\u2019t want to focus on the actual code you write, but rather the interface that that code creates. There are two high level times when this comes into play. Changing interfaces, and creating new ones.\u00a0<\/p>\n\n\n\n As a (hopefully) more relatable example, have you ever tried to use a keyboard that you aren\u2019t used to? When I work in our Cambridge office, they have UK keyboards. UK keyboards have mostly the same key patterns<\/a>, but are slightly different for a few key placements. The same happens when I am working from my iPad keyboard. The letters are in the same location, and I can adjust to the key size okay, but when I need a key that isn\u2019t in the exact same place, I tend to hit it instinctively, and then have to try again.<\/p>\n\n\n\n Changes to a user interface, sometimes to update an interface for modernization reasons, is a noble goal. Who wants their software to look like it was created in 1993 using Visual Basic 1.0? However, if you have a loyal user base (often people who work with you,) those changes need to be done carefully.\u00a0<\/p>\n\n\n\n Changes in a software interface are a very common source of errors. In this\u00a0article<\/a>\u00a0,\u00a0Page Laubhrimer<\/a>\u00a0discusses a memory model that the user of an application makes. For example, who doesn\u2019t have an app where you know where to click and do it without thinking or reading the dialogs that come up.\u00a0<\/p>\n\n\n\n As such, we are all an aware of some interface you once used regularly that underwent a complete change that initially made you angry. For example, if you are an iOS user who takes any number of pictures, you may recall when iOS 18 came out and they had overhauled the entire photo interface.\u00a0<\/p>\n\n\n\n Nothing was where it was expected, and of course everyone hated it. Certainly some very vocal users did. I wasn\u2019t immediately a fan either. Yet, now after some time and practice, I have warmed to the changes as I got used to them. In fact, I have warmed to a lot of these changes at this point. So, I am not here to tell you to never change your patterns, just to remind you that you need to manage that change and ease people into it.<\/p>\n\n\n\n However, large changes aren\u2019t the biggest problem for muscle memory. Large changes are frustrating, but far easier to change into. It is the subtle ones, typically where you may not immediately notice a difference. For example, say you buy a new car, and due to some research, it was decided that swapping the accelerator and the brake pedals would make travel safer. You can imagine what would initially occur. People would forget which pedal was which and best case, crunching metal and plastic would occur. It would require a lot of muscle memory training to make such a leap. Eventually that desired increase in safety might happen, but the cost initially might be huge.<\/p>\n\n\n\n Subtle changes occur all the time in software. Like if you have a few buttons on the screen. If you go from [cancel] [ok] to [ok][cancel], or something like [save][delete][cancel], people will make mistakes just positionally as they click where the button they wanted used to be as they wail: \u201cIt was always like this, why did they change?!?\u201d This becomes especially true when you have users who use hotkeys and they barely use the user interface.<\/p>\n\n\n\n It doesn\u2019t even need to be the same software that is involved either. Using SSMS for SQL Server, ADS (Azure Data Studio, depreciated), and DBeaver to execute queries, there are a set of keys that you can use to execute queries. F5, Ctrl-E, and Crtl-Enter, and it never fails that I try the wrong one. And SSMS has Ctrl-R to remove the results pane that I try in almost every tool that I miss when using many many software packages!<\/p>\n\n\n\n While this concern about user interfaces is perhaps obvious, the same goes true for designing a database, or a PowerShell cmdlet, a function, a CLI (command line interface) or any bit of reusable software. The users of your software are apt to make mistakes if you aren\u2019t careful and warn them as much as possible. <\/p>\n\n\n\n A common example in database design is naming a surrogate key for a database. If you have a table of customers, users of that structure ought to be able to predict the name of the surrogate primary key. There should be a customerId, customer_id, custId (if your platform doesn\u2019t allow long enough names and you are forced to abbreviate), or something similar. If you can predict the name of the customer table surrogate just by knowing a little bit about the database, they you can also predict all the other ones too. <\/p>\n\n\n\n Customer is to customerId as Product is to ________. <\/strong><\/p>\n\n\n\n And if that answer isn\u2019t productId, then you have an issue.\u00a0<\/p>\n\n\n\n In all things you design, following a common pattern is essential to the sanity of your users. Creativity is a great thing, but some things have to follow a standard. And if you are changing an application, even for the better, you need to make the path smooth for the user so they don\u2019t do something stupid because of muscle memory. <\/p>\n\n\n\nOf course this is not about dental hygiene<\/h2>\n\n\n\n
Changes in and of them selves aren\u2019t bad<\/h2>\n\n\n\n
Patterns matter as well<\/h2>\n\n\n\n
What about internals like database design?<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n