Software development isn’t magic. There isn’t a black box where you can throw a bunch of ideas and requirements and out pops a smoothly working app that perfectly meets all of your business needs. Once you see that in print, it seems perfectly logical, but because the process is often hard to understand it feels like there is at least a little magic involved.

In this seven-part series, we’ll pull back the covers and eXpose what you should know when you start the hunt for a professional developer for that custom, fix, or upgrade software project. We’ll offer tips to help you select the right developer, discuss pricing models, things to consider when signing an engagement contract, and walk you through the development process from idea to deployment. In this introduction, we offer a brief fundamental overview of what you should understand before you dive into any software development project engagement.

Collaboration

Development is a partnership between the client and the developer. You bring the knowledge of your business, your workflow and your needs. The developer brings the technical knowledge and software eXpertise. Both are equally necessary for development success. The developer should have a breadth of eXperience with various processes and technologies that will give you options to make your solution function smoothly within your workflow. But until you eXplain your business, your developer won’t know the intricacies of what you need. Even if you have an eXisting system, your developer still needs to know how you currently use it and how you wish you could use it.

Knowledge

From the developer’s perspective, it takes more than just a pile of papers, eXcel spreadsheets or a database to look at to understand your business flow. You are intimately familiar with how you do your job, often to the point where you could do it in your sleep. How things should work seems obvious to you. Rarely, if ever, will your developer be able to intuit the things you do by nature. You will have to eXplain it in great detail to make it clearly understood. This means that some things will need to be eXplained multiple times before the picture becomes clear.

One strategy is to treat your developer like a new employee and teach your workflow step-by-step. You don’t have to teach all of the details of your entire business (unless the new application will manage the whole thing), but view the app like a job description and teach that job to your developer. That will make the functionality of the solution clear enough to represent the way you actually do business. It will also give your developer a foundation for making suggestions for improvement

Perspective

When building a full database solution you will end up looking at your business processes with a fresh eye as they go under the microscope while trying to properly eXplain them to someone new. Using development as a springboard, it is common to find things you want to change as you go through your business details.
Software solutions reflect the business processes they represent. If those processes are inefficient, simply moving them from a paper representation to a digital representation will not make the underlying processes more streamlined or efficient. A custom app can make a process easier to manage, but will not fundamentally change it. Knowing this can put into perspective the effect the new software will have. Taking time to analyze eXisting processes with a focus on ways to improve them is a very important part of the development process.

As part of that process your developer can make suggestions for improvements in the efficiency of managing data based on their previous eXperience with data systems. It’s up to you to decide whether the suggestions that come from your collaboration make sense to incorporate.

eXpectations

Once the development process starts the eXpectations on the developer can be a bit high. There is somewhat of an art to software development. Commonly when a feature is described to a developer it seems straightforward and sounds conceptually easy. Then when the developer begins to create that feature within the framework of the application there are often nuances to the feature or its integration into the eXisting database structure that weren’t anticipated. In this case the development time can be longer than eXpected because implementation of the feature ends up being different and often more complex than planned. This can create frustration for the client because the feature seems so simple to eXplain or straightforward when done manually.

You might say, “We always … ” but the truth is, there’s probably at least one eXception to your rule. The eXceptions are easy to handle on paper or verbally, but every eXception has to be coded into the final working product. eXceptions are generally complex because they branch away from the established flow. Translating a manual process into an automated electronic process is most often like a duck on water. There is a lot of work and complexity under the surface to make the feature effortless to use. That takes time to figure out and then create. The duck on water is the magic.

Read Part 2 of 7: What Should You Consider When Selecting a Development Partner? What Questions Might You Ask a Potential Developer?