Software Engineering best practices we do ‘Not’ follow at our own risk

Software engineers all over the world were at some time or the other taught in their initial days some best practices to treat as the Bible while developing software and writing codes. But most of the time, we fail to undertake these steps. Due to lethargy, or time constraint, or taking things too easily, we skip the so very essential part of the best practices which can lead to some immense trouble and loss to others in the future. We will be discussing some of these serious issues now. And how we can focus on fixing our habits.


Often we will see Oracle, Java, Unix or for that matter codes written in any technology, often named without following the convention and reveals little about the utility of the piece of code. A coder when looks at the file in the future will have little or no idea as to what it was written for until he goes through each an every line of the code. Imagine the amount of time lost for the simple task of getting to know the functionality of a few hundred lines of code. Always include at least a few words of comment for each code block, naming conventions,  snapshot of the code (with the author name, version history, purpose). A few seconds taken by you will save many people in the future from putting their brains out to figure out the purpose of a code.

Software Engineering Best Practices
Software Engineering Best Practices

Development Team in UAT

The role of the development team should be up to code delivery and implementation. At most, they can guide the user how to proceed with the testing. Rest scenarios should be entirely left in the hands of the user. For obvious reasons, if the developer is involved in his own work, he is bound to influence the testing scenarios of the user unintentionally on a subconscious level. This is not to blame anyone, but something pretty natural by human behavior.

Allocation of due time for each phase in SDLC

Each of the phases in SDLC must be given due weight and time. It often happens due to strict timelines, the analysis and design phases are shortened. But this can lead to severe consequences as the solution approach might prove to be unsustainable on the long term. All sorts of feasibility, cost, adaptability, flexibility study should be completed with proper discussions and brainstorming which will also benefit in team-building.

These practices need to be strictly followed by budding engineers and experienced professionals alike. It’s ought to be like the untold rules of software engineering.

Author: Rahul Bhattacharya

Rahul is a journalist with expertise in researching a variety of topics and writing engaging contents. He is also a data analyst and an expert in visualizing business scenarios using data science. Rahul is skilled in a number of programming languages and data analysis tools. When he is not busy writing, Rahul can be found somewhere in the Appalachian trails or in an ethnic restaurant in Chicago.

1 thought on “Software Engineering best practices we do ‘Not’ follow at our own risk

Leave a Reply