So you are responsible for hiring a team to work on a software application for your company. It’s an application that a majority of your fellow employees will be using on a daily basis. It is a tool that your boss, his boss, all the way up to the CEO of the company will rely on to give them feedback on how the company is doing. Decisions will be made based on this application that will impact the entire company’s health and well being. So are you nervous?
If you go online and search for how to guarantee the best outcomes with hiring a .NET application development company, or team, it seems like you have nothing to worry about. Six questions to ask, 10 questions to ask. There are several blogs relating to this topic. This is the best I have found. And yet, I don’t agree 100% with all the responses to why to ask these questions and what to look for. In addition, there are several other questions I would ask. This is a big decision. Thirty minutes worth of questions is not enough time to determine if a .NET development company is the right fit.
How do you manage your development team?
Development companies have several styles for this. It is usually dependent on the company organization structure. Working with a team that is very hierarchical can be difficult. As a client, an attempt to put the best foot forward and please you will be there. But what will be missing is the close communication with the development team to resolve issues and clarify requirements. Have you ever played the game Telephone? Imagine doing that where the communication has to go both ways. Communication is always seasoned with perception and experience. It is not due to bad communication on the part of the in-betweens. It is just human nature. This is not to say that working with a top down organization is not a good fit. When interviewing, it is important to make sure that you will be able to ensure that all communication is clear and complete.
When working with a more matrix organization, there is more fluidity and more open communication channels, theoretically. This is not always the case, so questioning about organizational structure should be more detailed than just, “what is your org structure?” Make sure that you will have the ability to communicate directly with the development team. Find out what formats are used for communication.
More recently, there are many companies working with a stateside management team and overseas development team. The same rules apply to this model as it does with others. Make sure that you have access to the development team for communication. Find out in advance the most efficient ways to communicate. Also, be sure that there is someone that is there to ensure grammar and spelling are correct throughout the user interface.
Do you use version control?
Version control is a system that keeps track of changes to a file. There are many schools of thought on the best way to handle this with software. But to summarize:
- All code should have a mainline or branch. This is the complete code.
- Branches are taken off of this and worked on (version).
- Team members can pull a branch from the release branch to work on particular tasks/bugs.
- Member branches are checked into the work branch once tested.
- Work branches are tested and checked into the trunk.
- The trunk is tested.
At any point during this process prior to merging to the trunk, the trunk is able to be released. Any changes to the trunk can be reverted and are easily identified. To ensure you do not spend more money than needed, a company that uses version control properly is the best option. It guarantees that when a change is made that is not acceptable, that change can be removed without having a negative impact on the rest of the work done.
How do you track bugs/issues?
Having a good bug tracker, along with a great process in place will save you money. You may wonder why this is important. As long as the team knows there is a bug, they can fix it. There are a couple of issues with this concept. If I were to report a bug, unable to add a new goal for "the week", as the reporter, this makes sense to me. I know on what screen this occurs and the steps I took to get there. If I send this to development, they may look at the code, and not see a problem because it is written to behave as it currently does, as only one goal allowed per week. So what they would assume is that if you go to a week without a goal, it works fine. So, the response from development would be “unable to reproduce”. This would come back to me. I would test it and find the same issue because my expectation is that I should be able to create multiple goals for the same week. And the cycle begins. All of this will be costing you money.
Another issue with not having a good bug tracking system is that there is no way to ensure that a bug has been fixed at any given time, who is responsible for reporting or fixing it, and if code was changed to try to fix it. Without this history, if multiple people are testing your .NET web application, they report a bug. But if there is no tracking system, they cannot know that a specific bug has already been reported. And without that knowledge, there may be two different developers, or three, or. . . working on it at any given time. This not only costs extra, but may lead to confusion when developers try to merge changes to the same fix for a bug.
So what constitutes a good bug tracker and a good bug reporting format? For tracking, the key is that it is clear who reported the bug, what developer it is assigned to and what stage in the process it is in. There should be a way to search bugs in order to find similar bugs or bugs in the same area of the application either currently being worked on or have been fixed in the past. The bug report should include the following information.
- Reporter
- Version it appears
- Assigned to
- Reproduction steps
- Expected behavior
- Date reported
- Date resolved
- Resolution
- How it was fixed
- Code reviewer
- Implementation version
- Screenshots or video of the bug
It is hard to imagine that there could be too much information in a bug report. And the information provided will determine the probability of the bug actually being fixed in a timely manner.
Does your organization use Unit Testing?
Unit testing is the automated testing of small parts of code, based on functionality. These are small tests, added by the developer which are easy and quick to implement. They are great for detecting low level errors in code, but can also have a big impact on the overall quality of the code base. This is done by allowing for easy, quick testing of the code base when changes are made to ensure that other parts of the code are not detrimentally impacted. In addition, writing unit tests force the developer to spend time thinking about how a particular piece of code impacts other parts of the code, thus mentally connecting the code they are working on to the bigger scope of the code base. When you ask the question, be sure to include getting an understanding of their philosophy on unit testing. Be sure they are testing what could go wrong along with what the code should do.
How do you ensure a quality product?
There is never a guarantee that your product will be bug free or designed exactly as you envisioned it. But there are a few things you can do to minimize these. Let’s start with the validation/verification aspect of the process. Design validation/verification answers the questions, “is this what I asked for” and “Is this what I want”. It may seem like a basic concept that what you ask for will be what you want, but this is rarely the case on the first pass. Your requirements document is the key to what you asked for. The challenge is to make sure that it is what you want. Often this comes down to the nitty gritty details of how things are implemented and also looking at functionality you take for granted. So, for instance, if you are looking at passwords, have you specified what type of password requirements you want? How often do you want them to have to be changed? What happens when a user forgets their password? These are details often left out, and thus can be overlooked. Implementation of functionality is also a part of, “Is this what I want”. So you will want to check with your development team to make sure that they let you know in advance any implementation strategy for any functionality that is important.
The other part of quality is the user interface. Are text boxes, widgets, tables, images, etc. aligned? Is there any overlapping objects. Is the user interface well aligned? Developers, themselves, are not always good at the user side of an application. In order to ensure that your application has a professional look, check and make sure that there is a member on the team that focuses on this. It may be the quality person or a graphics person. Either way, there needs to be someone different from the developer looking at the user interface. And that person needs to have a detail oriented mindset.
Finally, there is the testing of the application to ensure there are no bugs. Unit testing is the first step. In addition, use cases of all the different types of users should be tested. This should be done by a QA team that has experience in testing a variety of applications on a regular basis. They need the ability to create use cases for different roles and persona. It is essential that they can easily pick up an application and understand how it should flow for all use cases. They should have a clear understanding of how software applications should work and flow. There should be a basic ability to see if the flow is optimized from a user perspective. As with all of this, the devil is in the detail.
How do you ensure that the output is functional from a user perspective?
When you are hiring a development team for your custom software solutions, you know in your mind what the application needs to be able to do. Either you have a similar application that may be outdated that you are looking to replace or you are wanting something to combine several different applications into one. There is also the possibility that you are using paper to do the job that you are wanting the software application to do. Somehow, you will have to communicate what you need to the development team. What you would like for the team to be able to tell you is the steps they take to get there. Keep in mind, they are writing code. They will not be using the application day in and day out. So it is important that they have checks and balances in place to ensure they are meeting your needs. Initially, a requirements document should be created. This can be created by you or by the team after they have had calls with you to discuss the requirements. This process may take some time and several back and forth sessions. Once a requirements document is complete and approved, a design document should be created. The design document is a detailed description of how the requirements are going to be met. This document is the key to saving you money and ensuring you get what you want and what you need. There is a strong chance that there are things you won’t think to mention when you were putting together the requirements document. Details like password formatting, phone number formatting, etc.
How are changes handled?
This may seem like an unimportant, senseless question. You, as the client, ask for a change, and the development team implements it. But this is where the problems arise. At the beginning of the project you were given an estimate on the work to be done. This was based on a detailed design document. And it is that, and only that work that was estimated. So any change comes with a change in cost. Unless you have a bottomless bucket of money and are not concerned about cost, this question can become very important or very costly.
Most people see the application evolving as the project progresses. New ideas and new features to be added is a natural progression. So, to ensure you don’t get hit with a huge invoice it is wise to have a clear, transparent change control process in place. Ensure that the development team makes you aware of any additional costs associated with the change as soon as the change has been requested and they have had time to research the work associated with it. Depending on your budget, you may request that no changes be made until you approve the estimate. In addition, it is a good idea to find out how any change is going to be implemented. This prevents rework, which is both time and money wasters, if the implementation does not match what you had in mind. The key is to control your budget and prevent scope creep.
Describe your most unhappy client you’ve had and why they were unhappy with the project.
What? Are people going to answer this? If they don’t, then you probably don’t want to hire them. No matter how good you are, no matter how hard you try, you are going to have a few unhappy clients. No one can please all the people all of the time. So, if the development team cannot give you an example, then they are just trying to win you over, without understanding the value in this question. This question is not to find a reason not to hire a team, but rather to determine how they handle stressful situations and resolve potential conflict or issues. So what you want to know is:
- What went wrong?
- How was it handled?
- What was learned?
How it was handled, might not have been right the first time around. This is why, “What was learned?” is important. Also, look for solutions that fit your style of working. “How it was handled” with one client, might have turned out perfect for that client, but for someone else, it might not have been the optimal choice. But keep in mind, with good communication on both sides, the goal is to avoid your project from taking a turn in the wrong direction.
Describe the worst project you’ve worked on and what made it the worst.
This may seem like the same question as a project going wrong, but worst does not mean that the project went poorly (although this may be true). In reality, a project that may go perfectly smoothly, from a project perspective, could still be bad in the eyes of the developer. Its worst project may be because the code was so outdated or poorly written that it made it difficult to deliver the changes the client wanted. It may be because the client took a long time to approve changes. This is another question that the answer can give you an idea about how the team handles difficult situations and also insight into their working style and priorities. The answer should be used to determine if you and they are a good fit.
Who does your design work for the front end?
This question may be irrelevant if you have someone in-house or you’ve hired a separate company to do the work for you. But if not, this is key to making sure that the front end flows well and has the look and feel you desire. Developers are not designers. So, when it comes to flow, look and feel under most circumstances, you want someone with user experience (UX) and user interface (UI) experience. Some teams have an internal expert that they use for the front end. Others have experts they call when required. If neither of these is the case and the development team does it, make sure to get samples of their work. This would be the case with all situations, but it is critical when there is not a UI/UX person involved.
How do you ensure that my application will not become outdated?
The real answer to this is simple, they can’t. It is up to you to keep your applications up to date, unless you specifically have the team maintaining it. So why ask the question? This is a communication and talent barometer. If you have an application in Pascal that you are having updated in Pascal, you are already outdated. If you are starting from scratch and the team is not providing you with current technology, then you will start out as outdated. When mentioning current technology, this does not mean the latest and greatest programming language. But if they are making use of the latest development tools available for their language of choice (Not Pascal) then there should be some concern on your end about their ability to start you at the front of the line with your application.
What information do you need to get started?
This is another question that may seem irrelevant also, but what you want to see is how organized the team is. Do they have a list prepared or do they ask for things one at a time. The better organized the team, the more likely it is that your costs will be contained.
What formats do you use when communicating with the client?
Email, phone, Zoom, Webex, Gotomeeting, Joinme, Google Meet, Slack, on and on. Does it matter which modality is used. There are two things that are key. 1. That there is open communication and follow-up and 2. That it is efficient. Email is always great for follow-up. But there are times when you or the development team may have to go to so many emails in a day, that depending on the time yours is sent, it might take days to even be seen. So, for both, if you have an urgent issue, it is best not to assume that your email has been seen. Pick up the phone and call or better yet, ping in Slack. By the same token, if you send a ping and communicate in Slack, follow up with an email, so that it is easy to go back to the key points later.
For meetings, what is most important is that you are able to record the sessions and they can be easily shared and viewed later. Personally, I like GoToMeeting because it records anyone that is speaking and any screen that is being shared. But other options exist that are efficient and offer the tools you need to communicate efficiently. Finally, I am a very strong proponent of collaborative project management tools. When both the vendor and the client use them, they save a great deal of time on the project timeline. Tasks don’t pile up waiting for the next meeting. Often, a specific task may need clarification on implementation or requirements. A couple of minutes of a response from the client allows the project to move along smoothly. But these tools are only as good as the team and client are willing to use them. I have had clients that respond immediately to any of the queries sent to them and some that don’t respond at all. Needless to say, if you don’t respond to the task in the tool, it is highly unlikely that you will respond in email. This means that a meeting must be held. And until the meeting can take place, the project has a potential of being stalled.
What is the process you have for doing development?
Currently companies are tied up in the discussion of how to best do software development. Is it agile, waterfall or do you use Kanban or on and on? Personally, I don’t care as long as it is efficient, quality is there and changes can be made without serious disruption or loss of time. No matter what method the team uses internally, the key to you is communication and adaptability are there. You want to know immediately if there are issues with your requirements. What is the issue and how can it be resolved? What are the risks with different options? How long will each option take? In everything you are looking for with a team, the most important component is that the team is conscientious and thoughtful. So if a team answers with a specific method, find out why they use that method and what it does that others don’t. But again, it may not be relevant to you as long as they prioritize the key components needed to do the job.
Where can I find examples of your work?
This is a no brainer. No matter how good the developer is, no matter how good the designer is, the pieces must come together create a cohesive application. Seeing samples of their work should give you a clear idea of what to expect from a finished product. Be sure to ask to see samples of different types of applications so that you can see how they are able to adapt. Don’t forget to ask to see an application similar to the application you want them to develop for you.
Can you provide three references?
Of course they will give you their best references. In order to get a more diverse idea of their work, ask for the reference from the client that they referred to with the “project that went wrong”. If they choose not to, move on to the next team.
Who will own the source code when the application is completed?
There is only one correct answer for this. . . YOU. If that is not the answer, move on. You are paying for the application to be developed. It’s yours.
These are not all the questions you should ask. There are things that are unique to your project that you should consider. There are also questions that may be unique to a particular team. Oh, and then there’s the development teams ability to actually write code. That’s easy to determine. Have them do some sample problems. These are available on several sites. The most important thing is that you are comfortable with your decision and communication is excellent.
To learn more about the importance of eliminating human error in your operations, please download the eBook titled "How to Automate Business Process in 7 Smart Steps."
