Design Philosopy

It’s a developer wet dream to be able to build a highly decoupled system that allow new features to just slot in flawlessly without disturbing existing one. However, that’s rather difficult to achieve, even if somewhow we’re able to, it will certainly come with a cost like any other.

Ok then what’s the approach we should take to tackle this delicate matter?
okay first we’ll have to list our priorities

• Rapid feature release
• Ease of tweaking
• Maintainability of said features

My answer is to combine the speed of mobile warfare and the organization of grand battle plan, is that even possible?
Yes, I call it the Nimble Forsythia.

In short this war doctrine design philosopy start with anticipating apparent problems and ignoring scary but vague problems and then goes into full speed while doing a little cleaning along the way by the end of a major patch we’ll take a brake and see if there’s new apparent problem and then adress it if there’s any.

There’s three main component to this philosopy

• Compound Battle Plan
• Relentless Execution
• Litter pick-up

Compound Battle Plan

In traditional SDLC the planning will be done once at the start of the project, However we’ll do it after every major patch.
Contrary to other software project we don’t have the luxury of knowing everything at the very beginning, so to cope with that we’ll do smaller design phase multiple times.

This short planning phase will result in faster features being done but if we’re not careful the whole thing can crumble, that’s where the Litter Pick-up and the compound part come into play.

After the end of every major patch, the code will start to tangle into spaghet but it won’t be too spaghet, Litter Pick-up will clean the smaller spaghet and the planning phase at the start of the next cycle will fix glaring architectural problems.

Relentless Execution

After the planning phase is completed we’re going to switch into full flank speed and try to follow the set guidelines but don’t show any hesitation don’t think of problems that might come in the future.

But isn’t this dangerous? Yes, but our first priority is to ship the features first so it’s fine and also there’s two percautions set in place to prevent too much damage which are:

• Unit testing
• Litter Pick-up

Unit testing discourage us from coupling system too much, because well the test won’t run if the scene can’t work by itself.
And Litter Pick-up untangle mess before it reach a critical point.

Litter Pick-up

To put it simply Litter-pickup is a refactoring process that’s being done after every feature release which focus on cleaning the small but numerous mess we’ve created during the creation of said feature.