Every engineer/developer has the right to do their work the right way, not necessarily the easy way.

There are a lot of reasons a software fails to serve its intended purpose. But most of them could be avoided if we implement the so called good practices into the software development life-cycle.

No matter you are making software as a product or for a client, you have to have a clear understanding of the end-user needs. Significant man hours have gone to waste and so have many applications built during it just by failing to understand the same. The end-user or client needs cannot usually be determined by one single meeting. It requires good research and understanding the problem statement first-hand. Then and only then we could try and solve the problem more efficiently.

“Slow and steady wins the race”. Sure, you could actually make the software development process much faster, but usually at the expense of compromising some vital steps. The applications developed skipping these “non-essential steps” might sooner or later become a big problem. It might be true that you could save the time and resources while building it in the first place. But, when (not if) it comes back with bugs, it will cost you more of both.

There is usually the need to upgrade and maintain a software as time goes on. Whenever you see the need and have the chance do not hesitate to refactor the code. Refactoring will usually help create a code base with increased readability, smooth execution, less bugs and higher performance.

Your primary focus should always be achieving the desired functionality. It doesn’t matter how better the design or how fast the response is, if it cannot produce appropriate output, that software is useless and a liability.

Do not wait for the software to grow beyond a certain size to incorporate version control applications such as GitHub or bitbucket. It is always a good practice to create repositories from day one. Create branches and maintain it responsibly. My method is to always keep at least three branches even for a single engineer. One for release, one with the latest stable version and one for the working copy. Any method would be good as long as it helps to keep a backup as well as a smooth workflow.

Disclaimer : The views and opinions expressed in the article belong solely to the author, and not necessarily to the author's employer, organisation, committee or other group or individual.