By Michal Davidek July 6, 2016

Hope Is Not a Strategy in Software Development

* I hope that I will implement it by the end of today.
* Hopefully it will work.
* I hope that they will deliver it tomorrow morning.

Well, gosh. Whenever I hear a developer talking about hope in regards to software development, I am paying closer attention to what is an author saying.

It means that author of the sentence containing the hope isn't reliable, and relies on some mysterious circumstances. Or he isn't capable of splitting the task into the small steps necessary for ensuring against the need of hoping. Or he simply doesn't know.

Of course “knowing” in software development is desperate to learn and on many occasions it’s impossible to know everything. But hoping is not a helpful strategy to face the problem. Thinking and hoping without collecting the right actions and performing them is not going to help at all.

Why People are Talking About Hope

Hope In Software Development

Inability to say “I don't know.”

This probably has to do with the developer's ego.

It's hard to admit that, even after significant time spent with an issue, we aren't able to solve the problem.

Trust me, not knowing is perfectly acceptable. No one knows everything. Every single developer was (and still is) at the same stage. Everyone hopes to solve a problem with only hard work, focus, and smarts.

By saying “I don't know,” you are accepting a possible failure in the future based on your expertise, and giving yourself the option to stop and think about the problem once again.

When you say “I don't know” instead of “I hope,” you are clearly stating that there is significant reason for you to spend additional time on the issue with learning, trying, and failing.

Not Admitting When You Fail to Solve an Issue

Being able to address the problem alone is great.

But it doesn't mean that you'll devote additional time since it is uncomfortable to admit that you are failing, especially if you are working on a team.

You should be able to recognize boundaries of independent developer, and know when it's time to ask your colleagues for help.

A Tendency to Prefer Simple Work over the Right ApproachProject Development

When we don't know, we are in artificial pressure that we won’t meet the expectations set for ourselves often.

In this situation, we have the tendency to prefer a simpler approach for solving an issue –– one which is not based on the solid foundation and can actually be completely wrong even it seems to be working.

Simple is good, but too simple is bad.

With the tendency to make our lives simpler, we should make a distinction between “simpler” and “too simple”. Although the words are similar, the difference is big.

Simple things are easy to understand, easy to maintain, easy to use, and easy to extend. Things that are too simple only meet the basic requirements make it work. Also, things that are too simple are often not useful.

Too Big Expectations

Everyone has big expectations for themselves.

And when we aren't meeting these expectations, the quality of our lives decreases.

I've seen many examples where people set too big expectations which were simply too hard to achieve in the short term. For example, let’s look at being an independent developer. What does it mean? Does it mean that you'll have to find a solution for literally every problem independently?

When you set an expectation like that, you hardly learn from others, and you'll use the same approaches along the way. It will become harder and harder to face new problems in the undiscovered areas for you, as you continue working “independently”.

Get Rid of Hoping

Admission is the Key

I firmly believe that both the admission of not knowing and the admission that chance is the only thing you have in your pocket are critical to getting rid of living with hope as a software developer.

Imagine that you are talking only with confidence — with no hope, and no assumptions acceptable. What are you going to say about solving the problem?

You will be forced to talk about approaching how to address the problem and laying out the steps you are going to take along the way.

You will need to admit if there are no steps, which exposes that uncertainty is the only thing which is remaining. Uncertainty, not hope.

Of course, you don't need to say it out loud; it's ok to say that you need to learn this and that before you can finish, or you need to ask for advice from a more experienced team member to solve the problem.

Having a Plan

Project Plan

The problems aren’t magically solved or answers to our questions given because of our willpower, our conviction, our passion, or our commitment to making something work. We resolve issues because we have a plan that has a great chance to achieve goal, and we are executing it.

What does the plan look like? It’s breaking the big problem into small, executable steps which you can deliver one by one. Let’s look on the small example:

The big problem: there is buggy behavior in one part of application.

Almost no plan:

  1. Let’s quickly play around, randomly look on the code, try to reproduce the buggy behaviour, or stimulate the data to be able to simulate the behaviour. No time scope, no exact starting point, no initial questions.

Having executable steps (aka a plan):

  1. Verify with the author of the specification of the issue what exactly is wrong and get some useful info about reproducing the issue and context.
  2. Try to simulate the issue on the same environment as the author.
  3. Look on the code where is the most probability the issue is happening and discuss it with the author of the code.
  4. If the problem isn’t solved in time scope specified before, all the steps performed are attached to the issue and communicated with author or the team leader as soon as possible.

It's perfectly ok if your plan contains trial and error steps. They are natural part of searching for solution and it can help with understanding the problem, or verifying ideas rising in your head. They just need to be written down, and prioritized by complexity.

Without a solid plan, you aren't going to meet the goal.

Word on Hard Commitments

In the book by Manuel Angel Ruiz, The Four Agreements, one of the deals to not sin by word.

What does that mean?

It means that whatever you say, is what is true for you. It’s quite simple, you are speaking your truth. It’s a commitment for you. But when you are speaking hopefully, the commitment you are accepting is not clear and even you can’t treat it as true. So how do you know you solve the problem without confidence, if you are only hoping?

There is no confidence, no steps to be followed, so there is the big probability that you won't meet the commitment. Speak with the firm commitment in mind; you will be more respected if you talk openly about what you can finish, and what needs to take further steps to make another commitment.

