Why Branching still has a Place in the Agile World

I’m sure every developer out there would love to have a single code base with builds which are automatically tested and pushed out to customers. However, let’s assume for a moment that you’ve not got a full CI system with triggered builds, automated testing, and thousands of automated deployments a day.

For the sake argument let’s say you’ve got some of these pieces in place. Perhaps you have nightly builds? Maybe even some unit tests! But if you’re like most of the companies I’ve worked with you still run manual signoff scripts and have a couple of guys who do the deployments, know every config setting by heart and can get your application to run in all kinds of new and innovative ways.

Despite what The Phoenix Project tells us deployments to customers are still a big deal and version management (finding a way to release bug fixes but not new features) is a fact of life.

If your customers are anything like mine they’ll be incredibly nervous about taking new features. They want lengthy UAT phases and opportunities to train their staff on new functionality. This may seem like Waterfall to us, but remember many of our clients have stakeholders in some very big business. In my industry (Health and Leisure) for example we have code freezes over the January period while New Years Resolutioners and marketing campaigns are at their peak. Very few businesses would open themselves up to the risk of IT failures during these critical times.

And yet support contracts and maintenance doesn’t stop. The busy times are when the software is really put to the test and we must be able to respond to any issue which may arise.

This is why we use maintenance branches.

Our job as developers and IT professionals is to deliver a good service to our customers. We need tools and processes to do this. Agile and Continuous Integration are two of those tools but if they don’t help us meet business needs then we should seek others which do.

My customers tell me that they want to be able to take patches quickly if required. That they want to be able to access fixes without the need to test and learn new functionality.

Techniques such as feature toggles help but in my view the only way to truly meet this need is to cut a release branch after each feature (or for convenience block of features) is completed. We usually use a minor version to represent this. Using this model we can support customers without surprising them with new functionality and continue to develop knowing that we can put out maintenance releases of older version at any time.

Controversial? Perhaps, practically over purity… I hope so. What are your views or release branches and support customers with on premise installations?

Microsoft HoloLens

I was lucky enough to get tickets to see Mike Taulty talk about Microsoft HoloLens at Leeds Sharp last week. I didn’t really know anything about augmentated reality or virtual reality but in the interests of Staying Technical I was definitely interested to find out a little more.

Wow!

It turns out that the HoloLens is a Windows 10 PC designed to be worn rather than sat at. It runs apps from the windows store without modification (although Mike did stress that typing furiously in midair is somewhat less precise than using a keyboard). Instead of sitting on a screen the windows floats in front of you, hovers on a wall, or rests on a table.

3D apps can be build using Unity 3D (in fact Mike showed us how). I was really impressed how easy it was to work out what the user was looking out and listen to what they were saying (although I imagine Microsoft Cognitive Services could be used very effectively here).

Can I imagine us all walking around with these things strapped our head? Probably not… at nearly £3000 for the developer version these are likely to be out of the consumer budget (although Microsoft are working with partners at the moment to develop other models). But in a commercial environment? For architects, engineers, surgeons or even as a stepping stone onto the next generation devices which may weigh little more than regular sunglasses? I could see that!

Am I rushing out to buy a HoloLens? Probably not,  it would I seriously consider an Acer or Asus model for a couple of hundred pounds… that’s a much harder question to answer! I can imagine little spaceships flying around my living room or a huge troll sat on my sofa playing chess with me – the sky really could be the limit with these devices!

The Cost of Fixing Bugs Late

Have you ever been in a situation where you’ve written a piece of code and it’s almost there but there are a few niggling issues which “can wait for V2?”. Have you ever wished, maybe months later that you’d gone back and resolved them at the time? You’re not alone!

More and more developers and managers are beginning to realise the true cost of fixing bugs late, not only on their sanity but on the company’s time and money.

Let’s say for the sake of argument that you’ve finished a piece of code except for a few edge cases. You’re under a lot of time pressure so you decide it’s of a high enough quality and you push it through to QA. The cost to the business of fixing that issue actually increases dramatically the longer it’s left.

Let’s look at a few scenarios:

You fix the issue immediatly

  • Fix time – 30 minutes

You send to QA and it’s rejected there

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Fix time – 30 minutes

QA passes as an “edge case” but the customer disagrees

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Deploy to UAT – 3 hours
  • Customer UAT – 1 week

