I will be converting most of the posts to Ghost, rather than continue to use my old static site generator which has more limited functionality, and the Swift is really old now.

Importing into Ghost is a massive pain but necessary going forward. All converted articles will show their original date and be 301'd. The only thing I lose is having the most popular posts on the front page unless I can figure out how to make Ghost do something like that. A few articles will be dropped as they are too old or obsolete.

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.

I always look at our crash reporting tool for both apps, as well as read App Store reviews daily, something I’ve been doing since I started doing iOS development long ago.

Our apps are built by a dozen or so teams out of more dozens of repositories and have way too many features. The quality is usually rather average for both apps. However about 3 months ago the crash rate, which was hovering around 0.5 - 1.0% suddenly dropped to 0.02% and everyone cheered, all the insane process and deadlines and other rigamarole we were and are subjected to finally paid off!

Except I did not believe it could possible be true, there was no way this overly complicated bloated app could possibly be that good. The best whole iOS app I ever released (back in iOS 7 days when the travel company I worked for was featured briefly in the keynote) had a lifetime crash rate of 0.07%.

Furthermore the App Store reviews were brutal over the same timeframe, often out of 30 daily reviews 29 of them would be one or two star and complain of constant crashes. These two facts could not be both true and I believe our customers know what a crash looks like, especially repeating ones.

A few weeks ago a new release prompted a lot of people at work to complain that even when they used one of the apps it crashed a lot, and finally people started to look into both why it was crashing, and why our crash reporting vendor was not showing the same. Someone sent them a support request asking why.

Oops. Turns out they had implemented a de-dupe method on their crash reporting to remove duplicate reports several months ago, and apparently it was eliminating 99% of our crashes! When they fixed it two weeks ago suddenly our crash rates were 0.7-1.2% again.

This story is not about an app monitoring vendor who apparently failed to monitor their own app; that’s just the setup as finally we could see what was crashing.

The Swift codebase is the higher quality of the two, often whole releases go by without a single defect reported, and it rarely has crashed previously other than the usual random noise ones. But during that period where we had no visibility four crashes appeared in our code area. They were around 10-12% together of all the crashes which one could live with at a rate of 0.7%, but my expectations are higher.

So I decided we should take a look and try to figure out what was going on. The strange thing was that all four crashes were in different places, yet they were always grouped together, with each having similar numbers. Every day—well at least since we started seeing crashes again—the same crashes at the same rate and in the same relative order.

That’s a really strange coincidence, which of course it isn’t. I’ve been shipping stuff for more than 3 decades, so I’ve seen a lot of weird errors. This one smelled of a common problem causing different results because the crash happened far removed from the problem, like driving down the road and seeing a car upside down without any idea how it got there.

Despite several releases since the crash reports went into hibernation, and with not a single report of any crash during testing (either by our testers or the full app testers) in stage, it had to be something unique to production.

A service call failure wouldn’t make much sense as even with our sometimes recalcitrant services (the app has an enormous variety) the odds of a minor constant failure every single day at the same rate seemed remote. It had to be some user action that only occurred in production, but our code has thorough automated testing and excellent testers; it didn’t seem likely someone would overlook pushing a button.

So how to trigger this bug in stage where no one had ever seen it? Note we could not test in production with a debugger as this app does not allow a controlled test.

Now our code in this app is a flow, with a common starting point and various paths until you get to an ending point where you confirm a choice. Usually one suspects things like clobbering memory, but in Swift this is very unlikely, although we do interact with other frameworks that are Objective-C so it could be that was leaving the land mine. But the every day nature of the 4 crashes didn’t make a random error like this make sense.

Now the server side code we call is currently different in stage and production, and there are various switches that influence the flow, so maybe something had been fixed in stage (nothing had been released recently).

So we were trying various crazy things to make something happen (I call this Poke and Hope, back from when I learned how to play pool in said fashion) when one programmer mentioned he got the app to crash while trying something unrelated. He described the steps, and then made a video to document it. After going through the flow a second time, on the last step the app displayed an alert reporting a service error (not an alert view, but inline) which we had never seen in stage before. Furthermore closing the alert returned the app to the beginning of the flow, but forwards.

