The Code Writers Workshop is taking place outside Washington, DC on June 9th with the theme “Software Leadership in a New Era.” The speakers are a diverse, distinguished array of industry leaders who have done great things around the world. The keynote speaker, Kara DeFrias, was Director of UX for former Vice-President Joe Biden!

The surprising thing is they’re letting me speak too. I have the honor of speaking on the topic “Here’s What’s Trending in Software Engineering.”

I look forward to learning from all the talented people who will be speaking at and attending the conference, and I hope to provide some interesting information as well. Please get in touch if you would like to attend. I will be happy to hook you up with a discount.

See you at the Code Writers Workshop!

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. The difficulty is learning how these abstract ideas apply to day-to-day software engineering.

For example, a common question is “Does Scrum permit a ScrumMaster with a technical background to help deliver features for the team he or she leads?” While this is a common practice and some teams have made it work, the general consensus answer is “No” or at least “Not ideally.” The primary reason is that a ScrumMaster can’t be an honest broker when resolving disagreements between the Product Owner and delivery team if he or she is writing code as a member of that delivery team. No one likes a conflict of interest, right?

However, there are other ways that a ScrumMaster with technical skills can apply them to provide significant value to the project and dramatically increase velocity without compromising credibility or the Scrum process.

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. In other words, the Go4 design patterns are only necessary because object-oriented programming (OOP) languages like C++ (the language they use in the book published in 1994) and Java demand them while FP obviates them entirely. Alvin’s post reiterates this theme by suggesting Scala “kills” the Strategy Pattern, which is one of my favorites because it promotes delegation over inheritance and is so obviously useful outside of the computer science department.

On this one, I really don’t agree with Alvin. Here’s why.

Vidya is proud to work with Webster & Fredrickson, PLLC, a law firm based in Washington, DC, specializing in the practice areas of whistleblower protection and employment, bankruptcy, and commercial law. Since the firm’s inception, Webster & Fredrickson has won millions for clients who have suffered discrimination, retaliation, harassment, and fraud at the hands of business and governmental organizations.

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. “OMG! $1.4 million?!!! For THAT???” I get it. That cost is absurd for what amounts to nothing more than a dream job for Two-Face.

The reaction was predictable. Add four cups of a smug Internet eager for an easy target, two cups of implicit assumption of widespread government waste, one cup of pervasive TSA resentment for making you take off your shoes when you’re running late, two tablespoons of a technology
everyone can understand, and one teaspoon of government contracting complexity, and you have a recipe for perfect Internet outrage. The app was so simple and the story so easy that The Late Show with Stephen Colbert and The Daily Show with Trevor Noah did bits on it. When it comes to public embarrassment, there’s bad, and then there’s late-night-talk-show-bit bad.

Of course the truth is a lot more complicated. The first shoe to drop was that journalists completely misunderstood the contract. TSA clarified that the $1.4 million figure refers to the entire contract vehicle. The amount dedicated to the Randomizer itself was a mere $47,400.

But isn’t that still way too much for an app that randomly points left or right?

Yes, but not by much and not for the reasons you might think.

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. That’s different from software engineering, which is an art.

As I help to revolutionize how government buys IT by teaching federal acquisition professionals to avoid spending hundreds of millions for deliverables that don’t work, I have stressed that the best way to maximize value and save taxpayer dollars is to understand the principles behind agile software development and to construct contracts accordingly.

Incentives (also called fee) have long been a significant part of government contracts—including contracts for software application development. When it comes to IT contracts, that needs to change as the government gets more agile. If you understand the core principles of agile development, it’s easy to see why.

Every (American) football fan knows that it is at least as important to know the playbook as it is to be blessed with speed, strength, and endorsement deals. After decades of failure with technology projects, including of course the high-profile debacle that was the initial rollout of HealthCare.gov, the United States government has taken steps to solve the problem. One of them was to create its own U.S. Digital Service Playbook, a guide to best practices for making technology work in government.

For me, this is personal. I’ve witnessed a lot of government technology projects fail because of some combination of incompetence, politics, and procurement methods that motivated shortsighted and suboptimal decisions. As the government begins to understand how to use technology to grow more efficient and yield more value to taxpayers, I want to play a role in that process. I’ve already written about the misunderstandings surrounding HealthCare.gov as well as a tactical overview of the Playbook for Government Computing News. This is a subject that has been important to me for a long time.

It turns out I am not the only one.