New York is a well thought out, grid based, highly planned city from the ground up from the beginning.
Paris is a complex city with many organic roads that were built long ago but during the Napoleon era, a few large boulevards were built in order to increase the efficiency and connectedness of the city. A hybrid of planning and organic growth.
London is an organically developed city with curving roads, complex subway systems, and tons of legacy but is still a highly functional city.
In all three scenarios, each city is massive, efficient, has high production, and gets the job done. They were all planned in different ways but achieved the same outcome. New York wanted to be very structured, Paris wanted a hybrid, London opted for an organic route. No one city has it right and each have their own charms, cultures, efficiencies, and issues.
In enterprise software development, we have very similar issues. Enterprise software is uniquely hard to make sweeping changes due to scale, complexity, impact, and cost. In certain cases, adding just a single dimensions to a database can mean hundreds of thousands, possibly millions, of extra dollars accrued in storage costs due to operation scale – not to mention performance impact of query times. When a new product or feature needs to be introduced that has sweeping impact and ramifications for the rest of the organization, it’s often a good idea to take a step back to think about New York, Paris, and London.
Strategically, do you think it makes sense to rewrite 1/4 of the platform? Is there a work around? Should we just build something entirely new from scratch then migrate? Is there a middle ground where we can build a connection? Is that a long term solution or just a bandaid that will hurt us later? These are all questions that go back to the same macro level issues of city planning.
I think most companies start out with a basic plan but rapidly move into an organic model – much like London. The development goes in different directions, workarounds are instituted, compromises are made, it becomes more costly to engineer, but it still works. At some point, this scale can break down in which organizations move to the Paris model.
Moving to the Paris model means creating large boulevards that allow for certain efficiencies while allowing autonomy for organic growth to fit into those boulevards. Sometimes we even dig tunnels to find ways around the boulevards and organic streets, but at the end of the day we still provide connections to the main boulevards.
Then, at some point, the intersection of feature needs and tech debt forces organizations to consider building New York – a new paradigm that offers a foreseeable scalable solution and is well planned from the ground up. We build a basic version of New York and then start to port over all of the features. New York works for a while until we start to see flaws, in which we move back towards feature developments that model London and Paris: organic development.
Repeat a few times and you’ve got software development for the enterprises.
This isn’t necessarily a bad thing at all. Much of the worlds greatest software follows each of these patterns and have proven that no single model is “the best”. What has become very apparent to me is that it’s important to know which model you’re building after. It’s critically important because it highlights specific choices and sacrifices you’re willing to make.
Put simply: be aware of which what you’re doing.
Where I’ve seen these models fail the most is when organizations are not aware of the type of city they’re trying to build, making compromises or features that back them into incredibly costly situations. Now, this isn’t to say that you need to consider this for every feature. I personally think it pertains largely to more macro/strategic development (ie. user permissions, data portability, etc.).
Obviously we will make mistakes and sometimes choose to bulldoze the wrong areas in way of building our boulevards, but the hope is that by being more conscious about these decisions it will help shed light on the long term impacts and make decision making easier.