The Reality of Software Development Pressure

I recently heard a quote from someone (and if I could remember who said it, then I’d give attribution – but this is what happens when tweets just happen to scroll on by, right?) that I liked:

Setting deadlines before requirements is like setting a wedding date before you’ve met your partner.

And yes, it’s obviously tongue-in-cheek, but it’s lead me to think a lot about the breakdown that exists between all of the discussion around software best practices, things we should be doing, architectures and patterns we should be following, and then what we’re actually doing and what we’re shipping out to the world.

Development Pressure: Setting Requirements

At this point in my career, I can’t help but wonder if we enjoy talking about and discussing a lot of the things we should be doing as some escape to some of the hacked solutions we end up releasing.

Development Pressure (A Decade or So In)

When it comes to software development pressure, I want to be clear that I’m not creating some faux-complex about how hard it is, nor am I trying to insight some pity party.

Because let’s call it for what it is:

It’s a solid gig where we get to sit (or stand) at a desk most of the day, use some neat technologies, and create solutions for other people.

Many of us get to wear what we want to wear, drink as much coffee, water, or whatever other provided drinks that we want, and even have flexible hours.

Development Pressure: Cushy Offices

All things considered, this is what we call “cushy.” This isn’t to say that it doesn’t bring stress like any other job or any other position, but the point I’m trying to make is that this isn’t a statement about “poor pitiful programmers and their frustrating work environment.”

That’s not what this is at all.

Instead, what I’m talking about is strictly about the pressure that exists between what and when we need to ship a solution and the best practices that many of us are aware of but may have to forgo to meet a deadline.

Leap Before You Look

Since the nature of computer programming centers on problem-solving, it’s inherently difficult to account for all of the variables during the outset of the project.

You know the least about the problem domain at the beginning.

And that’s true for many other areas, too. But the point that I’m trying to make is that it’s funny, in an ironic way, that we set goals, milestones, and deadlines before we’ve dug deep into the domain where we’ll be working.

What happens, then, when we get four weeks into a two-month project, and we realize there’s a lot for which we’ve yet to account during scoping, planning, and setting the requirements?

More often than that (though there are exceptions), deadlines stay fixed. Furthermore, we’re usually left with the same due date, the initial requirements, and then some because we learn more as we move through the project.

When Reality Sets In

Assuming, from the outset, that you care about many of the best practices for whatever platform and environment you’re working in, you’re likely committed to things such as:

  • following the coding standards for your language,
  • including some testing (or various types of testing) to ensure a level of quality,
  • making sure the third-party tools you’re using are catering towards your needs with as little bloat as possible,
  • incorporating whatever design patterns fit most natural for certain areas of the architecture,
  • and on and on this list can go.

Many times, software projects start off with the best of intentions. At least, in the ideal scenario, they do. But the more you learn about what you’re building and the more you realize you have to take into account coupled with the looming, immovable deadline, the more the quality of the project degrades.

It changes from this goal of writing a pristine, maintainable, clean solution to “we need to make this work so we can get it out the door.”

And when that shift happens, when we experience that realization, when the software development pressure starts to rise, it can drastically change your perspective on a project.

What a Bummer

This whole thing is something that I’ve read about, thought about, and wrestled with for years. And it’s not something for which I have a clear solution. I do know, at this point, that I try to approach things from a realistic standpoint.

  • Most projects are not going to be as pristine and well-developed as I’d like,
  • When I have the ability to add flexibility to a schedule, I will always take it. I won’t do so for scope creep, though. I will do it to refactor and refine what I’ve done to meet a previous milestone.
  • “Getting something working” is okay for a phase when you need to demonstrate something, but it’s not good enough to ship.
  • The resulting product is not necessarily – or, in many cases, not at all – reflective of one’s ability to architect solutions. Instead, it’s reflective of what needed to be written to maintain stability for a shippable version.

There are other things that one can add to this list, I’m sure, and I don’t even know if what I’ve listed fully represents all of my thoughts.

What I do know is this: I love what I do for a living, and I want to be as great at it as possible. The tension that I experience when working on projects for others or even myself when I realize I don’t have the capability to architect the solution to the degree negatively affects morale.

Perhaps a better way of putting it:

It bums me out.

And I don’t mean to say it in a fleeting manner, either. It’s one of those things that sticks with me. “This project didn’t go as planned because the quality of the work that powers the solution isn’t up to the standard for which I strive.”

It’s Not Just About Development, Either

I think this transcends industries, too. If you’re invested in your work and genuinely care about your craft and what you’re trying to put into the world, you can’t help but experience a bit of disappointment when those things happen.

Unfortunately, I don’t have a solution for how to overcome this. At least I’m able to articulate it more clearly than I was, say, a few years ago. But just recognizing and discussing it doesn’t do much regarding rectifying it.

Development Pressure and Missed Deadlines
Missed Deadlines are common. Unfortunately.

Then again, that doesn’t mean things can’t be put in place in future projects to try to make sure there isn’t more room to allow for less pressure.

At any rate, I share this because I know I’m not the only person who has experienced this at work (especially so as it relates to any development). But I also share it in case anyone else – further ahead, on the same page, or looking at it from a different perspective – has something to offer in the meantime.

If it’s something that’s common among people of a given industry, then I’m sure others have something to say. I’d love to hear it.

3 Replies to “The Reality of Software Development Pressure”

  1. ship, ship, ship

    Do it early, iterate often.

    Clients want everything on launch. What happens is the scope changes happen after you’ve spent so much time building when scope probably could have been changed earlier if you were shipping as you go along. I think ship early and iterate is really missed with larger client projects.

  2. I love the opening quote. I wish I had that for a recent project with a completely arbitrary deadline. We know it was arbitrary because the client admitted as much and the PM left his spine in his other pants.

    I think a little deadline pressure is good, eustress and all that, but you’re spot on in that the focus need to be on the domain issues. I think that detective work is an art/science skill that (hopefully) we develop with experience, just like the technical stuff.

    1. I wish I had that for a recent project with a completely arbitrary deadline. We know it was arbitrary because the client admitted as much and the PM left his spine in his other pants.

      Ugh, that sucks and I’m sorry to hear that. Sometimes it happens and when you end up being affected because of it, it’s rough.

      I think a little deadline pressure is good, eustress and all that, but you’re spot on in that the focus need to be on the domain issues.

      Yeah, I’m all for deadlines but ones that are reasonable and that give us enough time to really explore what we’re getting into dealing with working on.

      I think that detective work is an art/science skill that (hopefully) we develop with experience, just like the technical stuff.

      In some cases, I think we do. If nothing else, we develop a methodology that we can apply to most new projects that include problem domains outside of our usual bit of knowledge.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.