Continous improvement

One of the limiting factors of enterprise software development is pure business driven change request process, where behind every, even most benign change there’s always a requirement for a clear business driver. Practicality of having only business stakeholders in a process of driving changes in software limits scope of changes to quick fixes or erratic, patchy design. After considerable amount of time this leads to an impression of patchy choices in interface and inconsistent quality. One of the long forgotten remedies for this scenario is implementation of technical and design reviews within development departments. With implementation of reviews, the problem of patchy design improves dramatically. This however still leaves far too many projects in half baked state, where many long standing inconsistencies, design flaws or even simply bugs remain present. The missing factor of such projects is the component of continuous improvement, which would allow technical management to make efforts towards improvement of general experience of IT subsystems under their management. Continuous improvement process does come with its own risks too, whereas developers are left with wide open door to so called gold-plating, resulting in implementing features with no business value, along with which software is exposed to quality loopholes.