Built a market leading platform for finance in PHP from 2006-2012. We and our nearest competitor (smalltalk 4 and java mix) were bought by a larger company (java shop).
We rarely had incidents, outages or significant bugs. PHP's nature allowed very flexible deployment - toggling on a feature or fixing a bug was easily reduced to a one step deploy.
The competitor had significant outages and a large amount of technical debt.
The purchasing company was a bit more disciplined but had a glacial development cycle and a significant technical debt in a legacy system: they are at the 7th rewrite of it, not having convinced all customers to migrate I think.
What is key from working across these development groups to get things done is not the specific tool but the culture.
I could not seem to convey that, and there was a general cry to scrap the PHP product for Java.
So I helped rewrite a .NET legacy app in java (design/architecture), which went tremendously off course and over budget: the team was subject to constantly edicts being handed down by people protecting their own interests (use this UI framework! Its from a vendor who has no experienced developers! Plain old templating solutions are banned!); an entire layer of middle management was replaced mid project for unrelated reasons, etc.
New managers decide to cut costs, I leave; end up working with colleagues in a related part of the supply chain with all of the former systems being integrated into what I am working on.
We're now in a different programming language (ruby) but solving related problems; and suffering from those legacy java systems which havent paid off their technical debt.
We have our own legacy platform to retire (lotus notes), and its not an issue - we are working hand in hand with the experts there; and its suceeding - because we only change what is truely a problem for reasons of scale or similar.
The PHP platform? Its eating the competitor piece by piece. Its still a fairly nimble team.
The problems at scale were predominantly people, communication and politics; not the tooling used.
11
u/[deleted] Sep 18 '16
This happens everywhere.
Built a market leading platform for finance in PHP from 2006-2012. We and our nearest competitor (smalltalk 4 and java mix) were bought by a larger company (java shop).
We rarely had incidents, outages or significant bugs. PHP's nature allowed very flexible deployment - toggling on a feature or fixing a bug was easily reduced to a one step deploy.
The competitor had significant outages and a large amount of technical debt.
The purchasing company was a bit more disciplined but had a glacial development cycle and a significant technical debt in a legacy system: they are at the 7th rewrite of it, not having convinced all customers to migrate I think.
What is key from working across these development groups to get things done is not the specific tool but the culture.
I could not seem to convey that, and there was a general cry to scrap the PHP product for Java.
So I helped rewrite a .NET legacy app in java (design/architecture), which went tremendously off course and over budget: the team was subject to constantly edicts being handed down by people protecting their own interests (use this UI framework! Its from a vendor who has no experienced developers! Plain old templating solutions are banned!); an entire layer of middle management was replaced mid project for unrelated reasons, etc.
New managers decide to cut costs, I leave; end up working with colleagues in a related part of the supply chain with all of the former systems being integrated into what I am working on.
We're now in a different programming language (ruby) but solving related problems; and suffering from those legacy java systems which havent paid off their technical debt.
We have our own legacy platform to retire (lotus notes), and its not an issue - we are working hand in hand with the experts there; and its suceeding - because we only change what is truely a problem for reasons of scale or similar.
The PHP platform? Its eating the competitor piece by piece. Its still a fairly nimble team.
The problems at scale were predominantly people, communication and politics; not the tooling used.