Expectations

The secret to not going crazy or burning out while working on a large development project is to control expectations.

Software development always takes time. But these days it is usually extremely rushed, which is bad. An endless game of hurry-up-and-wait.

If you are stuck as a developer in the middle of this game, and you are entirely reactive, you will take a lot of nasty bumps and bruises; it will not be pleasant.

So there are a bunch of things we want to do to make our own experiences better.

First is that we want to disconnect the development from the domain's hurry-up-and-wait behaviors. A good development shop is smooth. It picks a reasonable pace and just keeps working at that pace. It makes life far more pleasant and bearable. You think better under less stress.

But that is not how the users and stakeholders generally operate. They lurch from drama to drama, diving into any development issues in between, when they have the time, thus causing constant changes in priorities, focus, and work. Disconnect from that.

You can’t disconnect if they don’t trust you. In fact, if they don’t trust you what happens is that when they are focused in your direction they will tend to micromanage everything, causing even more problems. You don’t want that, so you really want them to trust you instead.

Trust is a 2-way street. They won’t trust you if you bullshit or lie to them. So don’t, even when it seems embarrassing. Be really honest and straightforward.

If they are asking for something that will go wrong, tell them it will go wrong. If they insist on doing it anyways, remind them that it will go wrong, but then do it as they asked. If you can, prepare a rollback or a plan B or something. When it does go wrong, don’t say “I told you so”. Don't belabor the point, don’t even make a big deal out of it. If you had an alternative, suggest that, and lightly try to convince them that it will help them recover.

It may take a few dozen times through a bunch of messes, but if you are honest, doing the things that they wanted, and are there to help them when it doesn’t work out as planned, gradually they will start trusting you. Which is what you need.

Once they trust you, you can spend a little bit of effort explaining non-functional requirements like technical debt, and how it is important to clean up. A clean shop is an efficient shop. You probably still won’t get very much time for that during any of the crunches, but in between, you can redirect most effort over to making things better. This is where you figure out how to keep working in a smooth manner, even though the users are wobbling.

In time, if things are going well you can start looking ahead and even proactively anticipate the incoming work and overall direction. If you are paying attention to why they are getting bounced around, you probably understand a lot of the friction and angst that they are facing, You can work that into your plans, to make their lives better too. Obviously, if you manage to do that, they will be very appreciative.

When they trust you, you are able to set their expectations to reasonable levels. In doing that, you should be able to get them to understand how to match the resources to the work. With that in place, you can make sure things go smoothly, that the development is as pleasant as it can be, and that the quality is as good as the resources will allow. Basically, work is no longer hell.

It’s worth pointing out that you really can’t build new things sanely in a totally reactive state. Construction always involves some amount of proactive behavior, otherwise, you’ll just end up redoing at least an exponentially larger amount of work, or the quality will totally bottom out. You don’t want to do poor or unnecessary work and you will never have the time or resources to match exponential growth. So while some reactivity is often necessary and can even be good sometimes, overdoing it is a recipe for disaster.