Time and again we hear this question. Being a custom application developer it’s difficult to have an unbiased opinion. That said we always try to give our clients and prospects the answer which is best for their particular situation. Generally that question can be answered after evaluating what the client is trying to achieve.

We want our own product to sell

If this is the situation then 99.9% of the time the answer is yes. You’re going to have to build your product. One thing we work through with our clients is “Are there reseller agreements available that would get you where you want to be OR is it more important that the product be owned and controlled by you?”.

We don’t like our current application that performs X, Y and Z

A large number of our clients fall into this category. There are some significant gains available by creating a custom application. You have the ability to streamline software to work the way you do. The question we always try to help our clients with is “Will the gain justify the development and ongoing cost of the application?”. The gain can be man hours, new functionality that doesn’t yet exist, the ability to sell a new product or the ability to sell an existing product via a new channel. In any case it’s important to identity and measure the expected gain to determine is it necessary to replace my current application.

When making the decision to develop a custom application it is important to consider why so much as how. Historically price keeps quite a number of companies from developing their own custom application/solutions. In reality if the company truly needs a custom solution the upfront costs are greatly outweighed by the benefits that are had.

We as developers sometimes forget that the typically end user does not think like a programmer. If the user did, we’d have stopped progress the user interface at with the command line. Users like an app that is easy to use and just works. Apple as a company has been very good at getting users to love their products. Why? Because their user experience is simple and it works, performs just as advertised.

What does it take to make an app that works? I believe it all boils down to testing.

User Experience

Most applications developed have a user interface of some sort. The user interface can be a command line, a web application and actual client application that is installed on your desktop (who writes those any longer?). All have one thing in common, the user interacts with the application through this interface. This user interface is the most visible portion of your application, and therefore to the end user the user interface is your application. It won’t matter if your application contains the most eloquently written routines, not a single line of code duplicated anywhere, comments to explain perfectly what the code is doing; none of that matters to the end user. If the user experience is terrible so is your application.

How do you make a good user interface? Test it! I’m a programmer by trade, my user interface development skills are terrible to say the least. I’m no good at coming up with a UI the user loves right of the box. However I’ve discovered that iterating through several different designs with a few potential users I can quickly develop an interface a user will love. To test your UI:

1. Develop the application with a rough draft UI. You don’t have to spend weeks laboring over getting the first pass just right. Just include the functionality necessary for the application and continue to step 2.

2. Put it in front of real users or at least find some friends and family who don’t have the same understanding of the application domain that you do. Give the testers specific tasks and see how they fair. Make note of any problems utilizing specific functionality and make notes about what the testers are able to figure out quickly as well.

3. Review your problem notes from step 2, think about solutions and change your UI to address those problems. Go back to step 2 and repeat until you AND your potential users are happy.

Functional Testing

So you’ve got a user interface that your users will love. What now? Make sure it works! It’s very important to ensure your users will love your software, it’s equally important to be sure your application will work as it’s designed. If you’re following any sort of formal development process you should have a requirements specification. Utilize that specification to create automated and/or manual tests.

Automate as many tests as possible. You should create a full suite of tests that can be be run following each major change to prove your app still works.

In situations where you’re unable to create an automated test, create a documented testing plan. This documented plan should include details on the feature being tested, steps necessary to execute the test procedure and clearly define the result the constitutes pass or fail. Just like the automated testing run these manual tests with each major change in the application.

Testing, when done properly, is time consume and worth every minute spent to ensure you find any bugs before your users do.

Too many times I’ve seen developers spend a ton of effort building an application, getting the feature set just right, adding additional features (see previous post on keeping it simple), etc.. then launch the application and assume all is well. These are important parts of application development indeed but building the application is only the first step. Launching and support of the application are the most visible tasks in the process and also can be the most difficult. Building software is easy, building good software that is supportable and maintainable is hard.

The good news is there are several ways to make the lives of your users, your clients, your support staff and any other individuals who may have to support your applications easier.

