Artificial Intelligence
Consulting
Development ServicesDo you know how our brain evaluates the necessity of each particular action we perform? Associative chains that, for instance, allow us to close and lock the door automatically when we leave an apartment are created not because the brain thinks that closing the door is something good; rather they're created out of fear and anxiety we feel when the door is left open and unlocked. This fear overloads the brain, so the associative chain is formed not to provide a credit, but to avoid punishment or sad feelings.
The trick is if you put any software developer in a situation when not doing something meaningful and important is much worse than doing it, a special associative chain will be formed to incline a developer to be more efficient. The best-known method of employing this trick is using a penalty for poor performance.
As such, any tech lead should aim to create such conditions in which doing job properly becomes the most effective way of spending time at work. That being said, all wrong job approaches turn to become corridor walls and breaking these walls takes a lot of developers' time and efforts and results in burnout and poor performance. In a software development environment, such corridor walls are built automatically and it's up to your tech / team lead how thick and strong these walls will be. Do you want to have a daily code review? Add a rule to your versions control system that merge is disabled until code review is done. And that's it, you've got a pre-determined rule - pre-commit code review. Key to building effective corridors is the management's ability to organize internal workflow so that code review becomes an inevitable part of the process.
The evolution made our brains evaluate state of affairs on a continuous basis and set up, configure and adjust certain behavior models pertaining to this or that situation. We, humans, sense phony and fake stuff very well. And if we have even the slimmest opportunity not to do a boring job - we won't do it! And we'll find one hundred excuses not to do it.
That's when continuous integration (CI) comes to play a vital role! If CI is hardwired into your teamwork, all team members will have a shared vision and better understanding of the project goals. Once they've got this understanding, they'll subconsciously adjust own behavior and work approaches to meeting project milestones in the most efficient way.
The idea of continuous integration is to automate development processes for general improvement of the workflows within a team. Traditionally, CI is set up so that all automated controls are enabled after the developer has uploaded a new portion of the source code to a shared repository. Interactivity is of great importance, as the developer should feel the connection between pushing a new code to server and having an entire team get a build crash notification 2 minutes later. That's when physical indicators come in handy: current CI is broadcasted on a huge monitor with a dashboard indicating state of the code with different lights and colors. All these methods help our brain adjust its behavior and respond accordingly.
CI normally starts with the project assembly and "done - undone" as a key performance indicator. And then each team starts adding more and more automated rules to improve the workflow. Even adding code review with cyclomatic complexity is possible with CI. The only thing to keep in mind when doing CI is that measure is pleasure.
A good idea is to add code review for adherence to coding standards to your CI. For this purpose various lint programs (aka linters) are available. Launched before the project assembly, such a program can detect the most inconsistent and unhealthy code elements and notify team about them. Examples include identifiers naming and project structure, indentations, style of using parantheses accepted within the team, etc. The more inevitable the code review, the better disciplined the developers. They start following the standard not because their team lead has told them to do so, but because of fear to break a build. However, it's recommended that linters be configured to check the most critical points of standards only.
Continuous integration is great for project testing, and namely: integration, functional and unit-testing. It's enough to add a respective rule to your CI to make sure your project works perfectly well on all target screens and devices.
CI is a natural hub for storing information about how to roll out and configure the project being in progress. It's not a rare case when there's just one team member who knows the magic behind the project set-up and if s/he goes on vacation, everything becomes messy and results in a huge backlog. CI allows for gradual transfer of this knowledge to a centralized hub to ensure project's immunity against human errors and organizational mishap.
CI is at the very heart of Agile; it allows for gaining maximum value from the Agile methodology of software development. Automated assembly and launch let your software team better focus on development, interact with team members and other project stakeholders fast and help each other with tasks without being afraid of crashing the system.
Yet, when using CI, don't lose sight of your end goal. And the end goal is to improve the workflow by providing our brain with a set of easy-to-follow and clear automated rules. And it's easy to get trapped by focusing on the process, not the goal.
"A lot of teams I've seen during my career are aiming to cover the project with unit-tests and they believe it's the ultimate goal of their continuous integration," says Sergey Nemesh, Intersog's CTO. "Such a false goal creates an illusion of complexity control and allows developers to avoid a truly difficult work, i.e. building quality software products and delivering them on time."
Just set the right goal for your CI and you'll see how it'll help you manage your fears and concerns! Or sign up for our interactive workshop to learn how to improve your Agile Team performance and boost productivity.