After a bit I remembered that the product folks at the time had insisted that the transition go forwards even though you are really going back to the beginning. But it was not a big deal since this error was expected to be extremely rare. It had been tested by checking to see if the flow went forwards back to the start which it did.

The key was that this error should never happen in stage as it is a production only thing (aka, the real world). So why were we seeing it? And was this is the same behavior as the production crashes?

Repeating the steps a few times and watching the flow go forwards started to look like this was the culprit. The user would get this error (which apparently has been increasing over the past few months when we were blind) go forwards to the start of the flow, and try again. The problem is that the flow is now on the navigation stack twice, various notifications that happen are now being fed to two different sets of view controllers. When the code was shipped originally this apparently did not cause any issues but of course it was rarely if ever triggered, but it has changed over time. In normal behavior the flow always starts over with a nice fresh stack.

Depending on what path the user took through the second flow, eventually something they did would update in two places, and ultimately something got confused and led to one of the four crashes.

The reason we were seeing the service error in stage was that the current stage services had a wrong switch turned on and that was triggering the error which should not have otherwise occurred! Without it we might have poked forever and found nothing.

Now that we saw the problem, the fix was easy: go back to the beginning the right way (pop back to the beginning). Now all four crashes are fixed.

Fun afternoon of debugging. I rarely get to do anything like this since its always better to not have any problems in the first place and that’s always a priority!

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.

Looking at the App Store you can see that many companies ship as often as possible, two weeks is common but you see even less then that. Other companies ship more irregularly and some like my employer ship 5-6 times a year at most.

Companies that have a shipping pipeline of two weeks or less often have large staffs and are highly organized so that no developer does a lot of actual work, changes are generally small, and anything more complex are worked on in separate branches with frequent merges to keep up. The emphasis has to be on never breaking anything since that would gum up the pipeline. By having a large staff making many small changes with lots of testing support—automated is basically the only way—you can hope to keep the regular pace up.

The question I have is why is such a fast pace even required? Sure you can talk about keeping up with the market and trying to get the best product for your customers, but what of the cost? If you have dozens or even hundreds of mobile engineers (Facebook and Uber come to mind) constantly churning out new releases in a complex dance of branches, is shipping every week or every two weeks really worth the cost?

Having worked on travel apps a couple of jobs ago, our customers for the most part used our apps to book travel a couple times a year, sometimes they might browse a few more times. What would shipping every two weeks do for them? The odds are that most of our customers might run 10% of our releases and thus rarely even take advantage of anything we churned out. It’s doubtful they would even notice anything new or fixed. Not every app is used every day.

If you routinely make changes or a new features on a frequent basis to an app likely to be used on a regular basis, some people might find it unappealing that each time they use the app it changed. Today no one ever puts in release notes about what is different (probably since most people never read them) so finding out by random chance is more likely (hey where did that button go?).

You might say: there are bugs so we need to get fixes to our customers quicker. Are there serious bugs because you are shipping the apps too quickly to create quality? 30 years ago we didn’t ship until the app was solid since we couldn’t send out patches, today patches are so easy that people just assume they can fix whatever they break quickly. I suppose its acceptable to “break things and fix quickly” but I still prefer not to ship out broken crap in the first place.

Another thing people rarely consider is that frequent updating of apps can also cause a lot of bandwidth usage on your customer’s devices especially they have automatic downloads turned on. If your app is 150MB and you release every two weeks thats 7.8GB a year! Maybe that’s not a lot but in the upcoming nightmares in the ISP world with the loss of a neutral internet bandwidth might become precious again—or horribly expensive.

I noticed that TripAdvisor, who has a canned release note about shipping every two weeks, had a long break where they didn’t seem to update the app for a couple months. Naturally when they shipped again they kept the same message! The downside of a fast pipeline with a large staff is the inability to make major changes, either functional or architectural, without a massive branch dance that no one finds fun. It’s hard to do a big addition if you have to keep integrating other changes continually, causing more problems with automated and unit tests breaking left and right. Eventually speed kills and now you have a lot of problems getting it back.

I have never been a fan of shipping on a short schedule, I’d rather ship quality without the constant fear of breaking things and be able to spend at least some time thinking about how to do it right. I also am not a fan of huge teams where no one actually does very much in the interest of shipping fast.