• When your application breaks it should break loudly! No this does not mean you should just dump a ton of error information to the screen for your users to read. No one wants to see that. What it means is you should put together a nicely formatted error page, clean up the error if you can or show a generic error to your user. Make it perfectly clear that something went wrong with your application but present it in a way that the average user can understand and won’t think the world is coming to an end when they see the error page. You should not try to “gracefully” recover from most errors, especially those where there is no real recovery path only attempting the same action again.
• When your application breaks tell someone who can fix it! You’ve notified your user that something went wrong. That’s a good start. Now you need to tell someone else who can fix the problem. At a bare minimum an attempt should be made to email support staff. In several of the applications SDP has developed we’ve also built an administration console that displays in real-time any application errors that have occurred. Support personnel generally spend the day with this console open so they become aware of any errors within minutes.
• Logging, Logging, Logging! When something breaks you have to be able to determine what exactly caused the problem. In a production application you can send a message to the end user “Here is the problem please contact support and give them error code blah blah blah…”, try to include that information in an email to support or utilize the tried and true practice of logging. Of the 3 I believe the best option is to enable logging whenever an error occurs and be very very verbose in your logging. If you’re logging error information correctly you should be able to determine a) where in your application the error occurred and b) exactly what state the application was in at the time. That said don’t start recording additional data just because it may be needed at some unforeseen point in the future. There are some nasty side effects that come with recording too much information, most notably it is very easy to make your application drag like molasses. So when logging capture lots of information about the error and ignore logging when the application is running along just fine.

It’s important to know what will become of your application after you’ve developed it. Just keep in mind that building an application is just the first step in the process and you’ll need to plan for those individuals who will be taking on steps 2, 3, 4, etc…

Lately at SDP we’ve taken ownership of a number of projects developed by other individuals or companies. Most of these projects are in production or are near ready for production. When taking over a codebase we perform a short requirements session with the client to ensure we understand the whole of the project and then we perform a thorough code review. One of the things we’ve noticed is a lot of the projects we’ve taken ownership of have extra features that are not used by any of the clients users. These extra features can quickly add up to hundreds if not thousands of lines of code we end maintaining. Upon further investigation we’ve found in most cases that either the client or the previous developer decided these features would possibly be used so the features were included in the final product.

As software developers our goal should be to build the simplest feature set necessary to accomplish the goal, don’t code for what may be needed, keep all features as simple as possible while still meeting the clients need. Focusing on simplicity allows us to deliver what could be complex projects quickly and accurately. We’re not saying remove the all the killer features from a piece of software just to achieve simplicity, but do focus on making sure each and every feature provides some value to the entire project.

The next time you’re working through a requirements meeting continually ask yourself and the client “Is this feature absolutely necessary?”, “Does this feature provide value to all potential users? Or is there a single stakeholder we are trying to make happy?”. Making sure you focus on simplicity will make your chances of project success much higher and your client much happier.

One of the challenges we run into developing software is the changing of priorities throughout the development cycle. The only projects I’ve seen that do not suffer from changing priorities are those with only a handful of requirements that are all necessary for deliver. But given a project of reasonable size and you can feel assured that at some point the requirements priority order is going to change.

How do you handle changing priorities and keep your projects on track? Simple, communication. Make sure you’re development cycle for any project completely visible to your customer. A good method, and just happens to be the one we utilize, is maintain and work from “The List” (as described in Ship It!). The short version of the description is keep a list that is the single source of all project requirements. Keep this list ordered by priority with the highest priority first. ALWAYS be working on the item(s) at the top of the list.

At SDP we try to review and prioritize (if necessary) our larger projects at least every 2 weeks, more if the client has an unscheduled need. There are a lot of tracking tools available to keep up with your requirements. Overtime we’ve developed our own internal system with notification and an approval process that allows SDP employee’s or customers to change the priority at any time on a project. Developers and project managers can then take action as necessary.

Track your requirements and priorities using any method you are comfortable with. The key is to stay on top of the important requirements and communicate with your customer to ensure you understand what requirements are most important at any given time during the project.