How do you share best practices for software development?

Start with the thinking that there are NO "best practices" in development work unless they are so abstract as to give almost no guidance; as in: "it is best to address <topic> somehow or other". Instead, use the term "good practice" and make it a habit to say in which contexts it is good practice. Anything that genuinely IS "best practice", universally, can be automated and probably someone already has. Development work happens in the mind; it is thinking work. The term "Best Practice" is dangerous; it says "you don't need to think about this; just do it". The risk is, people won't think, when they move out of the context in which that practice IS best.

When discussing about best practices, keeping context in perspective is important. While certain general best practices can be applied globally, e.g., using version control, writing modular, reusable and testable code etc. there are going to be practices that are going to be dependent on the domain and business requirement. This helps in ensuring that solution is not under/over-engineered.

Start with WHY. Create value that you would pay money for. Align to what that value is and then begin coding. If it achieves the why, it's perfect!

I come from ancient days of software development where pride was not based on adherence to IT documentation doctrines, or robust internal code, but solely on user experience. Where the developers would, even after implementation, spend time with the users of the applications taking notes on user experience. Of course, we tested for bugs before distributing, but with the majority of bugs becoming evident in compiling, it quickly became obvious that the most common bugs faced were the gap between how the developers expected users to operate the application, and the many unexpected keystrokes and combinations the users actually attempted. Best Practices can never be about building a better IT team in a void space away from users.

Based on the nature of your project, for each skill area, Functional, Technical, People or Process, Identify or Create Best Practices documents, and organize them in such a way that it is readily available for reference like say in Sharepoint/Teams, Confluence etc. or even in as basic as a Sharedfolder accessible to the team. At all quality gates, their respective checklists should refer these documents. Many of the output artefacts best practices check should be automated through CI/CD pipelines. If using Scrum, DOD's should have these listed so they are ensured to be checked before a story is considered done.

First, there are best practices as defined in theory, development guides etc. Then there are best practices that are practical to your team and the project. To me, best practices that have greater chance of success are the ones that a team agrees upon, sees value in implementing them and holds each other to the task of ensuring they are being followed. So, first define the best practices that will make your and your team's life easier, and not yet another checklist to manage. Then seek input from your team and ensure they see a genuine value in them and then develop a process to adhere to them such as thru code reviews, pair programming or whatever works for your team.

Transparent WHY enables everyone to be on the same page and enables others to jump onboard and implement your best practices.

With my experience in SDLC over the years, best practices should be stated (with necessary justifications for them), communicated and documented. However, there should be room for improvement, innovation and creativity. Remember, the best practices of yesteryear, is now obsolete.

Communicating best practices for software development is a crucial element in successfully building software solution. It is essential that each of the team member understands these best practices and adopts as daily routine. Feedback channel should be kept open so that these are regularly updated to accommodate changes.

All of these communication methods are ad-hoc at best. There’s value in them, but having a centralized, up to date, community driven source of information is key. This builds program wide investment and interest in best practices

Documentation is becoming a thing of the past specially with the Agile methodology but it shouldn’t be. We are now in a very fast-paced development cycle and documentation is being left on the wayside. It’s now becoming an afterthought for many development teams. The leadership, stakeholders and the Scrum Master have to ensure the teams are given enough time to document designs, approach and most importantly any changes or pivot the teams have to make. I’ve worked with many scrum teams as a delivery manager and my job is to push changes through and I rely on the teams to let me know what they can and can not deliver within each iteration.

In my experience, even within agile projects, we should find ways to document user stories, infrastructure documentation, changes, issues. Some of these items can be tracked in sharepoint sites that are easier for the Dev team to update quickly. And some items can be saved in easily accessible repositories for the future. But documentation alleviates issues when production support issues arise or when original teams have changed and modifications are needed.

Every software development project should have a software design plan in which the development processes and tools to be used on the project are documented, along with all agreed-upon process metrics. The software development team must work as a team with a common set of procedures, tools and measures. Without such commonality there can be no hope of establishing and executing best practices.

I agree with the value of having, and using system and process documentation. Software development and implementation processes are moving forward more quickly than ever. Costly errors can be avoided or reduced by having access to, and making use of, properly created documentation. One of the first things I learned in the SDLC as an old school tester- if it's not written down, it didn't happen.

Write it down on a shared location. Simple. Ensure it's visible and can be edited like Wikipedia. What's written down lives beyond your role in the position.