I do wonder what your customers think if you ship every week or every two weeks versus every month or every two months. Do they even notice? Does it change how they use your app? If the only reason to ship fast is that you can brag you ship fast but your customers get nothing out of it and your cost of development is very high is it really a good idea?

At my job we ship every two months and the process is byzantine and horrific and more words I’d rather not type out. It’s the opposite of fast—we have too many people, a highly fragile code base, outsourced testing, and massive fear of shipping anything broken which of course happens anyway. I can’t change anything about it which is very frustrating. I am also sure we are not the only company in this mode of slow and expensive and messy.

There is happy medium, where releases happen at a rate which is easy to sustain yet can be speed up if needed. At the travel company two jobs ago we shipped reasonably fast (once a month or so) yet when needed to we could find a bug, fix it, test it and release the same day. The staff was small, localized, with minimal process and amazing testing resources. Despite having several apps (5 native mobile, a mobile web and a mobile api) we supported these with only 12 programmers total plus a few testers, a few designers and a scattering of managers. This type of small integrated team with little overhead allowed us ultimate flexibility to ship what made sense, either slow or fast as needed.

I’d rather have a team that was this flexible and a company that understood what its customer base really needed. I’d rather ship a quality app that didn’t require patches with a process that supported this flexible attitude. Too fast is not really a panacea and too rigid a process isn’t great either. Putting pressure on a team to deliver deliver deliver always at warp speed probably contributes to massive burnout. Sure companies like Facebook and Uber seem not to care about how many people they hire and what it all costs but that still seems crazy to me.

Even at my employer (non technology but every knows us) we waste enormous money on way too many people and a way too complex and horrible process that is also way too slow and inflexible. I know a lot of people here who want to have that quick every two week auto pipeline but that’s not going to happen either. To support rapid pace you have to have a good architecture, good discipline, a lot of people who do very little every day and be willing to avoid big changes. We don’t have any of that.

My experience at the Travel company (now sadly just a marketing brand of someone else) showed that there is a middle ground that is cheaper, more flexible and a whole lot more fun to work at. Yet even that requires a company willing to have fewer people but allow more freedom to innovate and hire good people who want to stick around and be part of this, and that isn’t going to happen at many companies. I was lucky to experience it.

Maybe a fast pipeline with a massive number of people works for you, I hope it’s worth the cost in dollars and in burnout. I sure know that massive people and a slow pipeline from hell isn’t working too well either! For me, I’d rather be in a small flexible team and ship whenever it’s a good time.

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.

When I started in 1981, most of those roles did not exist as separate people, in many cases we had only two: managers and programmers. The defense contractor I worked for basically had managers with programmers and managers who needed programmers. When I was assigned to something as a programmer by my manager, I was expected to do anything that was required from figure out what needed to be done to writing, testing and delivering—and often documenting—whatever it was. There was a concept of a programmer-analyst who did the first part but what I remember was we all did everything there.

Naturally what other companies did was a mystery—without an internet or any of the modern communications channels how other people did things was not known to us.

Having to do everything turned out to be a real benefit later on, I was comfortable with such diverse things as communicating with customers, designing UI, identifying and tracking plans, architecture, and other non-programming tasks. With today’s roles unless you are in a startup environment (sometimes not even there) as a programmer you rarely get to do anything but write code. People even joke about programmers doing other things like designing.

In the 80s programmers in general did a lot more things that today are all specialized. Of course we had applications with fewer moving parts like networking and databases, but we also worked without a whole lot of outside help, or open source, or any modern convenience like email.

Another difference was that huge teams were basically impossible to organize. Imagine working with 100 programmers on single application without email or Slack, code repositories, JIRA like tools and no way to coordinate software remotely other than Fedex and cartridge drives. Merging code between teams was a manual process–tedious and error prone unless you were really careful and disciplined.

My team actually did all this for Persuasion, we were in Texas and the author was in New York, we traded code via Fedex every other day for 8 months. Later on in the last release of Deltagraph around 1993 we did it again as the publisher in California added a couple programmers.

