The minutia of your software development process is problematic. It wastes time under the guise of being productive or enhancing the quality of the software. Unfortunately, many developers personally identify with certain designs or tendencies. This causes them to defend their position while not recognizing or realizing that it doesn’t matter. Here are
some of the most common software development details that may waste your time.
1. Arguing Over Coding Style
I’m not saying coding style doesn’t matter. I’m stating that I’ve seen a lot of time wasted over coding style that can be avoided. On top of that, some of the style arguments don’t matter. For example, in your software development process, you’ll inevitably write if-else statements. A shorthand way of writing if-else statements is through a ternary operator.
Here is a basic if-else statement and a ternary statement:
I’ve seen developers waste hours of time arguing over using ternary statements or not in code reviews with the most hard-core stances being that no ternary statements should ever be used. The rationale is that they can become confusing if they are long, people misuse them, it’s better to just use one standard, and I could go on. After 15 years of software development experience, I rarely see a meaningful impact on using ternary operators or not. Systems haven’t required major rewrites for this type of logic. Going over them in code reviews or taking hard stances is a waste of time. Fix these types of issues quickly with a linter on your IDE. Just agree to adhere to the linting suggestions as a standard and be done with it.
2. Custom Code Instead of Libraries
Developers love to write code or we wouldn’t be doing what we are doing. However, there is no greater waste of time than writing code that already exists. Using a simple library import is much easier. This seems straight forward but you would be amazed at how many companies create their own queuing system, custom database migration/management infrastructure, or simply create code libraries that already exist. To create business value and get things done quickly you need to be able to build upon and extend that which exists and not re-create the wheel.
3. Not Writing Automated Tests
While writing tests takes up additional developer time, it has great payoff for the longevity of your software. Tests for complex business logic is especially important.
I worked for an insurance company as the team lead in the claims division. Insurance companies work with deductibles and verifying if a customer meets the requirements. The deductible calculation with all of its logic took into account: if deductibles are met, the policy type, and if a refund or payment was made. This ensured that calculating the deductible on an account was extremely difficult. The company constantly had issues with miscalculations. Some of these calculations would be off by millions (yes, you read that right, millions of dollars). Manual processing would catch most of these, but inevitability some would slip through. The problem was no automated tests existed. Our team set out to write all the test scenarios we could. In the end, we had about 40 different scenarios to handle the deductible calculations.
The time we spent on writing tests, which ensured we didn’t break logic as code changed, was invaluable. The amount of time we saved for the company as a whole moving forward was tremendous. If you are not writing tests for your complex logic, you are doing yourself and your clients a disservice. The effort to maintain and handling changes in the future will be extensive.
4. Building the Wrong Feature or Product
So this is not inherent to the coding itself but it’s so important that it needs to be listed. It is integral to verify that you’re building the right product, otherwise, you may release a product that no one wants. Miscommunication on what should be built from the developer perspective versus the business perspective is also a common problem.
You may have beautifully crafted code and designed the most scalable system in the world. However, if no one is using your software, you just wasted your time. Not only is it a waste of time but it’s highly demoralizing to everyone involved.
You can ensure you are building the right thing by creating quick prototypes that validate your assumptions. Marketers have done this for years but software is late to the game.
5. Unnecessarily Complex Code
Simple is good. Simple is fast. Gold plating code or writing code that is far more complex than it needs to be to handle fantasy scenarios is a waste of time. Developers need to realize that they won’t be the only developer working on the code. Oftentimes, more inexperienced developers will need to work on the code. Therefore, the code has to be readable and easy to understand.
Depending on the language, code can be very terse. The code might not have parameters with types and return objects. Code methods have multiple responsibilities and thus are likely to be named incorrectly. If you have to give your method a 50-word name to let people know what it does, you might need to refactor.
Most people aren’t wasting time on purpose. Unfortunately, the items above can give a developer the illusion of making progress or doing something important. Unfortunately, it’s actually wasting time. Retrospectives where developers can openly discuss issues and discuss the quality and brevity of code reviews are a great way to find solutions and to ensure your software development process isn’t wasting time.