Missed in UAT but discovered as a significant issue in Live

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Deploy to UAT – 3 hours
  • Customer UAT – 1 week
  • Customer live deploy – 3 hours

 

As you can see, even with these rough estimates the time it takes to resolve the customer’s issue increases dramatically the longer it’s left. Not only that but the cost of time to the business of paying staff to run extra QA cycles or rounds of UAT spirals out of control. We haven’t even considered the final case where it goes to the bug queue to die and a completely different developer has to learn the feature and resolve the problem.

The graph is actually a very common shape*.

graph-2

I’m a big fan of practicality, no software is going to be perfect and it’s unrealistic to expect that you’re going to find and fix each and every issue before shipping to a customer.

However, hopefully this has made you stop and think and has provided a strong argument for making that extra 30 minutes to resolve the issue before it causes a real headache for the business!

*Thanks to fooplot.com for the graphing software.

When and Where to Automate Testing

A year ago I undertook an interesting piece of R&D to write Selenium tests for our main UI. I watched the pluralsight course, learned the difference between WebDriver and the IDE, and started building my Page Object Model. My simple test took the best part of three weeks to build and executed in around half the time a decent QA would take if you gave them a double shot of espresso.

I patted myself on the back, demonstrated the work to our Product Owner, and then advised that we should shelve the work because I wasn’t confident to hand over the mind boggling complexities of waits, framesets, and inherited view models into general practice.

Over time I lost confidence in the project. If it had taken me days to generate even the simplest of tests how would a junior developer fair when asked to automate complex financial scenarios. Quietly I put the idea to the back of my mind and concentrated on other more pressing matters.

That was until last week. We’ve been doing some work on our BACS integration and as part of the regression test I’d enlisted the help of one of our QAs to mock each response code and import it into the system. The process was tedious, repetitive, and I hated myself when I had to tell him he’d missed a vital check off each scenario.

As I was speaking to him cogs in my head began to turn. I’d gone off the idea of large scale test automation because of the complexity of our UI but the BACS processing system doesn’t have a UI. I could knock something together in a couple of hours which would create customers, mock BACS files, and schedule our JobServer. Even more powerful, if I used a technology like SpecFlow our QA could write the tests he wanted, I could automate them, and we’d be able to iterate over every scenario within a couple of minutes. Even more exciting was the idea we could send the feature files off to our Product Owner and banking partner and ask them to verify the behaviour was correct.

Later that week, after we’d proven our project to be a success and found a handful of low priority bugs to be corrected I started to wonder why this automation project had delivered such value where the previous UI automation had failed. I decided this was because:

  • The BACS process was an automated mechanism already so the test automation steps were simpler
  • The UI had been designed for human use, it wasn’t a chore to run through but it was complex for Selenium to navigate the controls
  • Mocking and importing BACS files was repetitive, slow, and tedious

The project turned out to be a huge success, we’re already planning on how we can expand the solution to cover other payment integrations such as SEPA.

The next time you’re considering whether or not you should automate an area of testing consider the nature of the tests. Do they use complex UIs? Do you have to repeat very similar tests over and over again? Do they currently take up a large portion of your testing cycles?

Try to automate the hidden process which run over and over and you wished you could test every time if you had the time!

Why you MUST run your Unit Tests as part of your Build Process

I was browsing StackOverflow the other day (as many geeks are known to do from time to time) and read an answer which describes writing Unit Tests as being like going to the gym. Now, I’m not sure about the final few sentences about finding another job but I do really like the analogy. It’s hard when you start out but the more you do the easier it gets and the more value it adds.

Now, like going to the gym there are couple of fundamentals which if forgotten can undermine everything. Unit Tests don’t require proper warmups or cool downs but they absolutely, definitely, must be run on the build server for their real value to be exploited.

Let me explain why.

Developers are often hackers by nature, we install different things and experiment. That’s what makes us good at our job, it’s also what makes every developer’s computer slightly different so software which runs on one machine could behave very differently on another.

What’s worse, if your developer is in a rush or having a bad day they may completely ‘forget’ to execute the tests before committing code. Now, instead of vigorously tested and proven code being added to source control you’ve got a risk.

Tools like NCrunch help reduce this but the only absolutely foolproof way to ensure that all your tests are executed and passed before deployment is to get your server to run them. Missing out this vital link means you’re opening your build and deployment process up to human error, something you should be very nervous of doing.