As software changes, best practices may no longer be relevant, or may even become counter-productive. To guard against this, it is important to put best practices in a historical context. Release notes can fulfill this purpose, as can referencing changelogs for any software libraries that your software is dependent upon.

Reflect. Retrospect. Iterate. This is crucial to improve best practices. Encourage the team to improve what is currently best practices so it can grow as the standard for years to come.

The project software development plan, including processes, tools and metrics should be continuously reviewed both for measurement of compliance to the plan and also for fitness of the plan itself. Processes may need to be improved. Tools may need to be added, eliminated, or updated.

For best practice adoption and adherence, there should be periodic review. However, it's important to make review as easy as possible. One possibility is to implement automation.

Incorporating Lessons Learned and retrospectives turns best practices into a dynamic powerhouse! Regular feedback keeps them sharp and relevant. Documenting insights creates a treasure trove of wisdom for all. Root cause analysis uncovers hidden gems of solutions, while risk-spotting sessions add a proactive edge. Empowering team members to shape best practices fosters a vibrant culture of innovation. This lively approach tailors industry standards to fit your team's unique flair, making best practices not just effective but exciting and engaging!

Best practice documents are highly domain-specific. Sharing the best practices for web development is only mildly applicable for embedded systems development. The processes, tools and metrics will necessarily be different in different domains.

Share. Make it accessible. Be inclusive. Let the content be readily available to all who can benefit from it. It's okay to overcommunicate this if you are passionate.

Socializing as best practices are being defined helps to ensure the community is not only aware of them but embraces them as something they had a hand in creating. The sense of community ownership also eases governance because of innate compliance.

Strategies to share best practices include - Make it part of your team culture - Include best practices sharing as part of onboarding - Conduct regular internal brown bag sessions to share best practices cross functionally - Attend conferences local groups that share similar interests to see what the industry is doing - Keep your knowledge base updated based on learnings that come as part of your day to day experience

The most important context for sharing best practices is interpersonal. We must genuinely advocate for and reflect on them in our conversations with others.

Effective communication and continuous process improvement are vital in software development as they facilitate team collaboration, accurate requirements understanding, early bug detection and resolution, and higher customer satisfaction. These practices also promote adaptability to change, knowledge sharing among team members, and a culture of continuous learning and improvement. By fostering open communication and embracing process enhancement, software development teams can manage risks more effectively and deliver high-quality products efficiently.

Never lose sight of the fact that you are solving a (business or other) problem. The app or software is the means to this end but not the end itself. It's easy to get distracted by dogma around technical architectures, tool choices, languages/frameworks, and methodologies. While these are important conversations, they remain secondary to the question of "why are we doing this".

Consider timing and why. The concept of "best practices" implies a desire for improvement, learning, and fostering a growth mindset. In this context, analyze the development team, considering their work patterns, schedules, and preferences. It's crucial to catch their attention at the right time. Get input from the team on the optimal timing and preferred methods for knowledge sharing – whether through colleague teach-backs or expert insights. Initiate the process, retrospect it along the way, and make forward-looking improvements. By attentively listening to the “system” and adapting, the entire initiative evolves and matures as a co-created “thing”.

In the Software Development Life Cycle (SDLC), best practices, logic, and common sense form the bedrock for success. Tailoring the process to suit project needs ensures resource efficiency. Thorough planning and documentation foster collaboration, offering a clear roadmap. Regular communication promotes adaptability, early issue identification, and timely adjustments. Quality assurance with testing and code reviews maintains high standards, reducing errors. Adopting a modular, iterative approach accelerates development and eases maintenance. Cultivating a culture of continuous improvement through retrospectives and a growth mindset propels progress. Adhering to these principles, software projects thrive, achieving long-term success.

In the Software Development Life Cycle (SDLC), best practices, logic, and common sense form the bedrock for success. Tailoring the process to suit project needs ensures resource efficiency. Thorough planning and documentation foster collaboration, offering a clear roadmap. Regular communication promotes adaptability, early issue identification, and timely adjustments. Quality assurance with testing and code reviews maintains high standards, reducing errors. Adopting a modular, iterative approach accelerates development and eases maintenance. Cultivating a culture of continuous improvement through retrospectives and a growth mindset propels progress. Adhering to these principles, software projects thrive, achieving long-term success.