2018-06-22 Friday - Advice to a Development Team Struggling with Delivery & Defects

Recently I had a discussion with the CEO of a  .NET focused software development company - who was concerned with recurring delays in his development organization's ability to consistently meet agile sprint delivery schedules - and an attendant problem of unexpected defect rates in the code that was delivered.  

After our brief discussion, I suggested that - based on the symptoms he  described - my initial suggestion would be to ensure that the following three areas were not contributors  - and were well understood by the development teams . 

Possible Root Causes To Investigate (in the near-term):

1) Developers may not be adequately trained in agile practices and the language/tools they are using

• Defects will tend to cluster around either specific persons and/or  specific code modules.  Root-cause analysis is essential to properly determine the appropriate mitigation actions, such as...
• Use the 5-Whys of Six Sigma to determine the root cause for defects - often it may come down to a lack of knowledge/training - being tasked to do something outside their area of expertise - lack of awareness of good code design principles, etc.
• For example (from my 2015 Seattle Code Camp talk, Diagnosing The Patient):
• 1st: Why is the system slow?
• The DB is slow
• 2nd: Why is the database slow?
• The app executes a lot of queries to load a page
• 3rd: Why is the app designed to be so chatty?
• DB was designed in an inefficient manner by [X]
• 4th: Why didn’t [X] use an efficient DB design?
• [X] was never trained on database design
• 5th: Why didn’t [X] get any DB design training?
• There is no budget for training
  

2) Developers may not be following Test Driven Design/Development (TDD) practices

• This can be due to a number of possible causative factors:
• Developers may be overwhelmed with unrealistic workloads squeezed into sprints
• Developers may not be adequately trained/experienced to properly estimate Epics/Stories/Tasks - and therefore are simply racing as fast as they can to crank out the code for a given sprint
• Developers may be writing trivial tests - and not focusing on the 20% that represents the `critical section` - first. 

3) Continuous Integration may not be in place (or taking advantage of all of its capabilities)

• Continuous Integration Server tooling
• https://www.infoworld.com/article/3239666/devops/what-is-jenkins-the-ci-server-explained.html
• https://www.c-sharpcorner.com/blogs/continuous-integration-tools
  
• https://www.c-sharpcorner.com/article/continuous-integration-for-net-projects-with-jenkins/
  
• https://jenkins.io/
• http://www.jetbrains.com/teamcity/
• https://docs.microsoft.com/en-us/vsts/pipelines/?view=vsts
  
• https://docs.microsoft.com/en-us/dotnet/core/tools/using-ci-with-cli
• https://docs.microsoft.com/en-us/vsts/pipelines/apps/aspnet/build-aspnet-cloudservice?view=vsts
  

• Kicked-off, automatically, upon code check-in to source control...
  
• Static code analysis tools automatically executed, reports generated, sent out via email
• Cyclomatic Complexity Analysis
• http://www.mccabe.com/iq_research_nist.htm
• NIST Special Publication 500-235, Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric
• "Based on the cyclomatic complexity measure of McCabe, structured testing uses the control flow structure of software to establish path coverage criteria. The resultant test sets provide more thorough testing than statement and branch coverage. Extensions of the fundamental structured testing techniques for integration testing and object-oriented systems are also presented. Several related software complexity metrics are described. Summaries of technical papers, case studies, and empirical results are presented in the appendices."
• http://www.mccabe.com/pdf/mccabe-nist235r.pdf
• https://blogs.msdn.microsoft.com/zainnab/2011/05/17/code-metrics-cyclomatic-complexity/
  
• https://blog.ndepend.com/cyclomatic-complexity-c/ 
  
• https://docs.microsoft.com/en-us/visualstudio/code-quality/ca1502-avoid-excessive-complexity
  
• https://github.com/JetBrains/resharper-cyclomatic-complexity
• https://resharper-plugins.jetbrains.com/packages/PowerToys.CyclomaticComplexity/
  
• Bug Detection
• https://www.sonarqube.org/
  
• https://docs.sonarqube.org/pages/viewpage.action?pageId=1441900
• https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+MSBuild 
• ShapChecker
• http://sharpchecker.ispras.ru/en/
• https://www.nuget.org/packages/SharpChecker
  
• https://link.springer.com/article/10.1134/S0361768817040041
  
• Standards compliance (naming conventions, patterns, anti-patterns, etc.)
• https://github.com/StyleCop
  
• Automated Unit Test execution
• http://nunit.org/
• https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-with-nunit
  
• Automated Performance Test monitoring/execution/diagnostic tooling
  
• https://channel9.msdn.com/Shows/Azure-Friday/Performance-Testing-Web-Applications-with-Manas-Maheshwari
  
• https://www.hanselman.com/blog/BenchmarkingNETCode.aspx
  
• https://github.com/dotnet/BenchmarkDotNet
  
• https://www.jetbrains.com/profiler/features
• https://www.radview.com/about-webload/features/webload-cloud/
  
• https://www.dynatrace.com/availability-and-performance/net-performance-monitoring/
• https://github.com/hallatore/Netling
• http://websurge.west-wind.com/
• https://www.telerik.com/fiddler
  
• https://petabridge.com/blog/introduction-to-nbench/
  
• https://github.com/petabridge/NBench
  
• etc.
• If build passes all checks/tests - automatically deployed to a QA / User Acceptance / PPROD server - for further testing/verification
  

Uncle Bob Martin's book, Clean Code - is the foundation knowledge that is necessary for every developer to be successful:
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882



He also teaches a 3-day workshop

• https://sites.google.com/site/unclebobconsultingllc/home/training
• https://drive.google.com/file/d/0BwhCYaYDn8EgZTBjNjBiMDItMjBjMS00MTczLTg3MzctN2RlNTkwNTg2MGU5/view