The Access Wizard Newsletter Tips, Tricks, and Traps for Access Users and Developers
October 2010

Ten Questions to Ask Before Hiring a Database Developer - Part 2

This is the second in a two-part series of questions to ask before hiring a database developer. As part of a long-term relationship, you want to make sure you get the right person on board. Now on to questions 6 - 10.

In this Issue
  • Tip of the Month - Bottom Line when Hiring a Developer
  • 6. How much time do you spend talking and meeting before starting to code?
  • 7. What do you do when you get stuck?
  • 8. Who will do the actual coding?
  • 9. How do you track changes and additions to the original requirements?
  • 10. What do you to do make the software flexible?

  • 6. How much time do you spend talking and meeting before starting to code?

    You want someone who will give you an unexpected answer. If he says "I have an initial meeting and then jump right into coding." It's time to smile politely, say "Thank you very much," and move on to someone else.

    Time spent at the beginning of a project to understand the problems that have to be solved, appreciating the unique challenges of your organization, and interacting with the folks that will be using the software, is a valuable investment of time and effort.

    Decisions made early in the software development process have a magnified impact downstream. You want to make sure the person that you are hiring has enough knowledge to ask the right questions in the beginning, so that there are few surprises late in the game. It is these surprises discovered towards the end that are the most expensive to fix.

    7. What do you do when you get stuck?

    I would suggest that there is really no right answer for this question because each problem presents different challenges. But you want to make sure that the developer does not always have the same approach to solving every single problem. You want someone who can reach into a tool bag and pull out a variety of instruments to help with the problem.

    If your developer says "Sometimes I just drop the problem and come back to it later" then you know you have someone with experience. Psychologists tell us that problems can be solved in a variety of ways, one of which is to not think about it consciously. If the developer has discovered that dropping a problem and letting it simmer in the background of his unconscious is a workable approach, then you know he's been down the road and has experience.

    8. Who will do the actual coding?

    If the person you're talking to is not the one doing the coding, then you really don't know what you're getting. I once worked on a project where the President of the software company made a magnificent impression on the customer. He convinced the company that his team was able to meet their needs on time and under budget.

    He was a great salesman - very impressive. However, the people that were doing the coding were not talented. Worse, he did a poor job of communicating with them; he was too busy recruiting new customers. So his team built mediocre software that really didn't meet the needs of the customer.

    Ideally you want to be talking to the person that is doing the coding. If the project is large enough that it requires a team of coders then make sure that you are talking to both the project manager and the lead developer. The lead developer may not be nearly as polished as the others, but he is the one that will be guiding the development team, and you want know that he has reasonable communication skills and that he is someone you can work with.

    If the person selling the software doesn't want you to meet the development team or who can't let you meet the development team because they're in India, it's time to find someone else.

    9. How do you track changes and additions to the original requirements?

    No matter how good your specifications, no matter how comprehensive the meetings at the beginning of the project, inevitably new issues will crop up as the project gets underway.

    You want to make sure that there is an organized method for tracking changes and enhancements. In many cases, this list of changes and enhancements will be long and complex, and keeping track of them all can be quite challenging. Taking notes during a meeting to keep track of these is an acceptable start, as long as each change or enhancement makes its way into some organized system for recording that they are needed. The tracking should include priority, details, and statuses.

    The system could be as simple as an Excel spreadsheet. A better solution, of course, is a database designed to track these enhancements. You want to know that you can pick up the phone and get a status report of all the open items so that you can have a sense as to where the project is at any point in time.

    10. What do you to do make the software flexible?

    Some developers will create code that exactly meets the specification. They are looking to meet your initial need and then force you to come back to them every time something changes. I'm happy to report that these developers tend to go out of business because their customers are not happy with them.

    What you want to hear is that they are making an effort to put as much power into your hands as possible. As things change, they want you to be able to make as many adjustments to the software as possible without having to come back to them. Look for things like dynamic list management, and a dynamic reporting engine.

    The best developers get more joy out of development than out of maintenance. What they try to do is create long-run, satisfied customers. They do this by setting up systems that customers can maintain to some degree by themselves. This isn't to suggest that there is never a need to call a developer back in. Just as the car needs an oil change periodically, software does need some maintenance. However, you want to be comfortable that the developer is creating software that meets your long-term needs, and that he has your best interest in the forefront of his mind.

    Tip of the Month - Bottom Line when Hiring a Developer

    Keep in mind that hiring a developer is going to be a long term relationship. There are two things you want to make sure that you're comfortable with. The first is chemistry. You want to feel that you can work with the developer; if you don't feel comfortable with him, you won't have fun along the way, and he won't do as a good job as possible.

    Second, as you begin to reach your decision as to whether or not to hire someone, check your gut. If you have a good feeling, go ahead and pull the trigger. But if you're having a bit of a queasy feeling, keep on looking. The relationship will be a long and you want it to be good.

    Quick Links...

    Custom Software Home

    Access Wizard Archives

    Our Services

    Join our mailing list!

    Custom Software | Copyright Custom Software All Rights Reserved | Westford | MA | 01886