0 Comments

This blog typically focuses pretty heavily on technical problems and their appropriately technical solutions. This is pretty normal for me, because I’m a software engineer and I like technical things.

Also, they are a lot easier to write about.

At some point you have to be mature enough to realise that software is expensive to both write and maintain, and you can provide significant value to your organisation by acting as the devils advocate whenever it looks like the solution to a problem is to write some software. Maybe the best solution doesn’t actually involve writing code at all.

If you picture yourself as just a developer (or code monkey), then doing this can feel a bit weird.

If you focus on solving problems though, its a natural extension of what you do.

Sometimes The Planets Align

Now for a more concrete example, because otherwise its all rather academic.

We’ve just embarked on a project to consume the users of another piece of software, giving them access to our new SaaS offering and moving them away from the legacy desktop software that they are currently using.

All told, there are a few hundred distinct clients to be eaten. Not exactly mind boggling numbers, but they represent a decent chunk of a particular market, so there is a lot of value in snapping them up.

Which is exactly what our competitors have been doing for longer than we would like to admit. That few hundred users was significantly higher late last year, and continues to drop at a relatively alarming rate.

Now, in our industry, its not just a matter of getting the client a copy of the (or login to) the software and then calling it a day. Users want all of their historical data to come along for the ride, so there is a significant push to support robust migrations from a variety of competitor software into our new platform.

We already have a migration tool that automates a migration from our own legacy software into the new one, so it could reasonably be extended to support another, similar migration.

But should we?

What we’re looking at here is a good case for not writing software at all:

  • The shelf life of this particular migration is limited. There are only a few hundred customers, and that number is not going to get any bigger as no new users are being added to the system
  • We have a limited amount of time available. The burn rate on the customer pool is ridiculously high, so the longer we wait, the less the total value of acquisition

It will take a certain amount of time to delivery an acceptable automated migration, and that amount of time could very well be long enough that the total pool of available customers diminishes to the point where its no longer financially feasible to chase them. Not only that, but once that pool of customers is empty, this particular migration has no value at all.

Now, there is a point in favour of developing migration software incrementally (i.e. migrating part of the system in an automated fashion and other parts manually), but there is also merit in simply hiring a bunch of dedicated data entry contractors and using the software development capability to build something that has more value over the long term.

Like a migration for an active competitor.

We still haven’t made a decision about this particular fork in the road yet, but it could easily go either way.

What Do You Do For Money Honey

Sometimes the situation is not quite as simple though, as you can find yourself in a situation where someone else has seemingly already made the decision that software should be written, and you need to convince them why its not a good idea.

We had a situation like this relatively recently, where the business had signed a contract with a third party provider of a communication service in order to complete a feature of some sort.

There was capacity remaining in the terms of the contract though (i.e. unutilised capability) and it was costing the company money for no benefit, so the idea was to augment or replace similar functionality already available in a piece of legacy software in order to make use of it.

This involved a significant amount of work, as the new provider’s functionality worked very differently to the old one, and had additional limitations.

In the end, we railed against the project and proved (using math!) that it was not financially feasible to spend a whole bunch of money on development in order to save less money elsewhere, especially when taking into account the different feature set available through the new provider (which would have required a parallel implementation as opposed to an out and out replacement).

Sometimes the best option is to not do anything at all.

Keep That Analysis Arm Strong

Both of the examples above relied heavily on our ability to perform solid analysis of a situation and then communicate the results of that analysis in a language that the business understood.

Usually this means money, but sometimes its also a matter of time. Interestingly enough, money often comes back to time anyway (we can spend $X on this, which equals Y months), and the time one is sometimes more of a question of money (how long can we sustain development at this burn rate, how much money will we gain/lose based on these timeframes, etc), so the two are intrinsically related.

The hardest art of the analysis for me is dealing with the time component, which usually means estimates. You can bypass this a bit if you’ve got an established team, because you can probably project from work that was done previously. If the nature of the new work is different, you can apply a fudge factor of some sort if you think it will help, but make sure those factors are clearly communicated in the analysis.

As a final point, don’t make the analysis complicated just to appear more comprehensive or smart. Say exactly what you need to say and no more. Present the facts and let them speak for themselves, even if you don’t like what those facts say.

Conclusion

Honestly, its really hard to not write software when its what you actually want to do.

In both of the examples I outlined, I could have happily directed a team of people to develop a software solution that would have met the requirements at hand, but it would have been irresponsible for me to do so if I honestly believed that there were better options available.

The hardest part in this whole thing can be convincing people why you should not be doing the thing that they ostensibly hired you to do.

This is where its important to be able to speak the language of the business, and to be able to deliver well analysed and supported information to the people who ultimately need to make the decision.

Of course, sometimes you don’t win that particular battle and you have to write software after all.

Which is a pretty good consolation prize, because writing software is awesome.