Top insights for IT pros
From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.
One important code-development rule for Steve Hulet, co-founder and CTO of Fresh Consulting? Every code change gets a peer review, from the change of a button’s color to the integration of credit-card processing.
“Some people, they might not understand or see the value and might be tempted to think that they can go faster by cutting it out…I think in the long run, you go faster by being careful and doing code reviews,” Hulet told IT Brew.
Peer review is one method for testing software, but organizations are still tinkering with the process to make sure that health checks for code don’t turn into roadblocks for developers. An IT leader’s choices on testing procedures set an impactful tone throughout an organization that can lead to either glitch or glory.
“If your team culture is not found and they’re not working as a team, you’re just giving tickets to individuals, and they go execute these peer reviews, it is chaos. And that is a very expensive way of running business,” said Fernando Cuadra, principal consultant at the advisory ISG.
Code chaos consequences. A report from the Consortium for Information and Software Quality (CISQ) estimated that the US cost of poor software quality has grown to at least $2.41 trillion, citing data breaches, unsuccessful projects, and recalls.
As Cuadra coaches up software-development teams, one industry-wide problem he sees relates to traditional ideas of peer review: In a typical peer audit, a reviewer is notified, they inspect the code for defects, and provide feedback that then gets incorporated into the next version until both sides are satisfied. The requests, however, may disrupt a coder’s routine, who might be in the middle of another task. And the person asking for review has to standby and wait for feedback.
Cuadra’s solution: pair up. One person types the code, the other watches, offering inspection in real time, and the two switch roles every 15 to 30 minutes.
“You’re identifying bugs on the fly. You have continuous reviews, so you don’t have to disrupt other folks. And you’re sharing information,” Cuadra told IT Brew.
With a pair, the code is designed together, said Cuadra, who guessed that only one out of 10 software teams decide to program in duos.
Whether you decide to pair up or peer up, don’t skip the review part.
“You’ve got to say that this is our culture, and this is our requirement…If a team decides to skip the testing requirement…their CTO needs to be telling them, ‘You can’t do that,’” said Rob Juncker, a CTO at the cybersecurity software company Code42.
Programmer and CTO: quite the pair.—BH
Do you work in IT or have information about your IT department you want to share? Email [email protected].