Skip to main content

News

Topic: Monolith First (Read 3526 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
Monolith First
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.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Monolith First
Reply #1
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Monolith First
Reply #2
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • FBnil
  • [*][*]
Re: Monolith First
Reply #3
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).