Demystifying Software Engineering: Being Approached to Build a Feature or Tool (Part 1)

Part 1: The Ask and The Detective Work

About Me

I’ve been working in tech for about seven years now, mostly in the hardware space as a test automation engineer with a sprinkling of devOps, tooling and web development. I’ve worked for companies that make smartwatches, smart locks, and robotic toys. 

Who this series is for

The aim of this series of posts is to help demystify what it’s like to do software work and tasks in a professional environment. There won't be any explicit explanations of how to apply software techniques, these articles are more generally about how and why you may want to use a software technique or approach. Most importantly, I hope to highlight how important the non-technical side of things are in software engineering.

People discuss the technical side of working with software but often neglect the importance of soft skills. But, assuming a baseline of technical competency, soft skills are in my opinion one of the most important parts of working in software.

So, who is the audience for this series of articles?

1. Anyone who has dabbled in software and is thinking about doing it as a career
2. A junior engineer just starting out and looking to learn what to expect

In this first part, I’ll be going over the following:

1. Introduction: Data Storage and Data Usage in a Company
2. Being Approached for Technical Help
3. How to handle the first ask
4. Requirements and information gathering from the requester

Introduction: Data Usage and Data Storage in a Company

Dealing with data is an important part of any company. This could be something as simple as test reports in the form of text documents or nicely formatted HTML files for viewing in a web browser. It can also be audio, video, large data sets,  or even sensitive information about customers that requires strict security measures.

What these all have in common is that you need a way to both store and access them. 

A common scenario that I’ve run into in my career is dealing with test results from past, current, and future test cases being run across the company. Oftentimes, these test results are more of a “This works!” or “Oops, your last code change caused a fire,” and they only temporarily stores results for reference. 

There were times though that we’ve wanted to store all our test results, so we can refer to them for data analysis. This was more relevant for performance tests rather than unit or functional tests. 

Now that we’ve set the stage for data usage, let's dive into the main focus of this first part of this series: being asked for technical help (features or tool request). 

Being Approached for Technical Help

You’re a developer for a small company (30 employees) and are approached by the testing department asking for your technical help. Here is their initial ask:

“Hey, so we've been running into an issue with our workflow. We run automated tests whenever code changes happen and normally we’re notified through Slack on the test passing or failing. The tests are all run through an automated system (Jenkins) that handles running tests on code changes, temporarily storing the results, and then letting the user that made the code change know the pass status. This notification also gives a link to a nicely formatted test report that they can quickly refer to.

The issue is, our machine that runs these tests doesn’t store more than 50 reports at a time so we’ve run into the issue where we wanted to compare old results but can’t.

Is there a way that you can help us store these reports in one place, that we can all refer back to? Could we also have it organized so that we can quickly figure out which tests we’re looking for?”

This initial request could be a casual ask that is pretty descriptive but still leaves quite a few questions. Your job is to help clarify with them what they need vs. what they're asking, and to see if it's possible to accomplish the task.

How to handle the first ask

The way I normally approach this situation is to first remember that my job as a developer is to create a solution that is not only possible, but also something they’ll be happy with. 

Usually, the first ask is not thoroughly planned since that takes time and expertise on something they may not be familiar with. It's also not really their job to have a fully outlined plan in a field they’re not necessarily familiar with. 

My job as a developer is to ask questions to help narrow down what they need in order to accomplish what they’re asking for. I also need to ask questions to get a better idea if I can even do what they’re asking for when factoring my workload and budget. 

This is pretty important to keep in mind, because you don’t want to waste time on a project that you’re not able to finish due to budget or time.

From the developers perspective, you’ll probably be worried about the following:

1. When does the requester need this by?
2. What budget are they working with?
3. Do they want a one off solution that they can maintain themselves once I create it?
4. Do they expect to add on to this in the future?
5. Is the information they’re dealing with sensitive?
6. How many people do they think will have access to the data?
7. What is the data like (size, type, how often produced)
8. Are they more concerned about the data storage or the data usage? Data storage would probably need to be done first and data usage can be the more complicated ask.

Answering these questions will help narrow down how you can approach designing this task for them. On to the follow-up talks!

What the first discussion may look like

Now that you’ve come prepared with your questions, you organize a discussion with the requester. This could be a formal meeting or just a casual conversation, it really depends on the work environment. 

Either way, you’re definitely going to want to document everything! This is to make sure everyone is on the same page and that there is a paper trail, which ends up benefiting both sides. 

Here is the conversation with the requester:

“Oh wow, I didn’t think about all of that! Well, we’re a small team of 4 and so we think it’ll just be us accessing the reports. Let's just say it will only be us using it and no one else, though we would like the nicely formatted reports to be internally available if we send a link to someone else. 

Our budget is pretty tight and we would need approval from management, so maybe you can give us rough estimates of what prices to expect? 

Also we would like to administrate and control the data, so a system that allows us to manage it would be perfect so we don’t have to keep coming back to you for changes or help.

As for usage, for now we only need to store the data and retrieve it, we’re not too concerned on the data analysis part.

For the data, they’ll be roughly 5 MB each, and about 100 tests will be run each day. We do think the amount of reports will increase depending on how many new developers join the company but to be honest we’re not sure.”

Based on this conversation, we’ve already narrowed down the ask! This is pretty important because it gives you a much better idea of how to approach the problem, making sure you’re providing your customer with exactly what they need. This will make both sides happy and save time in the long run. A win win!

I think this is a good cutoff point for Part 1. If you’re interested to see how the rest of the story unfolds, look out for Part 2!