5 Traits of Highly In-effective Dysfunctional Outsourced Product Development Companies
We at D10X are often approached by customers who have previously outsourced the software development work to another software company. Their experience typically goes like this – Initially, everything seems nice. But after some time, feature development becomes slow. A bug fix adds two or more bugs to the system. Bugs remain open because the development team cannot reproduce them, etc. At some point, the customer gives up and starts searching for another software development partner, and the cycle repeats. When we talked to our customers, we started seeing a ‘pattern’ in these dysfunctional “outsourced product development” companies.
Check these symptoms if you are a start-up (or a company) and have outsourced your product development or internal software development/maintenance to another company. Please be alarmed in time if you see any of these symptoms in your “software development team.” If so, your start-up is most likely already in severe trouble or will soon be getting there!
- Your Development Team / Partner does not share source code or avoids sharing code:
- They don’t use version control (like git, mercurial, subversion, etc.)
- If they use version control, They commit code only in the local repository, and there are no commits in the customer’s git repository.
- Bad version control practices
- Releases are not tagged. There is no way to ‘exactly reproduce’ release just from information in version control.
- When sharing the code as a ‘zip file.’
- not ready to share their git repository
What are your risks if you see this behavior from a software development partner?
- Remember, the source code belongs to you (if that’s explicitly written in your contract!)
- If not, your development partner may ask for an extra payment for handing over the source code to you.
- Incomplete source delivery
- No visibility to code quality
- Complete vendor lock-in (not sharing the source code with you enables the vendors to hold you for ransom!)
- The Development Team is doing Manual Deployment.
- Deployment is usually done by the same person. If this person is unavailable (maybe s/he is on vacation), the deployment is postponed or results in some issues.
- No deployment checklist or documentation
- says, “we do CI/D” Or “We follow DevOps,” but in practice, ignore all DevOps best practice
- Nobody knows how to set up a new server from scratch if required.
- Configuration is not stored in version control (git), and there are no reliable backups of configuration files.
- QA/Staging server not available.
What are your risks if you see this behavior from a software development partner?
- In case of release failure, the site/application remains down for hours.
- Possibility of business disruption because of deployment failure
- Possibility of going “out of business” because of IT errors
- Delayed bug fixes in trying to reduce manual deployment risk
- Person dependency
- Cannot setup new server quickly if required
- Ignoring Security and Privacy
- Almost Everyone on the team has access to the production server /data.
- All-access through one user account
- This one account and its password are known to everyone.
- Developers directly tinker with/modify production data.
What are your risks if you see this behavior from a software development partner?
- GDPR violations
- Malicious developers can misuse data.
- No monitoring and error logging
- Rely on end-user reporting error. In many cases, end users may not report errors, or such error reports may need to be completed.
- We are not able to reproduce.” this error is a common excuse
What are your risks if you see this behavior from a software development partner?
- Delay in fixing errors
- End User Dis-satisfaction, and hence, you will be dissatisfied.
- Losing users/Unsatisfied users
- Technology for the sake of Technology
- Buzzword based Technology selection
- Latest Technology (sometimes risky) is recommended.
- The reason for selecting a particular Tech is ‘Everyone is using it.’
- The technology selected based on ‘what the developer wants to put on his resume
- No logical explanation of why a particular choice is better
- Scalability and maintainability are not considered
- Technology selection on what the current team knows
What are your risks if you see this behavior from a software development partner?
- Wrong Technology selection
- Technology may scale differently than business requirements.
- Business has stagnated because of technological limitations.