Stress And Programming

Having spent four decades as a programmer in various industries and situations, I know that modern software development processes are far more stressful than when I started.

It's not simply that developing software today is more complex than it was back in 1981. In that early decade, none of us knew if what we were doing made sense, and almost everything you did was new, and there was a distinct lack of information on how to do anything available.

The processes were the most significant change between then and today. Contrary to some stories you might read, Waterfall was not all that common in my experience. I don't believe I was even aware of the name, much less the stepwise process lampooned by Royce in 1970, until around 1997.

What we did back then was far more relaxed; generally, it was release-focused. We did not make many updates since we shipped our apps on floppy disks and had to charge for updates ($5 cost for disk, duplications, packaging, and shipping). Generally, we stuck to what I jokingly call a "Madagascar", 6-9 months (penguin joke from the movies).

So development started with a list of things we wanted to add (for Deltagraph, it was the publisher's desires). We worked on them over time until we got closer to a cut-off date, after which we tapered the development and focused more on testing. There was plenty of time to devote to trying approaches, even starting over, and thus it was a far more relaxed process. We did not have email until 1991, and of course, no sprints, scrums, backlog grooming, Jira, and all the processes that dominate today. Yet we could ship things that worked despite having none of these things.

I retired four years ago, but I still keep in touch with former co-workers, who often have significant stress, such as closing tickets, meeting sprint promises, shipping on way-too-often schedules, and dealing with management yelling to go faster, dominating every day. Stress comes when you are overwhelmed not simply with work, but pressures to constantly exceed arbitrary demands, and try to cope with changing requirements, designs, schedules, and executive whims. Everything becomes an issue, and no one enjoys working. People try to cope with pressure and stress, but not everyone can manage it well.

Shipping way too often is, to me, a sign of poor management. I remember arguing with the shipping team, who insisted we needed to ship our mobile apps every two weeks (during the pandemic year, no less), even though we had successfully shipped five times a year before then without issue. They pointed to other companies' mobile apps that shipped every week or two. Yet, our business rarely changed much more often than every few months, and the nature of our business is that our customers came and went for a week or two, then possibly not for a year. This is similar to an airline, where you rarely use the app, unless you want to fly, or are about to board.

Updating your app or website faster than your business changes is unnecessary. Sometimes people insist that it's to roll out bug fixes faster (the team I argued with said this). My reply was Why are we shipping buggy apps? Would it not make more sense to ship less buggy apps, so we don't need to fix them so fast? They claimed there would be no need for hotfix releases since you could roll it into the next two-week release; in fact, they did a one-day hotfix soon after!

Shipping often takes time away from development, no matter how much you automate things. In our case, a new feature had previously taken about 2.5 months to get into the app, yet in the new scheme, any new feature had to be completed five sprints before the release it would be in, which took the same time! With the increased speed and more complex process, development had more overhead and less time to complete the work. This, of course, caused more stress to the teams to "keep up".

When I worked at the Travel company (more than a decade ago), our mobile team had 4-6 apps and mobile websites, and we had something like 80 releases a year, often simultaneously. Our process was straightforward; I frequently touched four apps daily, and we shipped when everything was solid, including building several new apps from scratch. At one point, we were forced to do Kanban on a new app, which was pointless as the app had constant requirement changes. On another app, the rest of the company tried to force us to do Scrum to slow us down to their pace (3 releases a year of the main website), but it failed miserably, and we returned to our freeform process.

When you can take the time to do things right and have more control over how you do things, you can often get things done faster and more productively. It doesn't work that well in large teams, but with 3-6 people, the process is mostly pointless. That was my experience in the 1980s and 1990s. Having control over how we work and having time to figure out more optimal ways to work makes for a much more stress-free environment, even if there is much to do.

How much time do you get in a Sprint to figure out how to do something better? Often, you have to estimate things at the beginning and get yelled at if you don't finish. In my final job, we were frequently forced to estimate an entire project's worth of Sprints ahead of time and then redo it repeatedly as requirements constantly changed (and not on a Sprint boundary either!).

If you focus more on releases assuming no timing requirement (like a server change or business reason), you can often get more done with fewer people since the process overhead is much less. Having the freedom to control how you do the work can frequently minimize stress. It doesn't work in all cases (large teams of random contractors or situations with multiple coordinated teams, for example). Still, anything where the process is more relaxed will often be a better experience for everyone.

Sadly, my opinion is unpopular with executives, who want programming projects to resemble assembling chairs and be predictable months in advance. This does not work very well, and with so many heavy-handed processes, productivity goes to hell. Programmers and others get stressed, which leads to more delays and less progress.

In my last job, despite all the sprints, schedules, meetings, and complaints, I got more out of my way-too-small team than teams with many more people because I managed to keep my team somewhat more relaxed and productive. It wasn't always possible, but the stress level for everyone was much lower, and we got a lot done, and it worked.

If you are in a stressful situation right now and in a job that seems more like a rigid prison, you should find yourself in a different environment, preferably in an industry that doesn't require rapid shipping and a company that is not in a hurry. Being stressed out daily is bad for your health and physical well-being and will likely result in you burning out. It's not worth it, no matter how much they pay you. I survived for four decades, but even I nearly gave up in late 2000s after two horrifically stressful jobs; I finally said screw it, and worked at a poor game company for way too little money, but lots of satisfaction and appreciation from the customers! Sometimes, the best thing is to cast about and find something you enjoy, even if it temporarily results in less money.

Stress and programming do seem to often come together, but it's not worth it. Even from a business standpoint, it's not worth having a staff or team that is stressed out and becoming poorly productive.