Time ManagementSoftware Development Time Management

Nothing is worse than the exposure to failure when you attempt to tackle a problem too late.

Being able to properly manage your time is critical to communicating clearly. Being too shy to ask can ruin your time and productivity. Being late with sharing some information with the colleagues can ruin their time management and influence the productivity of the team.

I suggest using Pomodoro for your work. This technique splits the day into several time units with breaks and mainly without any distraction. It works well with defined list of tasks or steps that need to be tackled. Before each unit, you choose one task or step, and have an exact time boundary to try to solve it. After, you can do a small retro if you are closer to the solution or not.

It's more productive than simply setting out to solve some issue and not be sure how much time you will spend on it.

Mentoring

Mentors can help to course-correct when they see someone going down the wrong path. Having a mentor means that you’ll waste less time worrying about what you’re doing, and more time developing the skills you need to help you achieve your goals.

I'll tell you my story.

I am a senior developer with more than eight years experience in industry. Even with this decent amount of experience, I am more than happy if someone more experienced can tell me about any flaws, discuss the problem with another perspective, review my code, and — in the end — teach me something.

There is plenty of stuff to learn every day, and mentoring can be an incredibly useful technique for gathering knowledge.

A good mentor doesn't need to know all the technologies and be a master in every aspect of the project. A mentor is good because he has a lot of experience with solving problems and tackling issues. He can easily give advice on what to try or which approach will be best for your situation.

He was once in the same place as you, the most useful principles in programming were already learned, any time a new piece of technology came out. Names and terms may have changed, but the principles have not. Understanding principles is one of the key characteristics of the good mentor.

Everyday Learning

Nothing can lead to improving your communication skills as everyday learning can. By learning new things, there is a significant chance to discover not only a lack of knowledge in practical things, but also a lack of knowledge in soft-skills.

Learning, and maybe more importantly, listening to others will open the mind to improve your own knowledge and communication.

Retrospection

We have to understand and analyze our past performance — what’s worked and why; what hasn’t worked and why.

We have to look at what we are doing differently than before. we have to test the ideas; we have to assess why they will be more successful, what the risks are, and how we will address them.

I am performing the retrospective in a weekly manner. After every single day, starting from Monday, I make notes about the content of my work — with what exactly I was busy with and what I have finished. Each Friday on the end of a day I look at the notes and try to find out what was good and bad about that week. The output is a list of pros and cons about that week and, more importantly, a list of the most important things I wasn’t able to finish. These items will be first things which I’ll tackle next week.

After several weeks of performing such a personal retrospectives, I felt confident that I hadn't missed anything important, and my performance increased significantly.

Sentences That Can Help

Checklist In Project Development

Instead of speaking with the hope, you should instead be focused on the precision language. The following sentences are examples used in the most common situations and how they can be replaced with the better language. You should use this language in everyday communication, in talks with colleagues and most importantly, in talks with yourself.

  • Situation: I don’t know.
    • Bad: I have one more idea to try, maybe it could work.
    • Good: It would help me if someone could look into this problem with me.
      Note: The better sentence will immediately lead to admitting that your situation is not in your hands anymore and you won’t pretend the opposite.
  • Situation: The task is in the area without in-depth knowledge.
    • Bad: I’m seeking the codebase and I found several places that could be affected. It doesn’t seem like a difficult task.
    • Good: It's unpredictable how long this task will take due to my lack of in-depth knowledge about the affected area.
  • Situation: Finishing of the task is depending on the other team work.
    • Bad: I’ll call them again and say that I’ll be able to force them to finish it today.
    • Good: There are outside circumstances I am unable to influence, so it's unpredictable when I will finish the task.
  • Situation: The task is almost done.
    • Bad: There are some minor issues to solve, but the task is basically done.
    • Good: I specified five more steps which are needed to be done to complete the task.
  • Situation: There are many known places which will be affected by the task.
    • Bad: The task is clear even there are many affected areas. When it will go smoothly I’ll finish it today.
    • Good: I need the time to discover affected areas of the codebase to have the clearer picture of the task first.
  • Situation: The task is inside a codebase with lack of the documentation.
    • Bad: I’ll take a look into the codebase and I hope that I understand it.
    • Good: There are unknown or undocumented areas inside the codebase which I need to have explained by a more experienced team member.

Stop Hoping

Stop hoping, and do what you know you need to do to achieve the goals and outcomes you’ve set for yourself.

If you don't know, just ask for help from somebody else. Try to learn from this person or learn by ourselves. Speak openly, with the firm commitment in mind, and no assumptions.

Specify the concrete steps which you're about to do, but know when they are not working. Be diligent enough to make the specification of the task clear. Take responsibility for the retrospection, execute the tests, and draw conclusions about the improvements yourself.

Be a better developer with everyday learning, whether you are learning by yourself or from anybody else.

In software development, hope is not a strategy because it can’t lead to the outputs in definite time.

If you're great at what you do, but aren't getting the compensation you deserve, you might want to check out our Simple Programmer course: How to Market Yourself as a Software Developer.

About the author

    Michal Davidek

    I’m a software engineer who is consistent in delivering high quality and well-tested software, specializing in helping other developers write amazing tests, helping them with practicing test driven development and especially making behaviour driven development possible in every organization structure. I have a blog about programming and skills needed by every software developer, am on GitHub, and I'm tweeting about technologies and programming exclusively.