About Steve O'Keefe

Development Manager at Algonquin Studios.

Consistency is Key!

A successful software development project is one that maintains consistency.

Whenever I visit a site or application that lacks consistency, it makes me uncomfortable. If each page acts differently from the others, it can end up confusing the user and feeling and looking poorly developed and unprofessional. A good development coding standard can help ensure a high level of consistency throughout an application and, once in place, these standards need to be followed. In the end, a good developer needs to make sure his/her final output reflects the standards and is built in a consistent, user-friendly way.

Another reason to adhere to a consistent, standard approach when developing a new application? Without it, the ongoing maintenance of the application will become cumbersome. If five developers are all coding differently, in their own style, you’ll eventually end up with an application that won’t lend itself to easy maintenance and might not function properly in the long run.

Remember, software often ends up being maintained by people who weren’t involved in the initial development of it! If you’ve ever been responsible for the upkeep on an application that was built with little adherence to quality standards, you know—it’s no fun! If the cost to upgrade or improve an inconsistent application becomes too high, it could force the client in a different direction.

I remember supporting an old ASP 3.0 application that was generally using the same connection information in a standard configuration file but had a few forms using hard coded values for the connection information. I couldn’t understand why, all of the sudden, some of these were breaking when my database information changed. This should have been a quick change to the configuration file, but turned out to be a pain!

When building front-end user interfaces, make sure you’re putting on your “end user” hat before you start working. When building out forms, do so in a consistent manner. If you have grids with search results on a screen, make sure all those grids are reporting the same data, and the same options, in the same way. Make sure all dates are displayed in the same format. All numeric/monetary fields should display consistently. Buttons with the same underlying logic should have labels that are consistent so the user can understand, from screen to screen, that button does the same job or accomplishes the same function. Make sure your form controls are organized in a pleasant manner—one that’s easy on the eyes and that can be tabbed through quickly. If it’s a data entry screen that users will be spending hours on each day, make sure the controls are aligned and sized properly allowing users to keep their focus on one part of the screen and providing a better overall user experience.

Before you start developing, take a look around! Review some of the screens in the system—there should be a common theme to the user interface; follow the same approach. Take a look at messaging and make sure you’re reporting information to end users in the same way. It won’t take long to get familiar with the site and then, once you start building your new feature, you’ll have a good context as to what it should look like. When you’re done developing, the new feature should look like existing ones.

One last note when testing your development—people still use IE! Do some browser testing to make sure your site is looking good and functioning well in the major browsers. If you’re only developing and testing only in your personal favorite, you’re not doing a full test. Sometimes, there are specific client requirements for the system you’re working on, so be sure you know what they are before you start. Some internal applications are written strictly for IE. Are there mobile requirements for this application? If so, be sure you’re testing those as well.

In the end, making sure your software development is done in a consistent matter is better for everyone in the long run. It will ensure the end product looks and feels like a well thought-out, professional piece of work!

Advertisements

Know Your Requirements!

Often times at Algonquin Studios, clients ask us to improve on their current software solution. The existing solution is either out of date or it simply isn’t giving the client what they need. For the user, changing systems can be a scary proposition. People grow comfortable with what they are accustomed to however, following a routine that you’ve done for years is the safe route. For this reason, it’s very important to sit back and think about what the system needs to accomplish. We want to make sure we maintain the output they are expecting from the software they use on a day to day basis, but keep an open mind on how to get there. In order to ensure this outcome, we spend a considerable amount of time conducting requirements analysis.

During the requirements analysis phase, one of the most important parts of a project, we determine what exactly the client needs are and how we will provide that solution. Time and again we run into the same obstacle of getting the client to see the difference between “what your users have today” and “what do you need the software to accomplish.” Clients often want everything they have today, in addition to the improvements we will provide with our software. Unfortunately, this could cause unnecessary features to be included in the software and add additional costs into the project going forward (training, support, system complexity … etc.). Costs that could be used elsewhere, either for the company or to build out additional features that are needed in the new system.

So, when coming into these requirements meetings it’s best to come prepared. To be better prepared it’s most important to know what is needed, as opposed to going screen by screen showing us everything they have today. There are many other ways to be prepared for these meetings, here are a couple:

Question your users

As a client, when was the last time you asked your user base about the program they use on a day to day basis? Requirements and business needs are always changing over time. Depending on the size of the user base, and the software being used, these questions could vary (and there are many). In the end, the client should find a way to determine:

  1. Which features are being used the most?
  2. Which features are rarely (if at all) used and aren’t needed?
  3. Is there anything you need the system to do that it doesn’t do today?
  4. Does the system provide repeatable work that the software doesn’t handle, costing people time every day?
  5. Are there current features that need to be revised to accommodate current needs?

There are many ways to gather this data.

Is this software internal, used by only a handful of people in your office? Have a meeting to review the software and gather the information firsthand from the users. Come prepared to ask about features that work and those that don’t. Are there any that have lost value over the years?

