Being able to keep the system you are working on in your mind with sufficient but excessive detail is key. Keeping the system in all is parts "as simple as possible and as complex as necessary" (that is my engineering philosophy) is what make se all the difference. I used to think: since I am smart I am going to write something more complex because I can manage that. Wrong. For the smart and dumb engineer a simpler system is faster to build and moreover easier to maintain.
Managing dependencies (briefly mention in the article) is even more important. In a large organization what show you down the most is having to wait for somebody else. Having autonomous teams as much as possible is part of the equation to keep a growing organization able to move fast.
That said everything else being equal (you are writing a good code, you have good engineers, etc), a monolithic system tends to be easier to debug (one stack trace is easier to debug than a trail of logs), the code base is usually easier to refactor.
Where a monolithic system makes things harder is asynchronously deploy different parts of the system and scaling different parts of the system at a different pace.
As a rule of thumb, trying to keep things in one system until it is evident where the cut should be and it is clear it is time to do it help to keep both infrastructure overhead and cognitive overload under control.
Managing dependencies (briefly mention in the article) is even more important. In a large organization what show you down the most is having to wait for somebody else. Having autonomous teams as much as possible is part of the equation to keep a growing organization able to move fast.
That said everything else being equal (you are writing a good code, you have good engineers, etc), a monolithic system tends to be easier to debug (one stack trace is easier to debug than a trail of logs), the code base is usually easier to refactor.
Where a monolithic system makes things harder is asynchronously deploy different parts of the system and scaling different parts of the system at a different pace.
As a rule of thumb, trying to keep things in one system until it is evident where the cut should be and it is clear it is time to do it help to keep both infrastructure overhead and cognitive overload under control.
But there is no silver bullet.
Check also: http://www.codingthearchitecture.com/2014/07/06/distributed_...