The Product vs. Project Problem

This is the first article since quite some time. The reason for that – being busy with customer’s issues – is not the worst, but the time to reflect about the projects is also important. And this time I will write about a conflict, which effectively leads to a slow demise of software quality, loss of competitiveness and high costs, if not handled properly. This article is about the conflict between project delivery versus product development.

The well known setting

The setting I am talking about is a rather common one. Think about a software developing organization, delivering “standard” software or a software platform. And now think about this organization being embedded in a project driven context, eg. region or customer specific adaptions, typically driven by a project or sales organization. We will explore the needs of the different stakeholders in this setting and the contradicting priorities.

The Product Stakeholders

In my personal view the typical product stakeholders are product managers, developers, QA-people. They will typically aim for a “clean” and structured development of the product, each for their own personal reason. The product managers are keen to develop their product in line with the overall market demand, addressing broad and market segments and reacting to competition.

The developers try to keep the development clean and structured, as this enables them to reduce the maintenance effort and keeps the product extensible and fit for the future. Furthermore, they will strive for regular “housekeeping” and refactoring for the same purposes of maintainability and robustness.

The QA people are interested in that kind of development as it keeps the QA efforts lower and cleaner. In addition, a well structured code is typically well testable by automated means.

Overall the continued growth in a clean, maintainable and extensible way is may main objective for the product stakeholders.

The Project Stakeholders

The typical project stakeholders are project managers and customers. For obvious reasons they are interested in the fastest solution of their specific problem. And for them the future beyond the project deliverable is rarely of any concern, even though technical debt incurred during the project might hit them at a later point as well.

Customers are interested in the solution of their specific problem. If the given system is not intended to interface with partners or shall support a given industry standard, the interests of other customers are of very limited concern to them.

The situation is virtually the same for project managers. To them achieving the project goals by any means, preferably within budget and time is the main concern. Therefore, an extensible, more elaborate solution to a problem is actually counterproductive, as it will cost more with regard to resources and time.

The Conflict

From the above it is rather clear that there is a conflict of interest between these groups. And from a business perspective, where contract fulfillment and customer timelines are driving sources, the situation is often decided in favor of the project interests. That means:

  • Shortcuts
  • Specific solutions
  • Creation of technical debt

This is not bad by itself. Software development is a means of doing business and earning money. An it therefore has to serve the business purpose.

Yet we must not forget that the product stakeholders try to protect their interests for a reason. And this reason is the technical debt created when time and resources are short.

Every software system has some technical debt. And most of it will survive a bit more of it. But if the technical debt is not decreased regularly as well, the systems becomes harder and harder to maintain. The shortcuts and special solutions increase the complexity of the system way beyond the necessary value. And this directly affects the productivity of the development for future releases.

The more complex the system is, and the more messed up its architecture and design has become, the longer it takes to make a single change. This is because it takes the developers longer and longer to understand, where and how to implement a change.

Additionally, the effects and potential side effect cannot be estimated as easily as in a clean architecture. Therefore, the testers have a way harder time to select the test cases needed, and the test suites and execution time grows and grows. The management will call for more automation, as to execute more test cases in shorter time. Yet the now bad design makes it hard to automate elegantly and fast.

Conclusion

While it is economically understandable and feasible at times to prioritize project over product, hence “quick and dirty” over “solid product”, this has to be followed up by regular “clean up” to ensure the long term feasibility of the product. Extensible and plug-in architectures also may help in the endeavor to produce quick customer solutions while preserving the architecture and design of the core.

 

References and reading material:

  1. Lilienthal: “Langlebige Softwarearchitekturen”

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Time limit is exhausted. Please reload CAPTCHA.