Today no one would build software this way. But today we also have the network, tools and processes to coordinate huge teams—but the cost is really high as so many different specialized roles have been created to support this. It’s funny how we’ve created so many tools today that would have amazed us back then yet need so many more people to get anything done.

Over the years I’ve always worked on small programming teams, other than the last version of Deltagraph in 1993 with 6 programmers, a project in the mid 2000s in Mexico that had 40 (and was a huge failure) 4 is the most I’ve ever done even large projects with.

Of course during the last few decades the non-programming side of projects has garnered an ever-increasing set of roles. It’s funny how we built Deltagraph with 4 programmers, 2 testers and a product manager, and built a product that lead its niche worldwide. Today at my job at a huge non-technology company (you would all know) we have 80 iOS programmers and more non-programmers and support people and managers than I even know. Yet functionally in the entire app (basically there are two similar ones) is not really that complicated.

The team I work for only has two iOS programmers now (we had three) and we built a large addition to one app with two programmers, ported it to a third business unit’s app, and built three internal apps during the same timeframe.

The Mexico project on the other hand had 40 programmers from three countries fly in every week to sit in one room in what was a death march. After three months the whole project cratered. The customer ran out of money.

At the travel company (two jobs ago) we also had a small team and managed to build and support 7 products with only 20 people total, half of which were programmers (4 iOS).

I still enjoy doing more than just take a ticket, work a ticket, PR some code, move a ticket to a new state—which seems the modern programmer role.

Today programmers don’t get the same “education” I got when I had to do everything myself—its something that you can only do if you get to experience it, which is why working at a startup can be really useful. From what I can tell that’s not always true though, often startups assume the whole suite of support people are necessary, and programmers do nothing but write code. If you have a lot of VC money I suppose it’s easy to spend.

Even with all the modern tooling and processes, from what I can tell enormous teams of programmers are very common today. At a recent conference I went to I asked people how big their mobile teams were, and having dozens of programmers was the norm. Uber has more than 100, I dread to think how many Facebook has.

What do they all do? I think the average programmer today writes very little shipping code every day compared to the 80s. I assume the norm is to write very little, write lots of unit tests, spend a lot of time in process and meetings. If you do these things you can’t get much shipping code done compared to what we could do back then when we had few tools, no email, no repository, no process other than what we came up, sat together and communicated by talking. We had much more time to contemplate what to build, how to build it, how to test it than most today; at least for my two companies (1985-1994) we generally had releases every 6 months or so. Since we shipped on floppies in boxes and had to charge people for a release you couldn’t release often.

Mind you we didn’t do Waterfall either, everything we built was done in an agile fashion long before it was called that.

Today people push software out through automated pipelines and release once every week or two. At my job we are lucky to release every two months due to a horrid process despite all the people. If you have a huge number of people who individually are responsible for little but are part of a large organized pipeline with automated testing you can get it out the door really fast, but it costs a lot of money and I am not sure that the end result is necessarily all that good.

I’ve usually worked in resource limited teams where we had more freedom to get things done, even in large projects, but never where the product shipped every week on a regular basis. Is the expense of large automated teams worth it? Maybe for some companies.

For me I would rather have a too small team that does more things for itself and needs fewer support people. I could not work in one of these 100 programmer turbocharged teams. It doesn’t sound fun at all either. I don’t know how to compare products built by 4 people taking time versus 100 people pumping out weekly.

I’d rather do a lot more things and take time to build a decent quality product and not spend a fortune. In the end it matters what is important to you and your company and what you can afford and how willing you are to organize a lot of people or else wait a little longer.

Are more people doing less with more organization and support people better than fewer people doing more individually? One can argue both approaches. I just prefer to be part of the latter.

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.

To really know how far the world has changed you almost have to have been there with me on that first day and experienced how the changes happened. Almost everything we know today in programming, plus of course in the world itself, has radically changed in the ensuing years.

When I started on Monday I had absolutely no clue what a real programmer did. There was of course no internet, no web, no books, few computer related magazines, basically no place I could even look up a bare idea. I had little confidence, I assumed that this might be too difficult for me to do, I had no concept of programming as a career. There were a couple of college friends who worked as a programmer but what little they told me about didn't help much.

