How to Avoid Falling Prey to Try in Software Development - the Long-term Consequences are Too High

Critical deadlines approaching. Poor planning and coordination. Last minute changes.

"Well, we can try to reach the deadline with the new changes?" - are you really saying that?

Question mark : a punctuation mark (?) indicating a question. Used to express doubt or uncertainty about something.

You already asked your team and they say it is not possible. It is too late to make last minutes changes to the delivery. But your boss is asking you to try. Under the pressure from his expectations and your hope it will boost your career, if you manage to deliver it, you fall prey to try.

Frankly, you wished you boldly said: "There is no way to reach your expectations!". Instead you end up uncertain saying: "We can try? [thinking : I guess]".

"Do. Or do not. There is no try." - Yoda

In Robert C. Martin's (aka Uncle Bob) book The Clean Coder he tells you to say NO! in these circumstances. Of course, he suggest a way to deal with it. More about that later.

A Situation You Might Know?

You already know the team cannot make it. Why would you make their life miserable and force them to cut corners to implement things that are hard to maintain?

It is like building a Cathedral in wood while being blindfolded and expect it to be sustainable for a couple of hundred years.

On top of that, the poorly constructed wooden Cathedral is requested to have a tower. You ask your software engineers to build it, while they need to keep the Cathedral from collapsing (hotfixes). You do not leave any time to re-do or learn from the unsustainable situation.

Over the span of years you can imagine how work satisfaction will fall and fail miserable.

As a manager you have a responsibility to keep the long-term work satisfaction of your software engineers. If you fail on that, you will end up with a team of uncommitted and burned out software engineers where the best ones will find new jobs.

Feature vs Quality Expectations

But isn't it also your responsibility as a manager to deliver what is expected?

Well of course it is.

The key is to understand the balance between product and feature requests (building the Cathedral, adding a tower, etc.) and quality (in wood while being blindfolded) in the delivery. Almost every time when a team is requested for new products or features the quality is implicitly expected and not formally defined.

Still, it is your responsibility as engineering manager to keep quality aligned with expectations.

The main challenge with poor quality in a delivery is that you first pay the price later, that is, you first feel the consequences later. The Cathedral can be used, of course it might have low user satisfaction, but you expect the tower you are building will change that. As time passes by, you spend more and more effort to prevent the wooden Cathedral from collapsing by adding pieces of wood to stabilize it (hotfixes).

The challenge is not only that the Cathedral will not provide the expected user satisfaction. The challenge is also that the people building it are not satisfied either.

They expected to build a Cathedral they would be proud of. Instead they end up with something looking like a miserable wooden shed that needs daily reinforcement not to collapse.

Is that the reality you want to present to your team?

But How To Avoid Falling Prey to Try?

Uncle Bob suggest something in The Clean Coder.

He suggest to compromise in a deliberate way. Say, for a deadline of a product you can make a mock-up with missing functionality or without backend features implemented. This way product can be shown and possibly launched in beta, while the product or feature first is expected to fully implemented afterwards.

This is obviously a compromise for both management and software engineers, but one where long-term quality can be kept on a sustainable level, as the finalization of the request is finished after the deadline.

The key message from Uncle Bob is not to fall prey to try. If you commit to try, you will be failing on long-term quality and job satisfaction for the software engineers.

Summary

When requested unrealistic feature and product demands, do not fall prey to try. If unavoidable, make a compromise in a deliberate way that maintains the long-term quality at a sustainable level.

You do not want to maintain a Cathedral build blindfolded in wood while constantly reinforcing it manually. It is not sustainable and will make your software engineers life miserable.