Do's and Don'ts in Software Development

In this post, I like to share the do/don't a checklist for the software application development, these are actually best/worst practices I facing every day in my software management career.

Which some of them I learned in practice, some of them I found in blogs and articles, proven and tested practices so In this post, I wrapped up in all of them. IMHO of course.

Let's get started;

Do's
Upfront
 

• Gather all required materials up-front.
• What's more, is that all the requirements must be explained as clearly as possible.
• Start with giving a thought to it after understanding its functional, user interface, integration, and nonfunctional requirements. This would give you a better perspective on how finally it should look like.

Architectural

• Try to break down it into smaller chunks and come up with a design for - small components.
• Do not use hardcoded strings in code.
• Do not write boilerplate code and reinvent the wheel.
• Don't develop code if you can't maintain for mid/long term.
• Do not think about premature optimizations.
• Don't forget to documentation, write code descriptions. If you are using company Wiki (i.e Confluence) this is better.
• Avoid over-engineering, over design.
• Deploy small, deploy often is crucial.
• Always keep it user-centric.
• Make a decision from the start, follow them
• Always think of multiple designs for a requirement.
• Test, Test, Test. Thinking about different unit test scenarios helps in understanding & imagining the various real-life scenarios and how this design is going to handle them in a production environment if that scenario arises.
• Take refactoring tasks to avoid technical debt.

Design 

• Follow KISS (Keep it simple, silly) principle while writing code.
• Do you have a difficult time finalizing decisions? Keep it simple, understandable as possible.
• To avoid confrontation to the point of making extra work for yourself or others.
• Do you have trouble saying no, even to tasks that detract from your core responsibilities, say no?
• Always take time to carefully consider every aspect of potential projects; try to break smaller tasks.

Environmental

• Consider running time environment situations; thread-safe operations, parallel execution, server topology, number of hops/point of failures, server date/timezone considerations, memory requirements, server/database settings, number of concurrent users, etc. Your code must be well configured for the test, pre-prod and prod environment to execute well, you need to handle well in different environments.

Scrum

• Do when new tech inevitably sparks off new ideas and improvement opportunities, it would be better to keep such process revisions out of the Sprint sessions and addressed with the business process owners. So when user stories from the have initial feature set, high-level requirements and expand them through design.
• To cross-validate the user stories with different stakeholders.
• Rationalize and prune. Park the shortlisted futuristic requirements for a later Sprint.
• To start with well understandable, well-defined tasks must be taken first. In the Scrum framework, the team gives a rough software estimation. Only for the first two iterations, the team can make more or less accurate predictions. Also, in the beginning, it's common that even clients don't know what they want from the development. The details of features aren't still well-thought-out, so it's almost impossible for the team to accurately predict software estimation under such circumstances.

Don'ts

• Don't create for yourself.
• Don't start unprepared before starting to project.
• Don't change suddenly
• Don't set inaccurate estimates, time expectations for complex features.
• Don't start coding right now, first build a "Proof of Concept" but the end of completing most of the coding.
• Don't skip documentation
• Don't overcomplicate. Never ever complicate design for addressing rare complex scenarios. complex requirement scenarios will always be for every feature and don't try to address each one of them.
• Don't skip the coding convention guideline.
• Don't be so optimistic. Software engineers are chronically too optimistic so Usually, anything unforeseen slows things down.
• Don't keep user stories open-ended and liable to multiple changes during the Sprint.