5 Traits of Highly In-effective/Dysfunctional Outsourced Product Development Companies
We at D10X, are quite often approached by customers who have previously outsourced the software development work to some other software company. The experience they share 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 system. Bugs remain open because development team is not able to reproduce them etc. At some point, customer gives up and starts searching for another software development partner and cycle repeats. When we talked to our customers, we started seeing a 'pattern' in these dysfunctional "outsourced product development" companies.
If you are a start-up (or a company) and have outsourced your product development or internal software development/maintenance to another company, then do check these symptoms. Please be alarmed in time if you see any of these symptoms in your "software development team". If so, most likely, your start-up is already in serious trouble or will soon be getting there!
1. 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 local repository and there no commits in 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 share the code as 'zip file'
- not ready to share their git repository
What are the risks for you if you see this behavior from software development partner?
- Remember, the source code belongs to you (if that's explicitly written in your contract!)
- If not, your development partner may most likely 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!)
2. Development Team is doing Manual Deployment
- Deployment is usually done by same person. If this person is not available (may be s/he is on vacation), then deployment is postponed or results in some issues.
- No deployment checklist or documentation
- say "we do CI/D" Or "We follow DevOps" but in practice ignore all DevOps best practice
- Nobody knows how to setup a new server from scratch if required
- Configuration not stored in version control (git) and there not reliable backups of configuration files.
- QA/Staging server not available
What are the risks for you if you see this behavior from software development partner?
- In case of release fail, 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
3. Ignoring Security and Privacy
- Almost Everyone in the team has access to production server /data
- All access through one user account
- This one account and its password is known to everyone
- Developers directly tinker/modify production data
What are the risks for you if you see this behavior from software development partner?
- GDPR violations
- Malicious developer can misuse data
4. No monitoring and error logging
- Rely on end user reporting error. Many cases end users may not report errors or such error reports may be incomplete.
- We are not able to reproduce" this error is common excuse
What are the risks for you if you see this behavior from software development partner?
- Delay in fixing errors
- End User Dis-satisfaction and hence in turn you will be dis-satisfied.
- Losing users/Unsatisfied users
5. Technology for the sake of Technology
- Buzzword based Technology selection
- Latest technology (sometimes risky) is recommended
- Reason for selecting particular Tech is 'Everyone is using it'
- Technology selected based on 'what developer wants to put on his resume
- No logical explanation of why a particular choice is better
- Scalability and maintainability is not considered
- Technology selection on what current team knows
What are the risks for you if you see this behavior from software development partner?
- Wrong Technology selection
- Technology may not scale as per business requirements
- Business is stagnated because of technology limitations
Comments
Post a Comment