.png)
In the Expectation Management chapter, we'll walk you through what to expect when undertaking an outsourced software development project. Many of the scenarios we'll discuss will arise whether you're outsourcing, contracting locally, or building in-house.
Welcome to software development, a world where hiccups are expected and bugs crawl around. Writing code is no easy task, and in doing so, you will face bugs (think of it as glitches for our non-techies out there).
No matter if you go in-house, domestic dev shop, or offshore freelancer, this will happen. Bugs are a fact of life of software development, and even the best code is not bug-free.
What matters here is how you handle bugs. When bugs are discovered in your testing or your developers tell you that something is taking a bit longer because of bugs, that is okay. The most important step here is making sure that anytime a bug is recognized, it is acknowledged and worked on.
For the developers, they'll do this inherently. For you, as you test the product and find new bugs, you need to address them and let your developers know right away. Here is the structure we use in identifying and logging bugs for our developers:
Explain what the bug is, don't be afraid to be too detailed. Screenshots or screen recordings are always welcome.
Be specific in retracing the steps to replicate the bug; this will be really important to make sure the developers find the bug and squash it quickly. The golden rule: if the developer can't reproduce the bugs on their machine, they can't fix it.
This helps the developers know how to prioritize their work - some bugs are small UI fixes and don't take precedent. Other bugs might crash the system and should be high priority for your development team to fix immediately.
This is the magic question. We put this on all bug submissions so you can specify whether you believe a bug is in scope or out of scope. If you think it's something that was caused by the current team and is within the scope of your project, then you can say it's in scope to let your team know you expect them to fix it.
If you just now discovered a bug that was leftover from your previous team, it's a good idea to let your development team know it's out of scope. This tells them they likely weren't responsible for the bug. Although they might not have created the bug, chances are your development team may opt to fix it anyway, or submit a change request to adjust the scope to include the bug.
Ultimately deciding whether or not a bug is truly in scope can be a difficult subject. Developers have a joke to the tune of 99 bottles of beer that goes: 99 little bugs in the code, 99 little bugs. Take one down, fix it around...127 little bugs in the code.
It's a silly joke and not meant to be serious, but like all good jokes it's based on truth. When writing software, it's possible to be working on something and affect or break a completely unrelated part of the product. There are often many references within the code base to other parts of the code and it can be difficult to keep track of all of them, so fixing one bug may introduce more.
If this happens, be patient with your development team and don't be too quick to put the blame on them if bugs come up. Provide all the information you can on the bug and work with them to find the root cause of the issue.
Running a business is hard,
Software development shouldn't be ✌️
