Software development with php programmers is always a compromise between what the project has to do and being able to complete it. However, you may be asked to compromise on quality to speed up the deployment of a project in a way that offends your technical or business sensitivity. For example, you may be asked to do something that is bad software engineering practice and will cause a lot of maintenance issues.
If this happens, your first responsibility is to let your team know and clearly explain the cost of the drop in quality. After all, your understanding should be much better than your boss's. Explain clearly what is lost and what is gained, and at what cost the lost ground can be made up in the next cycle. In this regard, the visibility provided by a good project plan should be helpful. If the compromise on quality affects the QA effort, report it (to your boss and QA managers). If the compromise on quality results in more bugs being reported after the QA period, report it.
If the quality problem persists, you should try to isolate the "poor" into specific components that you can plan to rewrite or improve in the next cycle. Explain this to your team so they can prepare.
Manage dependency on software systems
Modern software systems tend to depend on a large number of components that are not necessarily under your control. This increases productivity through synergy and reuse. On the other hand, each component brings with it problems:
How will you fix bugs in components?
Does a component restrict you to certain hardware or software systems? What will you do if a component malfunctions completely?
It is always best to encapsulate the component in such a way that it is isolated and can be replaced. If the component turns out to be totally unusable, you might be able to get another one, but you might have to write your own. Encapsulation isn't portability, but it makes portability easier, which is almost as good.
Owning the source code of a component reduces the risk by four. With source code, you can evaluate it more easily, debug it more easily, find workarounds more easily, and make corrections easier. If you make fixes, you should provide them to the component owner and incorporate them into an official release. Otherwise you will have to maintain an unofficial version.
