http://martinfowler.com/bliki/MonolithFirst.html (http://martinfowler.com/bliki/MonolithFirst.html)
I had to think about it awhile, but I actually really agree. Modularity, hierarchical systems, and microservices are cool, but most of the best non-monolithic stuff I've done started out monolithic and was later broken up.
Right. I agree with this as well. I always start my projects as monoliths (see: minisphere) and only later do I break stuff up if the need arises. In my experience it's very difficult, sometimes prohibitively so, to write a fully modular system from the ground up. You end up spending more time writing interface layers than actual code.
Yep. My Sphere Studio was Monolith first with the editors integrated. Then I striped them away and exposed as a plugin API what they needed to interface with the editor. I couldn't imagine trying to see how to do that first.
I agree too. Mostly there is a phase in programming where I start adding functionality, with focus on getting it working. Once I have a proof of concept, I start fleshing out what I wanted to do, the normalization to functions happen (similar calls grouped, same parameters), reuse of common functions (modularization). During the copy-pasta I make, I notice I modified functions to do something else. I then backport that modified function from where I copied it from. (However, they mostly grow due to feature-creep.) Once part of the software is proven handy, a lightbulb lights up, I isolate the functionality and I modularize it. and a library is born. But I can do that only once it is written.... strange. Once the library is there, I can think of it as a component for a next thing.
It is the moment I need paper to start fleshing out the structure, when it stops fitting all in my head, I need to modularize. Fairly organic process. Usually I then rewrite with long term maintenance in mind.
Engineers call that first monolith the "proof of concept", then, once that works and know what to expect from the software, you flesh out the final implementation api and structure. Sometimes it requires a complete rewrite. And then you can go 2 ways: Adding more functionality (software grows), or refining it (software gets smaller and faster).