As a senior developer I often see the same mistakes while I’m reviewing things like systems, processes and code. In this article I will try and explain some of them and the mitigations you can put in place to help avoid these things from happening.
Focusing only on the happy path
Often developers, due to a number of factors such as tight deadlines or poorly planned tasks, focus far to much on the happy path. The happy path is the simple code that is needed just to make the feature work.
A good example of this is when a component relies on an API, the feature works fine when the API is working but as soon as the API is down or returns something unexpected the component then doesn’t fail graciously.
What can you do to avoid this?
Well it all starts in the design stages. As a developer when you are given or take a task as part of the investigation stage (pre coding) you should always plan about what could fail and how you want it to fail. You can also use processes like SFMEA ( Software Failure Modes and Effects Analysis ) as a systematic and proactive method of evaluating possible failures and how you will mitigate the issues. SFMEA has a scoring mechanism to help you prioritize what work you should do first. Look out for my SFMEA process article coming soon.
Common points of failure are
- API calls
- Interfaces to other functions
- Database connections
- Input boundaries ( eg. Max Min Values )
- IFrame endpoints down
I Will be talking specifically on the happy and sad paths in the future so keep an eye out for that.
Poor time estimates
Its often said that however long your developer says it will take, double it and add them together. That’s because as a whole us developers, especially early on in your career, are not great at estimating how long tasks take to fully complete.
As mentioned above if the developer does not think about the unhappy path QA can reject some of the work back to the developer or worse it doesn’t get spotted until the end of the project. Often developers wont consider any other area of the team while planning the work, just thinking about what functions they may need to write.
Story pointing from the SCRUM methodology is a great way that project managers can still get a good project estimate but removing some of the difficulties developers have in estimations. A high level overview for story pointing is that developers as a team will estimate the complexity of a task in story points. After a while of working together the team will work at a known velocity, this then allows pm’s to estimate the duration of the task.
Code ownership
Another common mistake is that people end up as code owners. This is fine when you have access to that resource but it can quickly cause issues when planning new work or if that developer was to move to another team.
Another issue with code ownership is that other developers may feel like they cant modify or rework those areas of code, meaning important potential fixes or enhancements don’t go into the project.
A good way to avoid code ownership is to run teams in a pair programming setup. This means you will always have at least two developers who can be responsible for a set of functionality. Another good way is during planning sessions try not to continually work in the same area, be proactive and don’t pigeon hole yourself into a particular, it will also help in your personal development and make you a more desirable developer to the team.
Lack of business knowledge
Developers can often fall into the trap of having a single vision about the functionality without having the business knowledge to back it up. If you want to develop great functionality first time you cant rely on just requirements or initial discussions with a PO ( product owner ). Go and spend some time with your customers or other people in the business who know the customers well, really learning the business and how people actually use your products.
Categories: Developer Chat
greenchapel.dev 
Leave a Reply