I was lucky enough to have the opportunity via Shine recently to attend the inaugural OWASP AppSec Day 2018 (Melbourne) at RMIT. Security professionals from around the globe gave some insightful talks into the state of secure application development in 2018. In this post I'll share you some of the key insights I gained from these talks.
I'm going to confess something. I've been harbouring a terrible secret for the last few years. It's something that I've tried to keep hidden away from my peers for a very long time so as not to be labeled as "that guy". Something I've kept buried deep in the depths of my darkest closet. Ok, maybe I'm being somewhat melodramatic. Pray tell, I hear you say, what is it?!
Well, it's that I enjoy writing documentation. From the lowliest code comments through to high level architectural documentation. I enjoy it all.
I work in a team that is constantly faced with the challenge of getting features approved for release into production. This is largely because the business is very fast moving, and business priorities change often. As priorities change, the focus of the business shifts from feature to feature, so resources for testing and approving features can be scarce. Consequently, our trunk codeline contains approved and unapproved features. This becomes a problem during our releases, because unapproved features have to be removed from trunk, which as most developers would know, is a painful process that results in dozens of conflicts.
In this blog I will present a solution to minimise the problems surrounding unapproved features in the codeline at the time of a release. This solution involves having a separate branch that only contains features that have been completed and approved by the business. I will also contrast this approach with popular alternatives like Feature Branching and Feature Toggling.
Working on a project that used pair programming was something that I'd wanted to try for a long time but had never had the opportunity to do. Consequently, when a chance came up to work on a project where the entire team was pair-programming full-time, I was ready to get on board and give it a go. In this post I'll talk about my experience, some of the benefits I saw, and some broader conclusions that I reached.