The Codist

Thirty years ago I was building apps that were anything but simple, yet they existed in a simple environment: we shipped them on floppy disks to run on a Mac. There were no service interactions and we were a single team than controlled all the code. It was possible to know what everything did.

Today I work for a massive non-technology company (though we create a lot of software and systems for our own use) and our problems are increasing to the point that unexpected failures are a common occurrence, both on the service side and even in our mainstream mobile applications. The sum of everything is becoming almost chaotic in nature.

Our software is not the product itself, but is very important to the success of the real business. Yet as more and more things are built, upgraded, changed or moved around, the failures are becoming more numerous, delays in shipping longer, and our ability to respond to problems quickly less assured.

Read the rest of the article…

This is the story of a fun afternoon spent tracking down an unknown problem that led to 4 different crashes, all without any idea of what it could be.

My team supports code in two of our apps plus is working on a huge new project that is something the company has never done before, so the five of us are quite busy.

One code base was written before even I got here 3 years ago by an outsourced team and is in Objective-C, and the other was written by me and another programmer all in Swift. The latter was released in mid 2017.

Read the rest of the article…

Back in the floppy-in-a-box days we tried to ship no more than twice a year or so, as it cost money to ship a new version and often we had to charge the customers at least something for it.

For Trapeze and Deltagraph back then we never had to ship any “patch disks” or emergency fixes so the only releases were generally major ones. Our releases had to be of quality to stand on their own for at least 6 months. Most of the time we did not even know who any new buyers were unless they told us.

For the purposes of this post I want to talk mostly about apps, particularly mobile apps since that I what I do today. While shipping these days is easy (even Apple is fairly quick these days) and free, the question of how often is still a valid one.

Read the rest of the article…

There is a joke that asks, how many programmers does it take to screw in a light bulb? First you need a business analyst, a product manager, a scrum master/project manager, an architect, a DBA, a designer, a QA manager, a release manager, a tester… hmm, did I forget anyone?

Yes, it's a terrible joke that I just made up.

Today there are a whole host of people involved in creating software in most organizations. Modern software development generally has a huge number of specialized roles, and often includes a large number of programmers as well.

Read the rest of the article…

Thirty-six years ago this week I started working as a programmer. My first job was working at a defense contractor. I had no experience or education in programming other than some high school classes (we had a teletype machine connected to some mainframe somewhere) and my own self taught ability in BASIC on an Apple II+.

Imagine for a moment I had today a time machine and could go back to that first day to tell myself what my life as programmer would be in 2017 (ignoring the obvious time travel paradoxes). I can guarantee I would have been amazed, or possibly unbelieving that a world like we have today could ever exist. The differences between then and now would be almost unexplainable to that young version of myself.

Take another step and imagine that version of myself took a time machine back another 36 years to visit my dad. Turns out that would be a month after the end of World War II. My dad barely survived the war (and thus in a way I did too). He would not have understood the concept of a computer, had likely never seen a television and maybe would have been amazed that the world was no longer at war. But 1981 would not have seemed all that different to what he knew otherwise. What changed between these two 36 year periods? The pace of change changed.

Read the rest of the article…

I find reading app release notes a fun pastime. For whatever reason people who write these release notes in the App Store have no imagination, or a perverse sense of humor, or they have resorted to smoking funny cigarettes.

So many release notes include the phrases, in some version: "Bug fixes," "More bug fixes" or my all time favorite "Minor bug fixes and performance enhancements". Apparently their codebase is so bad that the bugs are multiplying faster than they can be fixed!

Take for example this major airline app I picked at random. Two stars. The current version and its predecessors:

Read the rest of the article…