Software is a static list of instructions, which we are constantly changing.
While each line of code is pretty simple, and a few of them are not much worse, assembling big collections of code that behaves as expected is crazy difficult. I used to think it was just scale that was the problem. Remembering a list of five things isn’t too bad; remembering a list of fifty things is beyond most people’s ability. That can be solved with organization. Write them down, make it…
Code is a set of instructions for a computer to follow. But code also has additional properties, beyond its runtime behaviour. There are lots of them. A simple one is readability. Some code is cryptic; it takes a lot of investigation to figure out what it will do. Some code is self-explanatory. It’s written in a clear style so that most programmers can quickly figure out what it will do. It has…
My very first experiences with different methodologies for software development date back to the early nineties. I’ve lived through some heavyweight ones over the decades, including those in healthcare. Realistically, we need methodologies, even if we don't like to be confined by them. Too many loose strings in a project will eventually tangle. Which is why I liked the emerging lightweight ideas…
Being able to predict what’s coming up in the future allows you to make better decisions right now. Better decisions will give you more chances to actually change the current direction rather than just getting caught up in the flow. The first part of enhancing predictions is to accept that there is only one objective reality. Although it surrounds all of us, we only ever see a tiny sliver of it.…
A long time ago, I remember someone trying to convince me that sufficient testing would prevent ‘all’ bugs. All you need are tests. That’s never been the case for me, even after all of these decades. At the very best, with a gifted team, we were super careful, had strict standards, and hyper-intense reviews, but we still had one bug escape. Worse, though, was that the effort took considerably…
If you collect some data with respect to a specific context, when there are significant changes in that context, the original data no longer fits seamlessly with any newly collected data. One way to handle this is to change all of the old data, updating it to the new changes. This works, but it could take quite a while in production and can be extremely risky. A change in massive data can take…
Decades ago, our project had a convention where we never directly used ANSI C primitive types, unless it was trivial in a loop. But for any and all other variables, everything had to be typedef’d explicitly. Everything. Some people would see that as excessive and way over the top, but it actually turned out to be a very good habit that helps with getting really high quality. If you went to call…
Back in the eighties, when I was a student, there were only two choices: you used ‘vi’ or you used ‘emacs’. I picked vi, my roommate picked emacs. The stuff he did with his editor was way cooler, but over the decades, vi has pretty much been everywhere I have stumbled. I assumed it would fall out of fashion, but it persisted. Vim and all of those embeddings in the IDEs keep it alive. I read…
The most common mistake I have seen in big ugly balls of mud is to try to capture data without enough structure. Chopping up some incoming data into a lot of little strongly typed fields is a pain. Sometimes it seems like an unwarranted pain. You may need to get a mailing address. Why not just give the user a big textbox to fill in? The problem isn’t that the users can’t carefully type in the text…
I use the term ‘software system’ loosely. I usually intend it to mean: all of the boundaries for a set of related solutions that have been or will be implemented with software. In that sense, it is less about the technical parts of the ‘system’ and more about how they all come together to help people. I do this mostly because I tend to visualize a ‘problem space’ as a flat 2D terrain. It is a…
A classic expression describes shoving a square peg into a round hole. Basically, you’re matching the wrong part with the wrong location. I see this often in software architecture. Sometimes I like to use the term impedance mismatch. There is a component that someone is suggesting for use in a different variation of its problem space. It fits badly. Sometimes the issue is access. There are hard…
If you start from the premise that a system is just a series of access points into a vast array of computations, then if you accept that there will always be a huge number of changes to this underlying code, you see why this is messy. All the computer is really doing is taking a bunch of inputs, grinding through computation, then spitting it out. But we often end up changing these computations,…
Recently, my blog has been getting a lot more views. Unfortunately, a lot of the incoming fields for these reads are just tagged with ‘Other’. That tells me that the traffic is not coming from the older established sites I know, like HackerNews, but is either fake traffic or newer sites that I haven’t seen. It would be nice to know which is correct. Are people actually reading these posts? So, if…
Programmers hate adding security to their systems. First, it is a huge amount of work, and second, since it is so often left to the end, it is very ugly and disruptive work. A patchwork of hacks. But it’s misdirected. Without enough security, the system they built is useless, well, worse than useless. If people use it, it could severely screw them over. Nobody would intentionally use something…
It really feels like the world has sunk to its lowest point in my lifetime. And it does not seem likely to improve anytime soon. We’re sliding downhill. When I first started playing with computers, way back in the 80s, I felt like they had huge potential to help humanity. To lift us up, but it seems like they did the opposite. First, they trapped us; now they are forcing us to regress. It’s not…
On the face of it, shortcuts and makework may seem like they are opposites. A shortcut is a faster way to do something that effectively pushes out the consequences down the road. You take the quick and easy way now, only to pay for it later. Makework, on the other hand, is anything that you are made to do that does not directly or indirectly contribute to the work at hand. For instance, you fill…
A common misconception in software development comes from not understanding users. For any piece of software, there is a bunch of primary users who are using it to solve their problems. This ranges from commercial product usages all the way to large enterprise usages. If the software is large and has been evolving for quite some time, these usages are often partitioned into different subgroups.…
I remember when I was in school; we got a difficult programming assignment that I struggled with. The algorithm, if I remember correctly, was to fill an oddly shaped virtual swimming pool at different levels, and then calculate the volume of water. The bottom of the pool was wavy curves. The most natural way to write the code to simulate adding little bits of water at a time to the pool was with…
For any given software development, there are a bunch of ‘bars’ that you have to jump over, which relate to quality. At the bottom, there is a minimum quality bar. If the code behaves worse than this, the project will be immediately cancelled. Someone who is watching the money will write the whole thing off as incompetence. To survive, you need to do better. A little higher is the acceptable…
A software system is a finite resource. For some people, this might be a surprising statement. They might feel that, as they can store a massive amount of data and talk to any other system in the world, this feels a lot more infinite. At any given time, there is a specific quantity of hardware, wires, and electricity. If more of these resources are available than are currently being consumed, they…
Since I started programming decades ago, there has been one seriously annoying trend that just does not seem to want to go away. If you work for an enterprise, banging away at their internal systems, the management above you really, really, really wants you to just sit there, do your job, and not cause any problems. They want you to be an obedient little cog. Just a part of the machine that they…
I was crafted by the Waterloo co-op program in the late eighties. Part of that experience was a crazy large number of interviews, so I got pretty good at them. Since then, I’ve worked for over a dozen companies. For one interview (for my all-time favourite job), I was really young, so I got asked rapid tech questions and had to bring printouts of my older code with me. That was fine, it was a…
Over the decades, I’ve seen the common practices around creating functions change quite a bit. When I first started coding, functions had come out of the procedural paradigm. I guess, long ago, in maybe assembler, a program was just one giant list of instructions. That would be a little crippling, so one of the early attempts to help was to break it up into smaller functions. An added benefit was…
Being a software developer is difficult and stressful. In the early days, there is an uncontrollable fear that you cannot build what you were asked to build. The industry is awash with too many unknown unknowns, and few programmers receive adequate training. Newbies are often just pushed into the deep end with a brick tied to their ankle and expected to figure out how to swim. Worse, the industry…
I’ve been deep into software since the mid-eighties, obsessively following the industry while I slough through its muddy trenches. The benefit of having survived so long is that you get the repeated pleasure of seeing the next annoying hype cycle explode. The pattern is always the same. Something almost newish comes along. It’s okay, but not that big of a deal. Still, it gets exposed to way more…