Rules for custom software

  1. Custom software should enable your core business. There are countless software packages on the market serving common business functions. It makes no sense to invest in expensive custom software if it is not driving your bottom line. Successful custom software projects will enable your business to do more of what it does best. A consultant should help you evaluate where using custom software makes sense and offer off-the-shelf alternatives if an appropriate solution already exists.
  2. Custom software pays for itself. You should be able to quantify your expected ROI before signing a development contract. In some cases this is easy to do: software that increases throughput, helps win additional business, or directly generates revenue in some other way can easily prove it’s worth. In some cases the payoff of software is less visible: reduction of employee time spent on overhead tasks, elimination of human error, or even increased employee morale can all result from better software. I believe a successful project should deliver at least 3X ROI in the first year after implementation.
  3. If you’re being charged by the hour, run like hell. There is an Ed Kless quote I really like: “If you aren’t good at what you do, charge by the hour.” A qualified developer who is genuinely interested in your business’s success will take the time to understand your situation, identify potential roadblocks, and design an effective solution that fits your budget. Based on their past experience they will be able to provide an accurate quote or fixed price agreement for the project.
  4. Custom software requires maintenance. Just like Microsoft regularly releases updates to Windows and Office, custom software also requires periodic care to address bug fixes, changes in business processes, and changes in 3rd party APIs. As part of a development contract, your software provider should provide a retainer to address issues such as bug fixes or user support questions. Information about future maintenance costs should be included as part of buyer education before you sign a contract.
  5. Custom software should be agile. It’s all too common that a consultant shows up, listens to your problems, and then disappears for months to code up a solution. When they return, it’s inevitable that somewhere there was a miscommunication and the software does not exactly fit your business. Efforts to modify the software result in expensive change orders. A reputable consultant should engage the buyer and end users regularly during the development cycle to discover misunderstandings as quickly as possible. Minor changes which do not affect the development schedule should not incur additional cost.

The future of IT spending

I just saw this on another post and wanted to share it here as well.

Recently the vice president of Gartner India said, “CIOs are soon going to be an endangered species in the new digital business era.” The primary threat: business units are increasing acting independently. 38% of IT spending is currently outside the IT department and that number is expected to be over 50% in 2017.

Why are businesses abandoning IT? Likely because few CEOs see CIOs as technology evangelists. Traditionally IT departments have guarded technology decisions as too complicated and favored systems that require frequent IT intervention. With the rise of cloud-based SaaS services, business units are finding solutions outside their company.

Gartner’s advice for a CIO watching out for their job: have frequent contact with the other business unit leaders and listen to their needs. Present feasible options to the business and when they’ve made a decision and be the champion to roll out the solution. There are still many factors you should have influence over including the security of proprietary information and compatibility with existing systems.

Source: http://www.cio.in/topstory/cios-are-becoming-endangered-species%3A-gartner-

Case Study: Saving employee time by migrating error prone Excel spreadsheets to custom software

Before the financial crash in 2008, I was working with a commodity brokerage to develop a suite of internal compliance and automation software products for their back office. This company utilized a large number of spreadsheets in carrying out the trade settlement process. In this case, they were creating a separate spreadsheet for each trade. We’re talking hundreds of trades each month. These trades were structured so that if the market price moved above or below certain levels, the behavior of the trade would change. At month end, an employee would open each spreadsheet and enter each day’s market price and range for the month. The final settlement quantity and prices would be copied from the spreadsheet back to another trade management system. This was a time consuming process, taking approximately 80 hours per month. Due to the time constraints and lack of understanding of the complex math behind the spreadsheets, nobody in the office was routinely auditing the process.

In talking with the back office employees, we learned that this was one of the most dreaded tasks and it kept the entire team in the office for several evenings each month-end. They had developed several techniques for splitting up the task to optimize copy-pasting settlement data into each spreadsheet.

The solution my team built was an application which imported the active trades from the other system each day, listened to live market data, and posted periodic updates back to the other system. Whenever a critical event occurred, we could now alert customers in real time. Trades which had unusual behavior or could not be reconciled with the other system would be summarized in a report to senior back office personnel. The dreaded 80 hour a month process was converted into a task which only required the attention of a manager for a few hours to resolve the mismatched trades over the course of each month.

During the rollout of this system, we backtested it on previous data. To the surprise of everyone, we discovered six figures worth of over payments to customers. The copious copy-pasting and lack of auditing had let human error accumulate. We now know this won’t be an issue going forward and is an additional huge cost savings to the firm.

I’m very proud of this project. It involved learning trade pricing rules which really clicked with my inner physicist geek. Beyond the original time savings from the project, it was also a huge morale boost to the employees who no longer had to sacrifice their evenings to reconciling spreadsheets. Due to the success of our project, my team became the go-to consultants for several more automation projects within this office.

Installing Meteor

These instructions will assume you are running Mac OS.

Getting started with Meteor is very simple. Everything can be installed from the command line.

Install Node

You can download node by going to http://nodejs.org/ and clicking Install.

Launch Terminal

Find Terminal in your Applications folder and run it. You’ll use this a lot so pin it to the dock.

Install Meteor

At the terminal prompt, type

$ curl https://install.meteor.com/ | sh

That’s it!

Install an editor

I’ll probably be trying out several different editors, but to get started I’m using Atom.

Install Git

I use git and GitHub for source control. You can get an installer from http://git-scm.com/download/mac. I won’t go into detail about Git. There are about 10,000 tutorials already. I recommend the GitHub tutorial.

In the next post we’ll create the default Meteor project and walk through each line of code.

Hello Meteor!

After 10 years in .NET land, I’m trying out something a bit different. I’ve been watching Meteor since the original announcement, but this is my first dive in. There are several things I’m really excited about in Meteor:

  • easy real-time collaborative UIs
  • reactive HTML templates
  • MongoDB
  • the active community

My background includes ASP.NET WebForms and about 5 years with ASP.NET MVC. I’ve been using REST/JSON APIs and Knockout extensively for the past several years, but never dove into real-time applications. I’m already quite familiar with MongoDB so when I started looking for a framework for quickly mocking up applications, Meteor jumped out as a great fit.

In this blog, I’ll be writing about my experience with Meteor, writing how-tos, and hopefully contributing something useful back to the community. I was inspired to start writing by Ciara’s intro post at Meteor Academy. I hope I can get some constructive feedback as I experiment with application architecture and become more familiar with the Meteor paradigm.

Let’s get started!