Chasing code quality in huge multi-location team project

Editor's Notes

• #3: Project size over 100 people total Large development activities in Vilnius, Suzhou, MinskProject management located in San Francisco
• #4: In the Component View, Business Processes and Functions (Claims, Billing, Policy) are composed of Common services which themselves adhere to a set of defined interface contracts.Services are implemented internally as JavaBeans and orchestrated through IoC via Spring configuration.All interface implementations rely on a common set of operational facilities for configuration, security, document generation, content management, rules and BAM.
• #5: If you succeed and you product gets many customer, with money paying for news features. You will need to expand your teams and here problems start. If you succeed and start growing, sometimes you get into multi-location, multi-team, multi product owners situation…
• #9: This is view Jenkins for one team CI environment, in most cases all is good, we have green build. Even if build fails it’s easy to fix it as people who broke it are near and can do it quickly.
• #10: CI is always red, one issues is find, while fixing it, new issues is created and this is eternal cycle. Teams get annoyed by the fact that CI is never working, they are not confident to take new source code from source control, just because it’s never stable and nobody knows then it will be fixed.
• #11: Fight – go investigate each incident, find who can be blamed, request fix, wait for fix and later find out that previous problem get fixed, but meanwhile new is introduced by other developer. After some time you will understand that fighting is not the answer, you will waist all you time and effort for it. Fail fast -
• #13: Each team has it’s own CI environment + central CI environment exist as well.
• #14: Each team has it’s own branch or repository close there they do all the coding. Only after Feature is done and team decided that code is good enough for integration it gets pushed to central. Push is done by one of the team members who does the “gatekeeper” role, he has to ensure the pushed code will go through.
• #15: Team CIPeople are less annoyed by CI failures. It’s easier to fix as people are co-located. It can be tested much earlier in the team scope.GatekeeperOne person who does the push will do merge and adequate testing before push. Less pushes, less builds, less failures.
• #16: People, even seniors do mistakes or sometimes are lazy to do adequate testing.
• #20: Environment stability: this is most important! If you environment produces unpredictable errors, this approach will not work.Test: If you have large number of failing test, it better to @ignore all of them and keep only stable/working test… Later you can revisit failing test and fix them one by one. CI: you will need huge number of hardware to run such setup.
• #22: It is generally accepted that the cost of a software bug goes up dramatically, perhaps exponentially, as the time between introduction and correction goes up.Typically customers don’t pay for code review as such, but if you need to achieve high quality this unavoidable and you should plan in ahead.Decision on code review should be made by project, there are many decision points – you need to know you project quality requirements (it doesn’t make sense to invest into short time project), project size (it doesn’t make much sense to do code review for POC’s or demos). Code review give benefits for larger, longer time to be supported and high quality projects.
• #23: Pair programming practically speaking does code review due the fact that two people are working on same code. But on the other end this is not true code review as it involves two developers who develop same thing for same deadline. Less than 100% 30% this is bare minimum to make sure developers care about their code and know that it might happen that their code will be reviewed. It’s Best Cost-Effect ration.This is level then developers are aware about possible code review and write better code. You can chose to review only selected review items – only complex changes, only juniors code, only new features, etc. Or 100%just to make sure nothing is missed.sounds quite much as it accounts small fixes as well, but this is practically this is the only approach ensuring highest quality.
• #26: Work as a team – everybody should feel part of team and understand that happens in other parts of code. Review all code changes – even small changes can create big problems… Code review minimizes this.Do not effect others– make sure code is compatible with others people work.Assure – most important is that this system has to assure code review is done. Don’t leave open windows to small hacks.
• #34: Coverage is calculate by testing code lines touched (executed by Unittests). It allows you to understand where you have good coverage and where you need add some work.