On that first day I wore a suit to work. Everyone did. No one had a computer on their desk. We had a bullpen with terminals (both IBM and Harris) that you signed up for time on and thus were shared resources. On that first day I met two “old guys” who did batch programming on the IBM, they worked on multiple projects at a time as they got only one compile-run cycle a day. They had started programming, of a sort, in the late 1950s on some kind of analog computer involving plugging in wires. They seemed so old and wise. They were much younger than I am now.

So what would I have thought of this much older me explaining the future?

I would have recognized my current employer, but that it needed programmers at all would have been surprising. That I would be writing code on phones would have been a shocker. How do you write code for a phone? In 1981 phones were hardly changed from 36 years earlier, black with a wire. That something I could hold in my hand had 3GB of memory, wireless networking, video interface and worked almost anywhere in the world would have made no sense. The IBM I was about to train on had 16MB of RAM and was approximately the size of a small house.

That this phone could contact anyone in the world by phone or retrieve information from people you didn’t even know, and that anyone could write programs that did all of this would have been hard to believe. In 1981 networking was something mainframes did or you used a modem. There were no cell phones at all, no internet, even the web was 10 years away, and I had no concept of email either. In 1984 my boss and I had an email account on a local bulletin board but no one to email but ourselves.

A thousand or so programming languages available would have seemed inconceivable, as I was told I would be writing everything in Fortran. There were few choices like assembly language (I had taught myself a couple, 6502 and Z80) but generally everything was written in Fortran there. Later I would learn Jovial as the Air Force would be using that until Ada was fully available but on my first day I had no idea.

That there were millions of people writing code for free and making it available to anyone to use would have seem shocking as well. Free? Software? Until my future self could explain what an internet was I would have thought you got tapes or floppies or something. The whole idea of people giving work away for nothing would have seemed insane. That you could generally use it in your own applications would have had no real analog to me.

A world wide web, something that ran on this internet and allowed anyone to post anything that anyone could read, and that programming info was available in staggering amounts, and that I could order virtually anything and have it delivered in an hour or a day or so without leaving my couch would have seem science fiction. Even mail order back then was not exactly swift or easy to do. Being able to stand in line, download an app, and run it without moving would have been just as strange, especially when I said people wrote millions of these apps including me.

On that first day I assumed people who ran companies were geniuses who never made errors and I could never be one of those. But it took only a couple years to find out how dumb ours were, and that I would start a company in 1985 and another in 1987 lasting until 1994 would not have been anything I assumed I could do. That today the biggest issue is that people can hack into companies and steal everything including all of your financial information was not something I would have ever thought of. Back then security was a lock or a guard. Stealing millions of people’s information wasn’t scalable then at all.

In 1981 you really had little idea of what anyone did in programming outside of your job, no blogs, no Google, nothing but the random magazine or if you were lucky, a library with some journals. What little I knew was by trial and error. I would have been amazed to learn how much is available today, yet people still screw up royally all the time. The problem today is too much information and it’s too difficult to learn what you need and adapt it but filter out all the stuff you don’t need.

I would have been scared to learn how much I needed to learn all the time, at an ever increasing pace, to stay ahead of the changes. In 1981 change happened at an almost imperceptible pace. On my first day I had never even considered that this industry (if I even thought of it as such) would change, I assumed it was just that I was dumb and didn’t know much. Finding out that knowledge in programming is a moving target, an accelerating one, and that if I didn’t keep up I’d get run over would have seemed frightening. Maybe if I had know how much I had to change over the years I would have taken that offer to work on a PhD in Chemistry despite not wanting to be in school yet another 7 years.

Thinking about it now I am not sure I could explain the “Cloud” to that younger self at all. Software ran on computers you could see, not some imaginary place that did so much for you in often mysterious ways. Even buying software was a mystery, I think I bought a few things in a computer store before then. Of course shipping Trapeze in 1987 I learned all about it, but in 1981 that was still 6 years away. That one could write software, upload it to an App Store and have it available to the entire planet (assuming anyone would see it) was real science fiction.

I would of course have traveled back then in my normal “uniform”: jeans and a golf shirt and some comfy footwear. To my suited self that would have seem unbelievable yet it took only a couple months before I canned the jacket and then the tie.