Almost all build servers have the capability of running tests so dig out the manual and make sure that when the tests fail, the build fails!

The Phoenix Project Book Review

I recently read The Phoenix Project, the definitive and often referenced DevOps Business Novel by Gene Kim, Kevin Behr, and George Spafford.

I have to admit I’ve been putting off reading this book, perhaps I had some misgivings about replacing Scrum techniques with the new craze of DevOps. Having decided that I was going to invest my time I was tested once again when I realised that Bill, the book’s main protagonist is an infrastructure guy… I’m a Development Manager, I want to know what DevOps can do for do for me not what I can do for the other guys!

That however was the last time I paused before devouring the remaining 370 pages.

Bill’s first few days after his promotion are littered with disasters. He has a project to deliver, infrastructure problems to resolve, and political ambushes to endure. In other words, he’s in the situation we’ve all experienced when teams aren’t communicating and colleagues are so stacked up with their own projects and priorities that they simply can’t assist each other.

With the timely arrival of Eric, the new potential board member Bill slowly equips himself with the tools he needs to resolve his infrastructure headaches and get the Phoenix Project back on track. Eric, acting as a kind of DevOps Yoda helps Bill gain an understanding of the four different types of work, the Theory of Constraints, Systems Thinking and see the value of Automated Deployments.

There’s a nice appendix at the end which helps consolidate the ideas and explains some of the ideas away from the story. There are also some mind blowing statistics about how some of the big web companies such as Amazon, Google, and Netflix.

So would I recommend this book to others? Absolutely! In fact I have, repeatedly to friends and colleagues! Whether you’re a developer, infrastructure guru or IT manager this book will introduce you to several new ways of thinking about workload management and IT processes.

DDDNorth 2016

I was very excited when I saw the announcement of DDDNorth earlier this year. I’ve attended the conference several times before and to see it was once again in Leeds really gave me no excuse not to attend!

Despite having a rather late night the previous evening I was one of the first there, in fact I think I accidentally tailgated a speaker inside and sat quietly in the corner until the masses arrived.

For those of you who don’t know the DDD events are free, one day conferences focused at .NET developers. They’re held around the country and have a very high standard of speakers. DDDNorth is our annual event and usually circulates between the Universities of Leeds, Sunderland and Bradford.

The first session I attended was “Machine Learning for Muggles” by Martin Kearn and it was one of the best geeky talks I have ever attended.

Martin demonstrated how to use the Azure Machine Learning API to upload your own data for analysis. He then took a photo of the audience and used facial recognition and text analysis to ask questions like “show me the happiest person”. Before today I’d always assumed machine learning was only for the likes of Google, before the first coffee break I was already wondering whether I could use the APIs in our own products.

The second session I attended was “10 More Things You Need to do to Succeed as a Tech Lead” by Joel Hammond-Turner. I’d attended one of his talks before (entitled 10 Things You Need to do to Succeed as a Tech Lead) and with my recent change in role I felt it was a wise choice session.

I was right. Joel gave us a good list. It contained tips on requirements, instrumentation, and team training. I was particularly impressed by his thoughts on managing and measuring technical debt!

The last session of the morning was “You read The Phoenix Project and you loved it! Now What?” by Matteo Emili. Having recently bought and demolished TPP while on holiday this was the session I was perhaps most excited about. Matteo argued for pragmatism, he told us that in order to sell process changes the value must be determined. He quoted the common phrase “you can’t manage what you can’t measure” and discussed in depth how you should use the Build-Measure-Learn. There were even a few tips and ticks towards the end to help us get our automation deployments going!

It was lunchtime, which meant sandwiches and GROC talks (I have always been curious to know what that stands for).

I arrived in time to see a few interesting mini-talks. The first was on using the C# interactive window in Visual Studio, the second was around ARM templates for Azure, and the final one was entitled “What’s the Point of Microsoft?” and was a tongue in cheek presentation about how the big tech players compete in today’s software and hardware world.

I’d love to continue, I’d love to tell you about the Microsoft BOT API talks I had lined up for the afternoon. Alas it was not to be, it was around this time that the office called to tell me that several hundred members were having issues with their accounts. No rest for the wicked!

I’d like to take the time to thank the DDDNorth team for putting together yet another fantastic event. The speakers this year were superb and if I get the chance I fully intend to catch the sessions I missed elsewhere in the country at a later date. See you next year!