Tag Archives: software development

Work Drained Me

Happy Saturday, dear readers! It seems I missed Friday’s post. Please blame my work on this. I’ve been mentally exhausted most of the week as my tasks have changed on a near-daily basis. On the days that the tasks haven’t changed, I spent most of my time realizing that what I thought would be a relatively easy task is far more complicated than I first thought. And then I’d realize it’s even more complicated than that the next day. So by the time it came time to work on my next post about Spinning Wyrd by Ryan Smith, I had nothing left in the intellectual gas tank. So today, you get some vague ramblings of a software developer.

The big issue I ran into today was discovering that a preexisting piece of software was an architected in a way that made the feature I was supposed to add to it nearly impossible1 to implement without a massive rewrite of the existing code. Since we don’t have the time or budget to rewrite the existing code, that new feature was finally shelved after I spent two days playing “why won’t this stupid thing work the way I think it should?”2

This whole experience is a reminder that project managers and project architects really need to spend more time thinking about a product roadmap for software. They need to try to anticipate what future features might be added so that when they make these architectural and design decisions, they don’t implement something that makes those features nearly impossible — or even just difficult — to implement. No one can possibly envision every feature that might get added to a piece of software in the future, but I’ve encountered more than one scenario like my current one and thought “someone probably should’ve sen this coming.”3

At any rate, my apologies to my readers who were looking forward to more book discussion/Heathen talk. I promise to get back on schedule next week. For anyone who observes it, happy start of Winter Nights on Thursday!

Post History: This post was written on October 12, 2024. There was no proofreading or revision process.

Footnotes

  1. Not completely impossible, mind you. As I’ve thought about it, I think I’ve come up with a workable solution, but it’s ugly. We’ll see when management decides they want to spend the time and money to revisit the feature. ↩︎
  2. Part of what took me so long to figure out why things weren’t working they way I thought they were is because I’m the fourth person to work on this piece of software and the original author who laid out the architecture left the company a couple years ago. So I’ve had to delve into the details of how the software works to a degree I haven’t had to before. Oh, and it’s written in a programming lanuage I’m not terribly familiar with. Fun! ↩︎
  3. For full disclosure that “someone” has been me at times. I’ve made design decisions in the past that I later realized were a mistake I should have anticipated. There’s a whole other discussion to be had about why this sort of lack if foresight is so common. ↩︎