Your application didn’t go down because of a bug.
It went down because an unsupported developer checked in code without going through code review in an area of the codebase that wasn’t covered by unit tests because the project was running late because it was under-scoped.
If you’ve worked on a digital product, whether as a product manager, engineering manager, or business leader, you know that the most common problems in software development are rarely as straightforward as “bugs.”
While the surface-level problem might be something like a bug, the root of the problem is closer to the story told in the quotes.
The software development team at DEPT® has worked on hundreds of digital products, and we’ve seen all the common (and not so common) problems that plague software teams. To save your project from a similar fate, we’ve decided to share them with you so you can avoid common pitfalls and have a great product with less time, money, and headaches.
The good news is that because these issues are so common, they also have solutions that are relatively simple to implement. The bad news is that simple does not equal easy. Many of these solutions are difficult to implement when considering budget and resource constraints. Regardless, we’ll lay it out.
Here are the most common surface-level problems in software development, and typically why they happen.
Problem: bugs, broken code, & technical debt
Why It Happens: Under-Scoping
Under-scoping is most often the cause of bugs during software development.
If the project wasn’t properly scoped from the outset, with an appropriate amount of time allotted for each stage, then your developers may start to cut corners and work in a rush to keep from falling behind schedule.
This is when semicolons start to go missing from the code or code gets checked in without undergoing the required code review, leading to application crashes and bugs galore.
Solution: Plan realistically, not optimistically
A lean development approach is typically helpful. Set short, achievable milestones, and validate that you’re going in the right direction. Then iterate. This approach makes it harder to put together a complete plan, but you can be more confident in the accuracy of your estimates in the short term.
Another way is identifying upfront which features are only “nice to have” and can be cut if you’re running up against a deadline.
Keep in mind that the “slow” way is often the fastest and most efficient way since hastiness invariably leads to a technical debt that will have to be made up later on.
Treating a problem at the source is much more effective than addressing a symptom. Take the time to consider what the root of the problem is—whether it’s a lack of time, skill, or oversight.
This will yield huge savings in time and effort over simply hiring more developers.
Problem: premature optimization
Why It Happens: Lack of strong code review process
Speed is too often treated as the highest good when it comes to code, at the expense of code that is clean or legible. It’s a common pitfall for developers to focus on writing optimized code that runs fast rather than code that can be read, understood, and maintained over the long term.
Hard-to-read code can slow your team down, particularly when engineers come and go. If an engineer comes in and can’t decipher code, you’ve suddenly got a big problem.
Premature optimization most commonly happens when there isn’t a strong code review process. Without this essential step, things get messy and cause problems down the road.
Solution: Have a strong code review process
A good code review process will ensure that the code is understandable, follows guidelines, and can be tested/debugged.
As for optimization, don’t worry about optimizing all of your code. Keep in mind that an application generally spends 90% of its time running 10% of the code. Once you know which 10% of the code that will be, you can focus your optimization efforts and prioritize legibility over speed in the rest of the code.
Problem: complicated new technologies
Why it Happens: Lack of Senior Leadership
Developers are drawn to hot new technologies. It’s no surprise. Tools such as AWS Lambda (that promise increased efficiency and flexibility) are exciting!
They can be great once you’re proficient with them, but it takes time to learn how to set up and test these new technologies. Plus, it’s like learning a new language. Once you progress past the basics, a little more nuance is required, and that can be time-consuming and challenging to navigate. An area where this issue plays out frequently is databases.
The root problem behind this is typically a lack of senior leadership. Software teams need engineers with experience. Those who know that new isn’t necessarily better.
Solution: Prioritize senior leaders
Senior leaders can mentor your less experienced engineers and encourage them to stick with proven tech (at least for now). They’ll be more likely to recommend familiar tools such as PostgreSQL or MYSQL. These are predictable entities that get the job done.
Whatever feature in a NoSQL database that caught your attention is probably not essential to your project. It’s a nice-to-have, not a need-to-have, and it probably has some limitations that you’re unaware of.
Problem: too much (or not enough) abstraction
Why it Happens: Either not understanding the problem domain or you’re paying developers by the line of code
Running your entire application out of a 10,000 line index.js file is a recipe for disaster, but going to the other end of the spectrum with 10,000 one-line files is also a bad idea.
Solution: Find a happy medium
Striking a balance is the way to resolve the abstraction issue. You want to aim for an approach that prioritizes code that is understandable and maintainable.
Problem: overlooking the little things
Why this happens: Again, underscoping
Let us reiterate. Underscoping a software project is one of the most common and detrimental mistakes people make.
Some of these little, overlooked things is a failure to cache or CDN static assets.
Another is not adding the appropriate indexes to your database. These whoopsies can have huge performance implications, and they almost always come down to scoping problems from months prior.
Solution: Scope properly
Here are three tips for better scoping:
- Involve a senior developer in the project scoping process. They’re more likely to remember all the little details than a PM or PO (who will be focused on features).
- Keep track of what was missed in your last project. Use that list as a checklist for your next one.
- Understand that a project doesn’t end when it is “released.”
One silver lining to all the little things we overlook is that they’re usually not a part of the “core” of the project. A cache or a database index can always be added later, and budgeting to keep a developer engaged with a project after a release is a good way to clean up all the little details.
Bumps in the road are inevitable when you’re building a digital product, but knowing the common pitfalls and the steps to prevent them can help.
If you have already fallen to one of the common software mistakes, our advice to you is to take your time getting back on track. Trying to increase velocity when behind schedule is a recipe for disaster.
