Documentation

For me, documentation starts from day one. What will happen when I am not there with the project. The documentation will save. I create the documentation covering all functional and technical aspects of project in such a manner that novice developers  are also able to contribute immediately. Of late I started doing documentation in form of github project website.

Business problems are generally complex. So their solutions tend to be complex. But I try to create simple solutions for complex problems. Sometimes I do extra hours just to make a working solution simpler. Simplicity helps others to easily connect with the project. It improves scalability and adoptability. Its simple to make complex  but difficult to make simple.

Separation of concern

I make it sure that each component in the software takes care of single artifact. I avoid if then else statements. This way the software becomes more understandable and easy to be followed by others. Believe me, great programmers are those who make the lives of other co-programmers simpler. Separating the software components with one component taking care of a single concern may appear daunting initially, but it pays in the long run.

I have seen that this is the most neglected area by novices. I come across in code with meaningless variable names and a mix of Pascal, Snake and several naming conventions. That is biggest mistake we do. I strictly follow naming conventions suggested by the aouthors of programming language and always use meaningful and well spelt variable names. That way my code appears like prose and I get rid of extra burden of commenting.

POC the proof of concept

Before starting a software project I always create a proof of concept (POC). This is in fact the validation of logic, algorithms and code which would be used in actual project. Spending time in POC is worth it. You know beforehand what is not going to work and you can take corrective actions timely. Keeping a separate timeline and budget for POC is a good idea. Never jump on to development phase without doing POC and research. Doing POC is a must for modern projects.

After the delivery of a software project, the vendor keeps the project on maintenance and the client readily agrees for it. In several cases I have seen that maintenance is an eyewash for clients. Ideally the maintenance should take care of  upgradation of code and fulfillment of new light weight requests from client which can be accomodated with minimum of coding. But in reality many companies finish the incomplete work and do bug fixing during maintenance. I hate this practice and do not follow it.

Research

Due to strict timelines, people tend to jump-start the project without proper research. The result may be that you end up overshooting the timeline with an inferior quality end product hungry of maintenance. In today’s complex environment there are plenty of libraries and several ways to accomplish a task. The research only tells you the optimal way to go. A proper research yields savings for tons of hours and a happy customer.

Robust algorithm design is a must for a healthy project. I spend proper time for a good algorithm and programming logic. With proper logic and well designed algorithm you can reduce hundreds of lines of code in few lines. As an example a novice programmer would create differnet API endpoints for each of insert, update, delete and read operations. But using a carefully designed algorithms a single endpoint can handle all the operaions.

Follow a framework

I always research and find out what are the frameworks available to perform a programming task. I check github stars, number of downloads and users’ feedbacks for several frameworks. Then I test them myself and select out a single optimized one and adhere to that framework during the lifecycle of the project. In case I do not find any, I create my own framework and stick to that.

When I start a new project, I create a lab project in parallel. The purpose of lab project is to check various code snippets in a separate simpler environment without polluting the actual code environment. Sometimes I simulate critical bugs in the isolated lab environment. In absence of other project complexities I can  rectify the bug in the lab environment much easily. Then, I put the antidote in actual project environment. It works great.