I Get It Now. I’m a Software Developer Miner
Photo by Zbynek Burival on Unsplash
Most software developers like ‘greenfield’ projects where they can implement new features. Instead of focusing on legacy systems and integrating with someone else's past decisions, we can focus on the future.
“I have to say that isn’t what I’m doing in my current job. I’m a miner and I hate it”
This article is about exploring the current situation, and seeing what we can learn about The Secret Developer’s current workplace and how this might change over time.
The Trash Situation
“I get told to work on ‘new’ requirements and add to parts of the codebase that have not been touched for a half-decade.
The ACs for these requirements might be to create new functionality that ‘works as before’ but while looking at legacy code it is hard to extract how it did work. Sometimes that previous behavior is actually incorrect and just hasn’t been previously picked up by our testers.
We don’t have unit tests. So, I do what I can, documenting the requirements and then attempting to get sign-off while the ticket is in-flight.”
You may or may not be familiar with such a situation. We can lay some blame on the developer in this type of situation as they need to be working with the team to make the situation better.
Here’s a checklist to make things better:
Raise issues at Sprint retros
Do not start work on tickets that are not ready
Work with the business to find those requirements, even if they are stored elsewhere in the business
“Let me put it another way. When you are in a dev job where the attitude is ‘get it done you resource’ there is no real room for negotiation.
You’re not a peer of the business team in my case. The product owner ignores my Slack messages for a day or two at a time so what exactly are you suggesting I do?”
This can come down to the capability of the team as a whole. If an autonomous team is not capable of creating work with requirements and success criteria it might be worth thinking about your future within that environment. However, in most real-world situations it’s almost always better to work with your team to make your current gig better.
The `Perfect` Resolution
A study by Rayson, Garside, and Sawyer from Lancaster University can help us think about what is really required to mine existing code for requirements.
The fact is it should not be the software developer’s responsibility to do so as we are thinking about business change here and it should be about the team improving their performance and moving to a high-performance environment.
Useful information is oftentimes locked up in documents and in the collective knowledge around the organization. Business change in itself can lead to people with pertinent knowledge learning the company naturally causing an information vacuum.
If we can arm Agile teams with tools to help explore the documentation and reconstruct the model of the business that motivated the work of the software, we could move forward in getting engineers to do what they do best. That is converting software requirements into working software.
Coming down the pipe (as covered in the paper) is a set of probabilistic NLP tools to work through documentation and extract those requirements.
“It can’t come fast enough if you ask me”
Conclusion
The Secret Developer isn’t the only one in a situation where they are expected to create software without proper requirements. If this is happening to you now is probably the time to do something about it.
“If you have time to build software you have time to make the process better (said no tech firm ever)”