00:42
Faizan
There are many reasons why a client could decide to change the software contractor halfway through. If summed up, the main reason is that the client is not satisfied with their work. But reasons aside, we are interested in the result: there is a project done to a certain extent; this means there is design and/or code that must be used by another contractor to make a finished product.
About 77% of projects with the third-party unfinished code brought by clients needed reworking. One third of them required full code refactoring, while about 20% had to be basically rewritten from scratch.
Such 'transitions' and 'reworks' rarely are painless for the owner of the future software product. The project runs the risks of not being finished at all. Moreover, if the previous contractor was quite negligent about their duties, the code brought by the client to a new contractor might be of insufficient quality. The new development team has their own risks of working with such code, but if they are really good at their job, they will cure the client's project and get things done with quality.
Main risks faced by both the company and the client when starting work on third-party code:
Quality. If the code is of low quality initially, all efforts might be simply unable to improve it. For example, the code has no extendability; or there are lots of hidden bugs - fixing them bears risks of causing other bugs and so on.
Time. Different developers use different approaches to coding. The client goes to a new software company whose priority is quality. But when they encounter problems with poor third-party code, they have to either fix them or start working with the substandard code of low quality. The latter case can be unacceptable and risky for both sides. Needless to say that estimations of third-party code are often subjective and inadequate. The poorly written code may not meet the expectations of a good developer.
Costs. It's quite normal for clients to overestimate their code as ''almost ready, just some fixes needed''. The hidden danger is underestimating the labor required to make a finished product from this code.
About 77% of projects with the third-party unfinished code brought by clients needed reworking. One third of them required full code refactoring, while about 20% had to be basically rewritten from scratch.
Such 'transitions' and 'reworks' rarely are painless for the owner of the future software product. The project runs the risks of not being finished at all. Moreover, if the previous contractor was quite negligent about their duties, the code brought by the client to a new contractor might be of insufficient quality. The new development team has their own risks of working with such code, but if they are really good at their job, they will cure the client's project and get things done with quality.
Main risks faced by both the company and the client when starting work on third-party code:
Quality. If the code is of low quality initially, all efforts might be simply unable to improve it. For example, the code has no extendability; or there are lots of hidden bugs - fixing them bears risks of causing other bugs and so on.
Time. Different developers use different approaches to coding. The client goes to a new software company whose priority is quality. But when they encounter problems with poor third-party code, they have to either fix them or start working with the substandard code of low quality. The latter case can be unacceptable and risky for both sides. Needless to say that estimations of third-party code are often subjective and inadequate. The poorly written code may not meet the expectations of a good developer.
Costs. It's quite normal for clients to overestimate their code as ''almost ready, just some fixes needed''. The hidden danger is underestimating the labor required to make a finished product from this code.
Posted in: business