Do you have thousands of users using the software across the United States? Setup online user groups and invite people to provide valuable feedback on the software. Depending on the capabilities of your software, you can limit the groups to certain sections of the software and provide questionnaires about those sections. This should help you gather all the necessary information to bring to your developers, so we can make sure we build you an efficient, quality application that suits all your needs.

Clearly Define the Inputs/Outputs

Frequently, a screen can be so overloaded that one loses focus on what exactly is needed. Determine all the inputs of the screen and make sure they are all required and are what you need. Next, identify inputs that are unnecessary or misused. Keep in mind that just because they exist today doesn’t mean they’re needed going forward. Additional inputs only cause more complexity.

As important as it is to define the inputs, it’s equally important to define the outputs. Outputs that are currently delivered may no longer be needed or efficient or may simply be delivered differently in the new software; Once again, this is often difficult for a client to understand. Asking a lot of questions in the requirements meetings about those features can help ease the process because in the end, the more inputs/outputs you have the more complex your system will be. Our team of consultants are really good at letting clients know if the value they’ll receive from a feature is worth the effort and, generally, we can determine this during the requirements meeting.

In the end, if the client does their part in determining what’s exactly needed out of a system in order to eliminate all the old, antiquated screens and logic, the better the software will be. This will ultimately save the client in the long run.

Making a Good “First” Impression

There’s nothing like the old cliché, “You never get a second chance to make a first impression.” In the software development business, this quote definitely holds true. Earning a client’s trust will hopefully happen the first time you meet with them to discuss their problem and work to identify a business solution, but once you gain that trust and come to an agreement to help them achieve their business solution, it doesn’t stop there. There are other points during a project that provide an opportunity to make a good impression, to ensure a successful project, and a great client relationship in the future:

Project Kickoff Meeting

At the start of the project we usually conduct a project kick-off meeting. Sometimes this meeting is with your initial contact, on whom you’ve already made a good first impression (or you wouldn’t have the job), but often this meeting will introduce you to the client contact who you’ll work with throughout the course of the project. It’s important to convey, during this meeting, that you understand the company’s needs and that you’re willing to listen to their ideas, suggestions, and pain points. Here are a few examples of what I do in these meetings to help ensure I’m making a good impression:

  1. Come organized and be prepared. Make sure the client knows that you understand their problem.
  2. Ask questions and don’t assume you know any answers. You’ve got questions for a reason; assuming the answers will ultimately leave you lacking vital information you’ll need later on.
  3. Listen to what the client wants and, if what they explain doesn’t make sense, see if you exlpore new ways of “explaining it” with them. I often have clients draw what they want on a whiteboard. While the drawing might not be an accurate representation of what will be needed in the long haul, having the client take control and talk things out while sketching is a good way to get them to focus on the goals of the project and gives you a great opportunity to gather requirements.
  4. Be sure someone from your team is taking diligent notes that you can refer to after the meeting and throughout the course of the project, making sure nothing gets missed.
  5. After the meeting, send the client an email, summarizing all the details and plans that were discussed.

First Client Demo

One of my favorite things about the software development process is seeing the client’s reaction when you first show off the solution you’ll be providing. Depending on the size of the project, and how many meetings it took to fully gather the requirements, the amount of time between kick-off to the first demo could be months-a lot of hard work goes into the requirements and construction, so you don’t want this first demo to go poorly. Having a bad demo might strip their confidence in you and what you’ve been striving to achieve with them. Here are some suggestions that have helped me ensure a great initial demo:

  1. Manage the client’s expectations about what they’ll see in the demo prior to arriving for your meeting. If you don’t know what to expect, they might be disappointed when that “cool feature” they’re all waiting for isn’t quite done.
  2. Try not to demo something that isn’t believed to be fully developed. Works-in-progress will probably throw errors and not perform to expectation, so save them for next time, when they are done!
  3. Try to populate the demonstration to utilize data that the client will understand. This may seem subtle to the developers, but having the client understand exactly what they are looking at will generate more productive questions and weed out unnecessary ones. If the client is fixated on “Why do all the fields say ‘Testing A’?” they won’t be focusing on whether you’ve accomplished the task at hand.
  4. For each screen or process you review, be sure to ask if it makes sense and take note of the reaction of the customers. It is usually pretty easy to tell from their expressions whether or not they “get” what you just showed them. Don’t underestimate this step-if you go through an entire demo without offering an opportunity for questions you’ve probably lost them.

As you can see, there are at least three different times where you need to make a good “first impression” throughout a project. This idea has been hammered home to me recently in my personal life, as well, as I’ve interacted with two separate businesses where my first impression of them was less than impressive. I thought to myself “Why would I spend my money on a product when I don’t have confidence that my best interests aren’t being considered?” Make sure you’re considering your clients’ best interests when working on projects for them and make sure the impression you’re providing leaves them confident you’re doing just that-putting them first!