How to deliver good software despite organizational challenges

Check here for cross post of this write up on Medium

Introduction

An alternative title of this post could have been — “How to be deliver good software in an agile way in a traditional organization”. But the word agile now days carries lot of baggage. Instead, I would like to focus on a just a couple of light weight things that have helped me deliver decent software in my specific context. (Incidentally though, before the name Agile was chosen, it was simply referred to as a a collection of home grown light weight methods for better software development)

The context referred to here is a typical offshore setup or it could be any organization that is out of touch with new, better ways of software development. Its assumed, however, that your know your technical stuff well enough to write good quality code. The points below are more about how to circumvent challenges at organizational level like inefficient communication, heavy & slow processes, complexity in the information system and so on. The aim is not to fight these problems directly but to find your way around them with the goal of delivering the best you can in the circumstances.

Gather feedback by relentlessly pushing information to users

Agile world often describes this perfect scenario where users of the software work in close collaboration with the developers — perhaps even sitting in same open space, having design discussions daily with rapid feedback cycle and so on.

Frankly, I’ve never seen that happening. In fact, the world I’m talking about is where the chasm between business and developers is so big that you’re considered lucky as a developer if you can even get one phone call with a user in a month. There again you may have communication issues like language differences (calling from Bangalore a Japanese user in Yokohama) or you have multiple intermediaries in between (analysts, managers, architects..) that most of the conversation anyways gets lost in the translation.

Needless to say, it can be disastrous, if you are unable to get any feedback from the future user of the things you are building. The best strategy here is to strategically keep pushing the information —

1. Make beautiful mock ups of pages you are designing and keep emailing to the users. Pro tip — don’t attach the slides in the email as the busy/lazy/”can’t care less” users may not open it at all; instead, put the images directly in the email for better readability. If something is wrong big time — this is the only way the users will notice it and could get back to you. Small things can be resolved later.

2. Request users for demo sessions — at least once a month. Make it a really simple demo of use cases and the related flow. Pro tip — when doing demos use a voice that addresses to their future selves in order to get their attention. For example — “when we go live in prod next month with this screen, you will be using these steps to generate the report for the auditors/executive management”. Anything that reminds them of their skin in the game helps.

Incremental releases to production

This may seem as a common place point in the devops world that’s already on continuous delivery pushing multiple releases to production in a day.

But there are still organizations where projects are huge and it may take more than a year before the changes are validated for production release. For example, this happens when the project involves a number of applications in the information system that may each take months to make the changes; followed by a long duration of different testing phases in each application to finally provide a global validation.

If you work on multiple branches for different projects, it will be a maintenance nightmare to keep up with your specific branch for a year. Despite constant merging of code, the risk of some components being stale when you finally push the changes to prod would keep growing with time.

Feature toggles are your friends in such a situation. Turn off the new (not yet validated) features and keep pushing to production even if overall signoff is pending. Of course, you will have to spend some extra time to ensure your change isn’t causing any regression. Nevertheless, this effort would prove its worth as it helps reduce both — the risk of staleness of your code which may cause regression and constant maintenance of the code branches which is time consuming and error prone.

Pro tip — keep the control of your feature toggle in the database. When, after months of waiting, the users/management will finally wake up, they would demand you to push the release into production, wait for it, ASAP! With a database based feature toggle, you’ll be prepared for it —with your changes already pushed incrementally to production earlier, the final release would be simply an update to the toggle in database

Just like the beginning of this post, let me end it with another alternative title to this post — “When life gives you lemons, make lemonade”. The goal really is to keep doing the best of what your profession has to offer wherever you are.