Category: Planning

software-warfare-attack

Do you Respond to a [Software] Attack with Unarmed Fighter Jets?

garthkoyleLeave a comment

You can’t entirely prevent an software attack, but you can be prepared to respond.

In 2015, we learned an interesting fact about how prepared the United States Armed Forces were to respond to an attack. During the attacks on September 11, 2001, after three other airplanes attacked the World Trade Center and Pentagon, all flights were ordered to land immediately. But Flight 93 continued its course towards Washington, D.C.

In response to Flight 93 disobeying the orders to land, the government ordered multiple F-16 fighter jets to scramble and fly towards Flight 93, presumed to have been hijacked due to its refusal to land. What we did not know until 2015 is that the fighter jets were not equipped with munitions to shoot down the plane. Consequently, the only option was for the pilots to ram the jets mid-air to stop them from approaching Washington D.C.

Apparently, the U.S. was more focused on threats farther away and had disarmed their domestic fighter jets. I don’t want to second-guess or comment on their military strategy, but did they ever play the game of Risk?

Prepare to Respond to Attacks in Modern Software Warfare

The September 11, 2001 attacks are similar to and an example of how it is nearly impossible to see and detect every threat. Likewise with software, as programs get more complex, users get more creative, and inter-connectivity increases, it leaves applications vulnerable. Software developers should do everything they can to protect their applications. However, I subscribe to the philosophy that if your applications are popular enough, eventually your systems will get hacked.

When your application is hacked, how you respond to those attacks will be just as important as protecting yourself in the first place. It’s a sad but true reality that we can’t anticipate all threats. But, I do believe that we can be more prepared to respond.

At Event Espresso and Event Smart we have a fairly rapid release process where within a minute or less of fixing a security hole we can release updates to our products. While that won’t stop the attack from happening in the first place, it does allow us to quickly block the attack and move on to damage control.

While an ounce of prevention is worth a pound of cure, as software developers we should have a process in place to manage an attack of various types that was unable to be prevented.

Ultimately, we were fortunate that the passengers of Flight 93 were able to neutralize the plane and do what the U.S. military was not very prepared to do. But we should not find ourselves in such a vulnerable position so that when an attack happens we are not even prepared to respond.

What is your process for responding to an attack on your software, platform or infrastructure?

counting priorities

3 Factors to Quickly Set Short-term Development Priorities

garthkoyleLeave a comment

There are an unlimited number of factors you could take into consideration when determining what projects or tasks should be a priority. You will likely use different factors when considering long or short term priorities too. What factors you actually use will be a reflection of the mission of your organization. Recently I spent a little time setting priorities for our Event Espresso and Event Smart developers for the next week. During this process I used Speed, Impact and Strategy to make the process of setting short-term priorities more practical. 🔨

Most Factors Distill Down to the Mission of the Organization

If the organization has a mission to make money, the organization will focus on what will drive money now and later. If the organization is focused on a different specific purpose, then the purpose of the day will be whatever can forward that mission.

Sometimes the “Mission” is Too Ambiguous to be Helpful

However, sometimes using the mission of the organization is not clear enough for the day-to-day decision making to be very helpful.

Here is a mission statement for Coca Cola that is probably less than helpful for a manager or programmer to decide what software code to work on today.

The Coca Cola Company Mission. Our mission is: To refresh the world in mind, body and spirit. To inspire moments of optimism and happiness through our brands and actions.

If you’re a programmer could you justify doing yoga to support that mission statement? 🤔

And if you’re the manager of that programmer, you won’t be very happy with the progress of your software project at the end of the week.

We have a mission statement and vision for Event Espresso, but that’s not necessarily enough to tell us what we should work on today, tomorrow or next week. For the real short-term planning I favor: speed, impact, and strategy.

Speed

Speed is important because sometimes a developer can complete a task (or several tasks) that can collectively improve a customer’s experience. Sometimes a few quick wins can increase your team’s morale, momentum and energy.

Getting a batch of issues resolved quickly can also clarify the fewer remaining tasks.

Even if a task has a lot of impact (discussed next), it might take a long time to get done, which can delay other enhancements.

So, the speed or velocity of completing the tasks is important. The faster a developer or development team can get something done the more likely it will be a priority today.

Impact

Some of the tasks you might consider will be trivial or significant. In the short-run, I favor projects that can have the biggest impact in the shortest amount of time. We often categorize tasks by the amount of work we expect it will take. So when we are evaluating a task we can get a sense that if we invest a little in that task it will be done pretty quickly. That gives us confidence that we can make customers happy and increase our chances of gaining market share in the event registration and ticketing software space.

Strategy

Even if there are features or bug fixes that customers want addressed, and we can do that task quickly, that still doesn’t mean those tasks should be a priority. In the software business you want to avoid throwing every little suggestion into your program. Unnecessary features and code creates technical debt that will have to be maintained and will impact future development (for good or bad). So, only when a task fits into the purpose of your software should you consider investing resources into that code.

What factors do you consider?

There are a lot of other great factors that could also be considered, such as marketability, popularity, etc… but I’ve discussed just a few of the more easily understood factors I use to help set development priorities in the short-term.

Give some encouragement and share a little…What factors do you use to quickly set short-term priorities? If you haven’t thought about it specifically, pause for a minute then tell me what you think.