Continuous Integration and Continuous Deployment
Automated QA and Full Product Regression Test Suite
TDD - Unit Testing
Code Reviews and Automated Code Quality Checks
Alternate Title: 5 Things that your company or agency should be doing to get the most out of your Software Engineers
1. Continuous Integration and Continuous Deployment
Continuous Integration (CI) is a development practice where engineers integrate code into a repository several times a day. Each check-in is verified by an automated build. This allows teams to detect problems early whereas Continuous Deployment aims to reduce the time elapsed between writing a line of code and making that code available to users in production. Ideally, a passing automated build means the product is deployed to production. Numerous tools exist to help teams accomplish this: CircleCI, Codeship, Docker, etc
Some teams will skip this vital practice and opt instead for bi-weekly or monthly releases with manual deployments that involved elaborate steps carried out by engineers on a production environment.
The problem with this approach is that by the time the code hits production, it is already out of date. It is not current with the code the engineers are currently working on. If problems are found in production, the engineers need to go back to the old code and patch it. The common answer will be “That will be fixed in the next release”, in other words, live with the problem for another month or two weeks.
If the engineers have to troubleshoot old code, they wastes valuable hours that could have been used to build new features or overhaul legacy systems.
Managers and teams should budget time to figure our how they can successfully deliver both Continuous Integration and Continuous deployment. When code is ready, it should ship.
As a co-worker of mine said, “Work in progress is the root of evil for software teams”.
2. Automated QA and Full Product Regression Test Suite
With an array of open source tools like Selenium or Splinter as well as paid platforms for running automated test suites like like CrossBrowserTesting by Smartbear and Saucelabs, there is no reason a mature company should not be investing in automated QA for their product. Along with continuous integration, an automated QA systems should be developed and it should verify functionality of the product outside the scope of unit tests. If the product is complex, for example with multiple apis or services, a full regression suite should be built against a robust test environment.
At times, teams and managers may prefer to bypass building a regression suite in favor of hiring a team of QA engineers to manually test the website or mobile app. The QA team will click around the site and see if they notice issues. They may even follow test cases for their manual testing. The problem here is that in order to cover every browser and every device, you must hire and invest in a large QA team. Large teams come with communications overhead.
By opting not to take the hit and have your engineers build a full regression suite, this oversight will probably cost your company more money in the long run.
3. TDD - Unit Testing
Unit testing is a method by which individual units of source code are tested to determine if they are fit for use. Unit tests are written and executed by software engineers to ensure that code meets its design requirements and executes with expected behaviors.
As described in Growing Object-Oriented Software Guided by Tests, Unit testing can also drive the design of your objects or functions by exposing complex dependencies. Unit testing will also lend a hand when refactoring for new features in the future.
Since Kent Beck’s seminal book Test-Driven Development by Example was released in 2000, Unit Testing has become a widespread practice for seasoned engineers but some junior developers will choose to skip this step. When pressure is applied to meet deadlines, some will ship their product without proper unit test coverage.
The product launch may go smoothly but in 6 months or 1 year, the team will be awash in technical debt. As the project grows or the teams grows, because methods and objects were not tested properly, the team will lose confidence in the code. Unrelated code changes in one service object may affect another. APIs will seem to be returning strange error messages that for edge cases and nobody can recall why. Eventually, team members will throw up their hands in desperation and you will hear cries of “This whole project needs a re-write”. This doesn’t end well…
As somebody that does not like to ship code without writing unit tests, I sleep well at night. My code may not immaculate or have a perfect design (I might think of those optimizations as I’m falling to sleep) but at least know it is well tested and the next engineer can run my tests and verify for herself that it works.
4. Code Reviews and Automated Code Quality Checks
First, your company must understand that code reviewing is a labor intensive process that requires a developer to give time and constructive feedback to others on their team. Code reviews serves 2 purposes:
- Ensure higher quality of code.
- Build knowledge of how features are implemented.
If you watch a Hollywood Movie or TV Show, you may be under the impression the most code is written by a super-talented genius from whose fingertips flows brilliant solutions at the drop of a hat. In the real world, this rarely happens. I have worked with some very smart people but most good quality software I have seen delivered was produced by teams who collaborate, share and learn from each other. Code reviews is an important part of this process.
One of my professors at UH Manoa, Philip Johnson, first introduced me to tools for Static and Dynamic Analysis of Java. At the time, I was a bit offended by such a thought. How could a machine know better than me if this code is solid? I used the tools he suggested at first begrudgingly. As time went on, I not only learned valuable information from these tools, I came to see them as indispensable.
With the advent of metric_fu for Ruby, Rubocop, ESLint combined with excellent and affordable service offered by Code Climate or CodeBeat, it is easy to plug automated code quality checking tools into your build system. A good team will learn and grow from using these tools.
Having Automated Code Quality tools in place helps surface issues with your code and is an important addition when integrated with your development process.
If you browse job postings for “Web Developer”, “Software Developer” and “Software Engineer”, you will often notice one thing: most openings are for “Senior” engineers. Every company would like to bring on 2 or 3 great engineers with 10+ years experience and have them deliver high quality software ad infinitum.
Then reality kicks in. The interviewing starts.
Many who apply are not really senior. Some are mid-level and others are surprisingly junior even though they have a multiple years of experience listed on their resumes.
The process drags on for months. Your current engineers are pulled away from their work to do multiple interviews per week. Not only does their productivity sap but most engineers don’t like interviewing other engineers because the process is so subjective. The quest for the unicorn engineer falters…
What is the solution?
A solid, well-thought-out mentorship program.
Most senior engineers are happy to impart their knowledge to junior or mid-level engineers and have many ideas about how this can be done successfully. The problem is, this needs to budgeted for and prioritized. Mentorship hours need to be established. Tasks and goals need to be created and agreed upon up and down the food chain.
With a good mentorship program, you can start to look at other employees in your organization and see if there aren’t hidden pools of talent. Maybe there is a graphic or web designer who always wanted to learn programming more in depth? Maybe there is a QA engineer whose coding skills just needs a little more polish to become software engineer quality? Maybe the Excel wizard in accounting just needs to have a curriculum of online courses set for him by a mentor to become the next Linus Torvalds?
Also with a good mentorship program, you can hire a few of those mid or junior level engineers. If the culture supports them, they will blossom and grow.
Shameless Self Promotion
I sub-contract for agencies and contract directly with companies in North America. If you would like to get in touch, you can email firstname.lastname@example.org