Number of lines of code. Number of commits. Number of bugs caught. Such are the old metrics of development. All very macho, all very developer bro—and all not terribly effective. These days, development is about quality, not quantity. It is about closing the gap between development and business, so technology solves tangible problems.
At cdCon in Vancouver, I recently discussed this topic with fellow technologists and product managers from JP Morgan, Roku and DeployHub. Everyone came to the discussion with different experiences and different business needs, but when it came down to the process of defining the role of developers and making them more productive, there were key themes and rules of engagement we all agreed on.
Rule 1: Time to get a framework.
As someone who spent more than 12 years in development, I get it. What works is what works is what works. And with schedules and budgets always tight, most developers don’t have the luxury to mess around with ideation. At the same time, there is a big difference between working hard and working smart.
Working smart is something I learned the hard way. After one-too-many experiences going off into a black box for months and coming back with what I thought was needed and finding out all the work needed to be scrapped, I realized the gap between developers and users and the business was something that needed to end.
Getting a development framework was the solution. OKR (Objectives and Key Results), developed by Intel’s Andy Grove back in the day, was the framework that made the most sense to me for its straightforward approach to solving the right problems.
Some developers favor Dora Medics. But really, it all comes down to the same principle. Developers need to work collaboratively with business so key problems are met, rather than just a release date.
Rule 2: Metrics have to be tied deeply to your organization.
How well a development framework is working is not something that can be externally defined. Performance should be deeply tied to the values and needs of your particular business.
When I was at Trend Micro, my previous company, we picked three. Without giving away the secret formula, I can say they combined usability with health and growth. But, honestly, as with the frameworks themselves, you can have three or thirty-three; it doesn’t matter as long as development is closing that gap and homing in on the true pain points of the business.
As a rule of thumb, Good OKR metrics will tell you that the latest release increased customer retention by 10% and development time spent on specific tasks decreased by 5%. Bad OKR metrics, like all bad numbers, always result from the same junk thinking: Make more money by doing the same thing or less of the right thing. Or, even worse, there are those situations when teams try to embrace the Agile principle of ‘fail fast,’ but ignore the key metrics that show their efforts aren’t really moving the needle.
Rule 3: Choose the right tools to avoid false positives.
At this point, I know the cynics are wondering whether you work bit-by-bit in agile or doing everything all at once with waterfall, aren’t you ending up in the same place? No, not quite. It may seem that way, but the missing ingredient in waterfall development is user feedback.
Every release is a reckoning with usability and business utility. That helpful, direct input is not something you get from traditional development. In this new world, we fail fast, and we learn and iterate, which is why having the right tools can help maintain momentum by giving us the right information.
When it comes to security in particular, it is too easy to be fooled by false positives. Development teams lose valuable time (and budget) chasing down long lists of vulnerabilities. With a tool like Qwiet AI’s Blacklight, for instance, developers drill down on vulnerabilities to reveal true exploits that are threatening their organization.
This is only one example, I realize, but it is indicative of the larger issue our panel discussion kept addressing: How to remain empathetic to the end-user while also delivering on ever-more-aggressive deadlines.
With the threat surface of today’s development organization also ever-increasing, it is too easy to cut corners or ignore issues like security entirely.
The good news for all the developers out there who pride themselves on good code and would never want to see their code hacked, the same tools that might seem like an unnecessary step save not only one’s reputation, but they also create concrete evidence to show the business what has been working.
As someone who once doubted these same methods, I can’t tell you the relief I felt the first time I walked into a business meeting with true metrics showing exactly what was happening with my team and where money needed to be invested to improve our shortcomings. Being able to offer that tangible proof, in lieu of the usual back-of-the-envelope estimates was one of the most freeing experiences of my career—and one that I recommend to every developer who dreams of improving their productivity and overall quality of life.
