In part one, DevOps.com presented Netuitive’s DevOps transformation, which helped the company to automate its product development processes. Now in part two, we take a look at that development process as it stands today.

Netuitive Development & Technical Debt Initiatives

“We are using a Feature Branch Workflow model with Git to isolate our work while we develop and test it,” says Brian Spindler, VP of Engineering, Netuitive. As soon as all teams and team members are in agreement, Netuitive merges the feature with the master branch and deploys it to the internal pre-release staging environment for further testing and verification.

“In the old world, we released software twice a year,” says Spindler. After using the Scrum development process religiously and exclusively to take the software to beta, Netuitive drove the pre-release software through the testing ringer prior to releasing the packaged final product.

“Now we release on a weekly basis,” says Spindler. The development team shoulders the unit, integration, and acceptance testing while Netuitive reaches forward to increasingly add features and polish its architecture.

Netuitive is continually bringing the increasing technical debt into the black side of the development ledger, so to speak. Netuitive offers two examples of being technically in the red. The first is in the area of unfinished business. Incomplete or hacked up implementations typically happen when the team is developing outside the core technology stack, is cutting corners for speed, has a poor understanding of the software requirements in a given area, has to rush testing, or does not create complete and appropriate documentation, according to Spindler.

The second example circles library / dependency updates, where falling behind can lead to numerous interrupts and blocks for features / bugs / requests that are at the top of the queue, Spindler explains. “Often times in either of these two sample areas, a theme will emerge and that can be a good indicator that it is time to start paying down the technical debt in that area,” says Spindler.

Netuitive puts that debt under a microscope where through transparency and visibility, it can review the bugs on a regular recurring basis and, as soon as an engineer catches something that is offensive to the software, he can create a ticket in JIRA to put it on the backlog to address, according to Spindler.

“However, it doesn’t always make sense to ticket something if it is not actionable,” says Spindler. In such cases, Netuitive will catch those instances of technical debt in the Technical Roadmap Idea Board that it maintains, which captures three verticals: the development environment, the technical debt, and the architectural / structural vision, according to Spindler. “Any team member can contribute to this Board. To keep everything on it in perspective, we hold retrospectives regularly,” says Spindler.

Changes, Experiences

“It was a positive experience seeing how we handle bug fixes differently after switching to a SaaS model,” says Spindler. Now we understand bugs that we fix very well and we easily duplicate them for isolation and to excise them from the software. That’s because the developer has full access and freedom to debug the same system that he reports on. This eliminates the tedium of setting up systems and testing and repairing for edge case scenarios, according to Spindler.

“We were also positively surprised at how quickly something can go from concept to production,” says Spindler. To make that possible, there is an opportunity cost in that development has to be willing to sacrifice, to try something while risking having to toss something aside. “In the SaaS world, it’s all about trade-offs, fast vs. refactoring, pay off that technical debt or put out feature XYZ. When you have a team like ours, everyone’s time is critical, and we work hard at prioritizing and balancing that,” Spindler says.

To maintain the balance and improve the team’s precision and good judgement over time, Netuitive follows Kaizen, which is a continuous improvement methodology. “As the team grows and changes, so will our priorities and the way we work and build the system. We’ve got to be open to that and willing to embrace it,” says Spindler. Regular retrospectives and transparency help to make that possible.