Archive | June, 2015

Why Your Org Should Develop Software

11 Jun

If only there was a way to move this to here and make this load automatically in there and all I have to do is press a button, then I could get straight to the part of my job that requires personal attention and knowledge and not have to keep doing the same ten steps over and over.

I hear this a lot. When someone has been in a position long enough, they quickly discover routine tasks that could be automated or ways to make them more efficient. What started as a desire to simplify my job and not waste time performing rote tasks turned in to a career out of writing simple applications to make everyone’s routine tasks easier.

This worked well for me in small companies that lacked resources – and were forward thinking. They didn’t know python from perl and didn’t care. They knew a task that took days now took hours – with no money being spent – and that was enough.

Enter the large organization.

The large organization buys its applications. They have accounting software, web servers, databases, Cognos, SharePoint, and GIS applications. When you have a task that needs to be accomplished, you use one of these applications. If you can’t, go buy something that will.

This line of thinking results in inefficient workplaces.

Joe needs to grab a field from a database and put it on a website. Great, our organization has software for that – Cognos. Does Joe really need a massive Cognos report to display data that really only takes 3 lines of code?  No. So what are his options? Build it or buy it.

These daily tasks that are needed by individuals are often too specific to be solved by off the shelf applications and also simple enough that they could be built in house – the sad part is they aren’t.

The Case Against In House Development

In house development is prevented for a variety of reasons. My favorites are:

Who will maintain it?

  • We can’t have an employee wasting time fixing applications, that costs money.
  • When the employee leaves, who will maintain it then?
  • When we need updates, who will do it.

What about security?

  • In House applications are not secure.

Who is accountable?

  • If we buy it, we have someone to blame when it all goes wrong.
  • We have someone to sue if something goes wrong.

The Case for In House Development

These reasons for not pursuing in house development seem reasonable enough, but we need to examine them and the alternatives.

Who will maintain it?

You need someone to maintain it and it should be your in house development team. It is not a waste of money. If the application results in efficiency gains, they need to be measured with the costs of building and maintaining the application. Who maintains vendor applications? The vendor. But do they maintain it for free? Not always. Need something fixed in your application because you got rid of your image server for ESRI Rest and now your vendor applications don’t work? Too bad. You broke it, not them. Pay, and maybe they will fix the application for you. Did you upgrade to IE 9 because of another application and now your primary doesn’t work. Oh well. Your vendor doesn’t have an IE 9 version yet. If you need a new feature, will your vendor add it? Will they charge you for it? What if your vendor discontinues the product? No support for you – unless you buy the new version or application.

What about security?

I hate this argument. I understand that you have no confidence in your in house developers but to think that because a developer works for a vendor somehow makes their applications more secure is absurd. Let’s just assume that they are more secure for now. Security is measured in what we know today.In 1995, developers were not thinking about SQL Injections. Their applications were secure – as far as they knew. Time proved them wrong. While many rewrote them, we still find these insecurities today. The point is, as technology changes, we see new security holes. While you can protect yourself with what you know today, protecting against the future is difficult. And if you need a fix, will your vendor provide it quickly and cheaply?

Security is not a function of company size and reputation. Microsoft produces software that has numerous vulnerabilities. Of course their software is huge, but so is the company. ESRI ArcServer 10 is subject to cross site scripting vulnerabilities. ESRI has no updates for 10 so you need to buy a newer version. But I haven’t been using 10 for very long and my budgets are tight. Can’t I just get a patch? Nope.

Software is hard and hackers are looking for ways to exploit it. You can code with what you know to be best practices but the key to security is fixing known issues as soon as they arise – not waiting on purchasing to approve a contract for a fix – if your vendor has got around to writing one.

Who is accountable?

Organizations like to be able to point the finger at someone else, but this doesn’t make you function better. If you are a government and are providing a service that doesn’t work, the public could care less who built it, they just want it to work. If they find out you paid a large sum of money for the complicated, buggy, requires a plugin application they are using they are going to be more upset that their tax dollars when toward it.

Go ahead, pass the buck, but your users don’t care. They want to get their jobs done, or interact with your organization. And if it has your logo on it, it’s you even if you didn’t build it. So if you are going to let a vendor control your image and reputation, good luck. At least you can spend even more money to sue them when it fails or when they lose all your customers social security numbers.

One word for you: Healthcare.gov.

The feds paid millions for a website that was a complete failure. Nobody cared that the government didn’t build it. The government got the blame for hiring an inept vendor and for spending millions and getting nothing. Can you name the vendor? No, because even you don’t care – it was the governments fault. In response to this fiasco, the feds started 18F and the US Digitial Service – in house developers. But your organization doesn’t need developers because you’re special.

 

The best software is software you use.

The best software is software you use. Basecamp is a popular project management application that started out as the developers internal project management app. They wrote it for themselves. Now, over 15,000,000 people have used it. Git is another example. Git is a revision control system that was developed by Linus Torvalds for his work on maintaining the Linux kernal. It is the most widely used software management system.

Your organization knows what it needs. If it can build it, you will be better off. I am also a realist. I do not think you should build everything. But for the small tasks that make everyone more efficient, why not?