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

Popular posts from this blog

Git Branching Strategy

Image
​ One and a half years ago, one of our clients was experiencing serious deployment problems like on lot of merge conflicts on  every merge , ​ ​ production database scripts and committed scripts are different resulting in wrong data schema, etc We analyzed and concluded that root cause of problems is poor branching strategy. The client asked us to suggest the branching strategy that will work for them. We designed and implemented the updated Git branching strategy and solved the majority of deployment issues. Following are the branching strategies for different development workflows that we implemented for the client. Strategies for CI-CD based development There will be four main branches created for each project and they are as follows, Develop QA Staging  Pre-Production Main / Production Below is the diagram that represents the strategy with the process automation and audiences, Strategy for develop branch: When a developer starts working on a feature, a feature branch will be create
Read more

DEBUGGING at D10X

Debugging is fixing bugs, i.e., errors in the code written. It is one of the tasks a developer finds themselves in for hours while working on a project. Sometimes, it seems like a breeze to fix the bug; other times, it takes a herculean effort to correct it. These bugs come in various categories: behavioral or logical, syntactical, run time, etc. One of the categories, called heisenbug, is one of the most difficult to debug. It takes hours to days to get a sense of it. During the past three years in D10X as a developer, I have faced bugs working on different projects. Therefore, I would like to share my experience in debugging bugs. Bugs are introduced in codebases because of a lack of understanding of the requirements(logic) or how tools you use function. One common ground I found post-analysis of my debugging journey is that I fixed the logic by filling gaps in knowledge.   Over the years, we have built a workflow of debugging at D10X.  Ask a teammate if it takes more than two hours
Read more