3 ms·

Provocatively asked: who was right? This sounds more like an organizational problem. The project leader has to decide whether speed issues need fixing or not.

by _ph_ 6y ago

Provocatively asked: who was right? This sounds more like an organizational problem. The project leader has to decide whether speed issues need fixing or not. If they don't need fixing, then it is indeed a wasted resources trying to do so. If they need fixing, then of course it is the task for the project leader to find the neccessary resources. Speed issues are almost never unfixable. But, the cost of doing so might be prohibitive, usually companies deliver products which are just fast enough. The question is, with a given budget, how do you ship the better product for the customers needs? Do you want it to be fast with fewer features or not quite as fast, but having many more required features? To decide this, it is the job of the project lead, the architects and of course marketing, which has to sell the product. And both as a project lead and a developer, I can say, it is really fun to make something faster and more efficient, but far too often there isn't the time/resources for it. Most of the time you have a customer waiting for new functionality or bug fixes much more urgently than for some speed improvements.

CaptArmchair 6y ago
This comes down to defining and generating "value". Speed, features and bug fixes are all different forms of value. But value isn't an absolute. It's always in the eye of the beholder and depending on where a stakeholder is coming from, they are prioritized differently. From a business perspective, balancing between different types of values is paramount. The end goal, after all, is to always deliver value that generates revenue exceeding expenses at an acceptable level. This is why legacy software is a thing. The business assesses that an old tool still generates value for paying customers and revenue while spending an acceptable amount of time on maintenance. In the context of a large system with a large userbase, this may imply dedicating one or two developers full time towards keeping the lights on. Many software projects don't get a rewrite. Why? Because over the course of years, business and technological contexts for all stakeholders - both the business and the customers - change so much that they become irrelevant. For instance, the business pivoting away towards a new lucrative market or product, or customers moving away to a competitor offering the same value but at a better price point and with up-to-date technology. Just consider many services and products you've used over the years and how many of them have been shelved or sunset without ever being rewritten. While the necessity of a full rewrite may pop up over technical concerns such as security or performance. It's only when business and functional requirements have shifted away to a serious degree from the original scope of the project that organizations tend to consider dedicating time and resources to a successor. At that time, a rewrite isn't necessarily the only option: sourcing a product that does the same thing but better from an outside supplier could be a valid option as well. For instance, chucking away your own homegrown decade old CRM for Salesforce as your business grew from a 5 person outfit to a 120 person business servicing enterprise.
deleted 6y ago
[deleted]

by _ph_ 6y ago

CaptArmchair 6y ago

This comes down to defining and generating "value". Speed, features and bug fixes are all different forms of value. But value isn't an absolute. It's always in the eye of the beholder and depending on where a stakeholder is coming from, they are prioritized differently. From a business perspective, balancing between different types of values is paramount. The end goal, after all, is to always deliver value that generates revenue exceeding expenses at an acceptable level. This is why legacy software is a thing. The business assesses that an old tool still generates value for paying customers and revenue while spending an acceptable amount of time on maintenance. In the context of a large system with a large userbase, this may imply dedicating one or two developers full time towards keeping the lights on. Many software projects don't get a rewrite. Why? Because over the course of years, business and technological contexts for all stakeholders - both the business and the customers - change so much that they become irrelevant. For instance, the business pivoting away towards a new lucrative market or product, or customers moving away to a competitor offering the same value but at a better price point and with up-to-date technology. Just consider many services and products you've used over the years and how many of them have been shelved or sunset without ever being rewritten. While the necessity of a full rewrite may pop up over technical concerns such as security or performance. It's only when business and functional requirements have shifted away to a serious degree from the original scope of the project that organizations tend to consider dedicating time and resources to a successor. At that time, a rewrite isn't necessarily the only option: sourcing a product that does the same thing but better from an outside supplier could be a valid option as well. For instance, chucking away your own homegrown decade old CRM for Salesforce as your business grew from a 5 person outfit to a 120 person business servicing enterprise.

deleted 6y ago

[deleted]