The true answer, which not one single CEO will ever want to hear until the problem becomes so dire it threatens the business, is if all the tools available are hot garbage, it’s time to build your own. Generality in software has a cost, and for large multidisciplinary problems like job tracking or ticketing, that cost makes developing an in-house tool for solving your specific problem and your specific use case much more efficient than what any general tool could produce. All those stupid features that some other company depends on, or no one uses, or are only there because someone was trying to capture all possible use cases, can simply not exist. That makes the tool faster, more efficient, simpler to use, and when you realize there’s some feature that would be really valuable you can just implement it rather than cludge together some half assed version in someone else’s proprietary shitpile. There is a scale where things like jira make sense, but much like cloud services it’s a technical trap because by the time you realize the tool doesn’t really work for your use case it’s too late to switch. At that point you’re already past the point you need to start developing your own tool, but the sunk cost fallacy is a bitch and there’s never enough funding for that. Pay no attention to the csuite salaries.
This is a very difficult topic, as sometimes I think the opposite end is true, where a company like mine spends a billion to develop their own solution, which is worse than anything on the market, and worse than our old systems. Executives hallucinating that they will become the next innovative tech company are also a problem, as they vacuum up a lot of resources from the market, and then everybody complains how you cannot find an architect anywhere.
I think companies should do a make-or-buy decision for each tool, and reevaluate this regularly. Of course this requires extra work, and letting go of politics (and sometimes corruption), so never going to happen.
There is a scale where things like jira make sense, but much like cloud services it’s a technical trap because by the time you realize the tool doesn’t really work for your use case it’s too late to switch.
Heh, my org went the opposite route. They started by developing their own tool that’s gotten so big and bloated (with all the original implementers LONG gone) that it’s at the point where they’re talking about moving to a pre built tool because the self built one is too unwieldy to do what we need to do.
At that point you’re already past the point you need to start developing your own tool, but the sunk cost fallacy is a bitch and there’s never enough funding for that.
And if you’re not at that point at the beginning of the process, wait a few years until employee churn is high enough that the sunk cost of the self built system is finally outweighed by the technical debt of the system.
Systems have lifecycles. They should die at some time and be replaced by other systems that function better for the now.
But instead, patch patch patch and keep all the unused or rarely used functions, as well as add more because some csuite attended a conference once and decided it needed x y and z even though company only used a-h.
The true answer, which not one single CEO will ever want to hear until the problem becomes so dire it threatens the business, is if all the tools available are hot garbage, it’s time to build your own. Generality in software has a cost, and for large multidisciplinary problems like job tracking or ticketing, that cost makes developing an in-house tool for solving your specific problem and your specific use case much more efficient than what any general tool could produce. All those stupid features that some other company depends on, or no one uses, or are only there because someone was trying to capture all possible use cases, can simply not exist. That makes the tool faster, more efficient, simpler to use, and when you realize there’s some feature that would be really valuable you can just implement it rather than cludge together some half assed version in someone else’s proprietary shitpile. There is a scale where things like jira make sense, but much like cloud services it’s a technical trap because by the time you realize the tool doesn’t really work for your use case it’s too late to switch. At that point you’re already past the point you need to start developing your own tool, but the sunk cost fallacy is a bitch and there’s never enough funding for that. Pay no attention to the csuite salaries.
This is a very difficult topic, as sometimes I think the opposite end is true, where a company like mine spends a billion to develop their own solution, which is worse than anything on the market, and worse than our old systems. Executives hallucinating that they will become the next innovative tech company are also a problem, as they vacuum up a lot of resources from the market, and then everybody complains how you cannot find an architect anywhere.
I think companies should do a make-or-buy decision for each tool, and reevaluate this regularly. Of course this requires extra work, and letting go of politics (and sometimes corruption), so never going to happen.
Heh, my org went the opposite route. They started by developing their own tool that’s gotten so big and bloated (with all the original implementers LONG gone) that it’s at the point where they’re talking about moving to a pre built tool because the self built one is too unwieldy to do what we need to do.
And if you’re not at that point at the beginning of the process, wait a few years until employee churn is high enough that the sunk cost of the self built system is finally outweighed by the technical debt of the system.
Systems have lifecycles. They should die at some time and be replaced by other systems that function better for the now.
But instead, patch patch patch and keep all the unused or rarely used functions, as well as add more because some csuite attended a conference once and decided it needed x y and z even though company only used a-h.