8 June 2015 Comments Off on Great Ways to Increase the Cost of Your Software General Software Development
Author: Jason Gillies
After years of writing software I have seen a few areas that are often over looked. These aren’t hard problems to solve. But they do require planning. If you take the time to think through these issues before building your application you will reduce costs for this and future applications.
Don’t manage your data
It’s just data. This is the only app that’s going to need access to this data. So just create it and move on. WRONG. Stop and take the time to think about how this data will be used in the organization. What department is responsible for maintaining this data? How are you going to share this data with other applications? You want to avoid having the same data stored in many applications. Sometimes that isn’t possible. If you have to store it in more than one place, take the time to determine which is the system of record? How are you going to synchronize the data? What constraints are required to ensure the data is clean. Data is the fuel that powers your application. Data issues will have a negative impact on you application.
Build features the users didn’t ask for
Easter eggs are cool. Having them makes your app more enjoyable to use. WRONG. And really I’m not just talking about Easter eggs. Any time a feature is added that isn’t used is wasted effort that increases the cost of the software. This adds to the cost of the software now and in the future. All software has to be maintained. The more you have the higher your maintenance costs. These costs can sometimes be hidden. They can be as small as a few additional seconds that it takes for you software to compile. Or they can consume more memory, disk space and processing power. This unused functionality could break in the future when dependencies are changed. Forcing you to fix or remove the unwanted feature. They bloat your software. Great ideas shouldn’t be ignored. But they do need to get the product owners buy off before you implement them. After all, the product owner is responsible for maintaining the budget.
Any one is qualified to be a Product Owner
The product owner is an easy job. Anyone that knows the business’s needs can fill that position. WRONG. Letting business people who aren’t tech savvy design software is an expensive route to go down. If you find yourself in this position you really need to get super users involved earlier in the process. You should always think through the interface. When your product owner is more of a novice you need to take extra diligence.
Far too often I have seen product owners build software to do what they want done and not follow the current business processes. This usually ends up in required fields the user is unable to populate, or software that requires more interaction than was necessary. Too much interaction can slow the user down to the point of making the software unusable. Think though the users’ day. Is this something they are going to do repeatedly? If so do those extra seconds add up to minutes or hours?
Your software should automate proven business processes and not invent new ones. If you are building a new process, try to test it before writing the software. This isn’t always possible, but it can help increase the chance for success.
We don’t need to define a Technology stack
Our developers should always use the latest and greatest technology. By allowing our developers to choose new technologies for every application we ensure our success. WRONG. There isn’t a golden hammer technology that can solve every problem. I’m not suggesting you don’t let you developers innovate. What I’m suggesting is that you think through what technologies work best for your organization. How will they be maintained in the future? If your developer leaves, will you be able to find another that can support that technology? It’s very hard to keep your skills sharp on a technology you don’t often use. The more technologies your developer staff has to support the higher your maintenance costs will be. Instead take the time to come up with a proven stack. The technologies should be stable, but not out of date. There should be a strong local developer base? If a technology isn’t widely used, it’s likely to become unsupported in the near future. Leaving you to live with bugs or rewrite the application.
Great software isn’t hard to write. But it does take discipline. You need to take the time to think through and plan. Consider the long term vision for your organization when planning a project. Consider how todays decisions will impact future use and maintenance costs of the application. Cowboys and Firefighters are to be revered, but only outside of IT. All software has costs that can’t be avoided. Planning and diligence will help to control those costs.
Author: Jason Gillies
Tags:
