If you are a software engineer or run software projects, code coverage is probably very important to you. It’s intuitive. Of course more tests produce better software! It’s easy to calculate. Tools, automation, and stunning charts to impress the people who pay for the occasional pizza are all readily available. The problem is code coverage is killing you. Don’t get me wrong. You deserve credit for your agile commitment to quality and your investment in continuous integration and continuous delivery.
With a new year upon us, I am very proud to announce that the the US Pan Asian American Chamber of Commerce Education Foundation (USPAACC) has certified Vidya as an Asian and minority-owned small business. At Vidya, we have been very privileged to deliver high-quality software to a wide array of commercial and government clients using exciting technology while promoting lean principles, agile software development, and diversity in software engineering. The best part about it?
I had the opportunity to join a panel discussion hosted by Frank McNally, Director of Learning and Content Development at Public Spend Forum, where we discussed cybersecurity procurement in the federal government. Rounding out the panel was Spence Witten, VP of security solutions provider LunarLine, who has a wealth of experience with federal procurement in the security space. Check out why procurement officials need to take initiative when buying cybersecurity solutions (and how they can do it both pre-award and post-award) and how security can be built into the software engineering process.
Have you found that your code has a lot of bugs even though you’ve invested in maintaining 90% code coverage? Have you also found that your tests break so often that you don’t want to write any more? I have. With multiple clients. Part of the problem is code coverage is a misleading indicator of quality. Even worse, you are writing tests that don’t test anything except the implementation details of your code.
Functional programming isn’t exactly a fun topic anywhere outside of technical conferences and The Big Bang Theory. Even software engineers who love code often tune out when they hear terms like monad and referential transparency. But if you are a technical manager or executive, heads up. Functional programming will limit your technical debt so you build better software faster than you imagined and will earn you the Tesla you always wanted.
Anyone with a basic knowledge of Scrum, and certainly everyone who has taken Agile Software Project Management With Scrum, knows the role of the ScrumMaster–to be a servant leader, to act as guardian of the Scrum process, to remove obstacles for the delivery team, to negotiate any tension between the Product Owner and the delivery team, to encourage the team to self-organize and be cross-functional, and so on. These are so well understood they’re almost clichés.
Alvin Alexander is a renowned software engineer and author. His Scala Cookbook was invaluable when I got started with Scala, and that book and his prolific blog posts have remained essential reading even as I’ve gotten better at it. One of Alvin’s most recent posts, How Scala killed the Strategy Pattern, is the latest iteration of an old criticism of the Gang of Four (Go4) Design Patterns by functional programming (FP) advocates–that you don’t even need them if languages provide sufficient abstractions.
I was recently at an event hosted by the Agile Leadership Network of DC (ALN) called Reflective Retrospectives To Build High Performing Teams. It was an interesting presentation with a highly credentialed speaker–Certified Agile Coach, ITIL, PMP/PMI-ACP Coach, Protector of the Realm, Breaker of Chains, and so on–but what really struck me that evening was a question from the audience. The question came from a fellow software engineer, who began by noting that ALN events typically engage executives and managers rather than engineers, and can be paraphrased this way:
News broke recently that the Transportation Security Administration (TSA) contracted the development of an iPad app called the Randomizer that eliminates any hint of profiling by airport security by simply directing travelers according to an arrow onscreen that randomly points left or right. That’s it. No, really. An arrow that points left or right. At random. Over and over. The cost? $1.4 million. Yes, that’s dollars. Naturally, the Internet sprung into outrage.
At an event recently, someone was kind enough to introduce herself to me, and during the course of our pleasant conversation, she asked me, “So are you a programmer?” My first impulse was to acknowledge once again that I look really nerdy. I embrace that. But my second impulse was to be mildly offended. I wasn’t sure exactly why. As I have reflected a bit about that, I think my visceral reaction to being called a “programmer” arose from my perception of programmers as just people who write code, which is a science.