I recently met with an individual for a chat in my home town of Wellington, New Zealand who stated that it takes his engineers a year to get productive on their huge, monolithic Ruby on Rails codebase.
This in itself is astounding, as its an unusually long time-period. But it does make sense when one considers that no matter what framework or language you may be using, if you have not spent sufficient time on your architecture up front then you will pay for it at some time in the future.
Having dabbled with Rails, it is not surprising that a Rails application can morph, over years, into a large scale enterprise application that cannot easily be architecturally redesigned to enhance its modularity, testability and other quality attributes. But perhaps this does not matter so much if you are making tons of money.
MonolithLater and MonolithFirst Arguments
With microservices architectures being topical, its interesting to note that there are “Don’t start with a monolith” and “MonolithFirst” arguments out there with Martin Fowler falling into the latter camp. Mr. Fowler essentially argues that having architectural problems to solve is a better place to be with an exception to this rule of thumb being a system rewrite.
It may be hard to scale a poorly designed but successful software system, but that’s still a better place to be than its inverse.