Common software development myths
March 1st, 2016
Usually, clients have some kind of stereotype in their minds when they hire a team to do software development for them. Even IT professionals who don’t specifically do software development have assumptions about those of us who do!
As common as those expectations are, they aren’t always helpful for building clear communication between a business and the software developers they’ve hired. Here are 5 myths that we see pretty often-and the truths behind them.
1. Once the site is ‘up’ or the software application is now in production, the software developer’s work is done.
Your software is never done. Enhancements and fixes are ongoing because the system is never perfect upon ‘go-live’. Think about the iPhone, or Google. Those technologies aren’t really ever “finished” because developers are providing updates to fix bugs and add even better features.
2. Software developers should be given as much freedom as possible. Direction will only halt their creativity.
From a creativity standpoint, having unlimited time and resources for a project would be a luxury, but even then some direction from the client’s Project Manager is necessary to make sure the design and development fits within the budgets of time, feasibility and money. Every software development project LSG drives, there are constraints, so total freedom isn’t realistic. It’s important to discuss the boundaries for a project so all parties know what’s expected.
3. The customer’s the expert on their project, not the developer. They should be able to explain what they want so the developer doesn’t have to ask questions or make suggestions.
The majority of our customers will tell us some version of: “Look, if you can think of a better way to do this, please tell us and help us find the best solution.” Businesses should definitely know what their high-level needs are, but it’s the developer’s expertise that will help them get there. Open communication between both parties is crucial here.
4. If you don’t like interacting with people, you should do software development.
Anyone above a junior level programmer should be able to make suggestions about how to do things better in a respectful way. Programmers regularly need to run ideas by clients, discuss budget and technology, and have conversations about what’s actually reasonable for each project. Good people skills will help developers do those things with tact and respect. By the way, the junior-level programmer should be collaborating with the senior-level staff.
5. The shiniest, newest, most exciting technical system is always the best solution.
Most of the time, it’s the simplest system that wins the day. That’s the system that is the easiest to maintain and the one that improves morale. The goal is not for developers to impress their clients with IT glitter, but to help businesses have systems that operate well even when the developers are not physically there.
Good software developers know that they’re providing a service to their clients by sharing their expertise to solve IT problems. Communication between developers and their clients will help debunk some of these myths so that everyone can do their work well.