Finish it, release it, and do not try to be a God while developing your application

Small introduction, I am Chief of software engineering for the customer experience platform in #Nordea, and I have been a programmer for 12 years professionally, so I have this self-belief that I know a thing or two about software engineering and system design. I have also been mentoring software engineers for many years, mainly in the areas of code quality, reusability and reliable releases.

In this article I thought to address two specific issue from coding prospective I have seen time and time again by new software engineers/programmers. I though to take you though my opinion and mentorship in relation to these issues. I will not go into too much details but only highlight the issues, and suggestion on how to improve.  

These are the two main issues which I have noticed

• Developers start taking care of unplanned features in the same way as the planned features
• Trying to solve each and everything which can ever go wrong in the application

 You see no software is a complete solution to all the problems in the world. They are designed to solve specific problems through features. While designing a software, there are features which are developed on purpose to serve the business needs according to the business cases, and then we have non planned features which get created as a consequence of implementing the planned features, but a developer have to focus on the planned features and not concentrate on the unplanned ones, because they are not really the focus. While developing, the team of engineers should be focused on the main features, which will make the software capable of covering all the business needs, and this should be done through an Agile way in a continuous delivery fashion, with the minimum viable product (MVP) already agreed with the business. Then there are features which are un planned. These are not the focus until they are interfering with the planned features. This is very important, because if the team starts taking care of unplanned features, it will cost the project more money and time for the over all release, and the product might take much more time to finish in each iteration.

The second issue is when the developer start behaving like a God and starts taking care of each clause which can get an application into an exception, this is not the right approach. You see you should not prevent an application from getting into an exception, you should at times not even handle the exception if it is not needed. What you should really concentrate on is that the application should not crash, and the show must go on. Remember this is a mindset, not a solution. If it is necessary to take care of the exceptions to stop the application from crashing unexpectedly? than do it, I am not advocating for never handling exceptions, I am suggesting to not to be overly possessive and handle everything which is not necessary. It is totally alright for an application to complain in the log files for unhandled exceptions if this doesn’t crash the application and the show goes on. Also there are several cases of how and when to handle exceptions, i would also recommend to go through some literature, and learn about the best practices.

These two points I have shared above are from experience and self-mentorship through reading and following trends. I would like to have your comments on how do you think? After all we are all learning from each other.