Consider This When Navigating a Software Project

Recently, we have talked about The Most Important Thing in Software Engineering and one common reason Why Many Software Projects Fail. In this article, I want to look at another common problem that you should avoid in IT projects.

Let’s imagine you are on a hiking trip with a friend. You have a great time exploring nature and the beautiful landscape around you. However, the region is unfamiliar, and therefore you need to check that you are on the right track from time to time. Otherwise, it might get dark before you return from your adventure, and then it gets complicated to find the way back to your accommodation.

Let’s assume you have no GPS signal, your smartphone got lost or the battery is empty. How would you navigate your way back? At least you have a map in your back that you picked up at a tourist shop. You unfold the map and identify your destination immediately. However, your destination is only one part of the equation. You also need to know where your current position is. How would you find out? These are some options:

• Look around you to identify hints about your current position, maybe a street name, a monument or some other sight.
• Ask a passenger walking by if he or she knows the region and your current location.
• Look for a hiking map located at some intervals on the hiking trail where you can find a marker of your current position.

You might even need to walk further for a while until you come across one of these options to find out your current position. Now, how does that relate to software development and IT projects in general? The answer is simple: Whenever you want to reach a goal, you need to know your current position. When joining a software project, there is usually some existing software that needs to be extended or improved. Even when you are working on a greenfield project, there is typically some existing process or other software that needs to be integrated or otherwise accounted for. In other words, the existing IT landscape plus some established work processes are the starting point of your project.

Now, let’s translate this concept to some specific actions that you can take to avoid running into this trap:

• Find out how current processes work. Talk to business experts and people working on the daily business. Maybe someone can show you their daily work while you are watching and asking questions.
• Examine existing software that shall be extended, improved, integrated or replaced. Yes, even when you replace something, you should look at existing solutions. Read important code sections and ask questions if associated developers are still accessible (often they are no longer available, though).
• Check for available documentation about existing processes and software. Read it carefully and consider asking questions based on that. If documentation is missing or outdated, strongly consider updating it yourself when you gained some knowledge on the topic. This deepens your own understanding and makes it easier for future engineers.
• Read test cases for existing software. Since documentation is often missing or outdated, tests can be a more reliable alternative that tells you about desired behavior.

Always know where you are coming from before you head off towards your goal. Otherwise, you will run into a direction that leads you nowhere (best case) or even does harm to the company that you work for (by wasting resources, creating more work etc.).

What has been your experience with finding out your starting point in a project?

Note: You can also find this episode on YouTube and Spotify.