That world I started my career in is long gone. I can still remember before all the things we have and use today existed and what I thought about them when they appeared. Today everything was science fiction to that first day programmer that I was.

The future is never what you imagined it to be, yet while massive changes happened before 1981, the pace is what has accelerated to an insane level today. Last year’s big deal is abandoned, there are uncountable ways to do everything, you can’t even grasp more than tiny amount of what the world knows. If this pace continues (if our presence on this planet continues) the world of 36 years in the future, 2053, is unlikely to be anything like today. I would say that if that world is more like today then we will be in serious trouble and our future is in doubt.

I know I won’t be programming any more in 2053 if I am alive I will be as old as Stan Lee is today. Given the enormous changes in the past 36 years I can’t even fathom how anyone will keep up. Will there even be programmers in 2053? I couldn’t tell you.

On that day in early October, 1981 the future of programming, much less the world, wasn’t clear at all, and if I gave any thought to it at all I probably assumed not much would happen. I would have been very wrong.

If I had the chance to tell myself on that first day something, what would I say (again assuming no paradoxes), other than the obvious buy Microsoft stock, would likely have been to never stop learning, though I think I figured that out on my own almost immediately. Maybe I would have told myself than when the time came to decide to run companies or be a programmer, give up the programming. My life would have been very different and of course there is no way to know what would have happened.

But there are no time machines and my life happened as it did. Today I have enormous responsibility and a great track record of delivering applications that work all the time so I must have done all right without the future knowledge. I do miss running the company but I don’t see how that would ever happen now given my total lack of useful contacts. But I still enjoy delivering great products that work.

If any of you have a working time machine I’d love to borrow it. Scaring the crap out of myself in 1981 would be fun. Or maybe I’d take a peek at 2053 just to see where we are going and scare myself.

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:

1. Bug fixes.
2. Many, many, many bug fixes.
3. Of course we are squishing bugs with every update.
4. More bugs eliminated.
5. Back end enhancements and smashing bugs.
6. Minor bug fixes and tweaks.
7. And as always, bugs have been squashed.
8. And of course, the usual bug fixes with every release.
9. Various bug fixes and backend updates.
10. And of course, more bug fixes.
11. Bug fix-a-thon.
12. Bug fixes.
13. Various bug fixes and back-end fixes.
14. Squashed lots of bugs.
15. Various bug fixes and continuous improvements.
16. Several bug fixes.
17. Various bug fixes.

Then a miracle occurs—there was a release nearly two years ago with no bug fixes!

Where the heck did all these bugs come from? When my mom was a child in Germany during the war, the local authorities demanded children in schools go once a week to the fields and look for potato bugs the Americans were dropping in the fields. Of course they never found any. Maybe the bugs are being dropped by a rival airline!

I have no idea how this airline builds apps or who builds them, and maybe the review writer just likes to rebel and comment on how miserable releasing apps is there. I know at my employer every release is a nightmare of bugs that can't be finished and are pushed to the next release (and then pushed again so they never die). Then defects are found after release, resulting in rounds of hot fixes which leak into the next release causing more defects and more defects to be kicked down the road.

Maybe I should be resigned that all software is riddled with bugs and quality is a thing that doesn't matter any more. Maybe I am too old and remember shipping code on floppies in boxes to strangers to whom we could not send a hot fix since we often had no idea who they were, so what we put on that floppy (or in Deltagraph's case, 10 floppies) had to live unpatched for at least 6 months. Perhaps as a dinosaur I am out of touch with modern software development and should just accept that each release should consist of 99% bug fixes and 1% new functionality, plus another 20% bugs to sow the next release's crop.

Yet I refuse to accept bugs, I didn't back then and I still can't today. I want the code I write to work according to my long standing philosophy: the code always does what it is supposed to do, never does what it is not supposed to, and is never surprising in what it does. I am not satisfied unless what I write functions.

Just because the customer expects things to work, since they are paying for this (directly if it's a product, indirectly if the software is adjunct to the real product like an airline or here), I want to make sure they get something that works.

I'd rather not have any bugs to fix and be able to take the time to build some useful, delightful, or necessary feature.

Someday I would like to read an app release note and see: "We didn't fix any bugs because we could no longer find any."

But I am just a fossil, don't listen to me.