The Rarely-Mentioned Side of Software Development
Programming is the easy part
I recently had an experience where I spent half a day implementing a certain feature and changed a bunch of things in the codebase. There was one test case I was struggling with and I asked my colleagues for clarification.
At which point I discovered that the majority of the logic was completely unnecessary because I had made the wrong assumptions based on my interpretation of the feature.
Cue sad music.
Had I only taken the time upfront to test my understanding, I could have saved a couple of hours worth of work.
It’s the Assumption of the Developers That Goes to Production
I was reminded of this incident during Alberto Brandolini’s talk at Domain-Driven Design Europe 2020, when he said:
“It’s the assumption of the developers that goes to production.”
This really hit me.
As software developers, we should not only know how to program but also have enough knowledge of the domain to program the correct thing. Ultimately, it is our understanding that is reflected in the code we write.
I’ll be the first to admit that, on occasion, I’ve only read the title of the task I was about the implement, made the changes, and made the pull request. This works sometimes for the small features and bug tickets, but when it comes to implementing bigger features, this doesn’t work at all.
If you’re lucky, the wrong assumptions will be caught during the pull request. If you’re unlucky, it will be caught during QA or even worse, during the application review.
Now, it’s not just a matter of going back and correcting your assumption, but creating a new ticket and a new pull request. Wasting everybody’s time and potentially having to rewrite the whole feature.
All because of an assumption based on the title of the ticket and a discussion from a month ago during refinement.
While actually reading the acceptance criteria can go a long way towards avoiding the above scenario, product owners and stakeholders are people too. We all make mistakes or think some things are obvious. Acceptance criteria can be incomplete.
So, as software developers, we should keep this in mind and ask whenever we venture into uncharted territory, even if it doesn’t feel uncharted.
Avoid Jumping Over Where the Fence Is Lowest
It is very easy to focus on the technical solution because that is what we, as developers, know and understand.
Setting up a microservices architecture with all the bells and whistles is cool. Calling all the microservices to get anything done — not so cool.
So, even if a solution is a technical feat, an art piece of the latest and greatest technologies, it might fall completely short of the goal.
I once helped oversee an exam for a Python course. It was the first time the exam was digital and the application for it was seriously cool. This application had a built-in shell, automatic grading, and was deployed in a Kubernetes cluster.
It was beautiful. Until 400 students had to sign in and use it at once.
Thirty minutes went by before all the students had logged in. Answers weren’t saving and there were issues with the sessions. It was a nightmare. The system that was supposed to save us time with grading ended up causing grades to be delayed for weeks.
The complexity of the application made it completely unpredictable under heavy load and ultimately caused it to fail to live up to the main requirement — saving the exam and grading it.
Taking the time up front to make sure you are actually fulfilling the needs of your user could mean the difference between a successful application and a failed one.
Knowing the domain might sound like the job of the product owner or whoever comes up with requirements.
However, you are not a code monkey. You don’t consume requirements and return code. It’s your responsibility to ensure the code you are writing is as correct as it can be.
While you might never have the level of knowledge a domain expert will have, you could know enough to spot wrong assumptions in pull requests or are able to make sustainable infrastructure decisions.
So, talk to your domain experts when you stumble upon something that makes no sense to you. Ask why the acceptance criteria have to be fulfilled like that. Who knows what you’ll find.
Remember, there is a lot more to software development than writing code.
Thank you for reading!