We’ve all been there in our coding youth, well at least I have. You see that a codebase can be improved and you add in a whole bunch of features and also slide in a large refactor at the same time. What is the result total chaos, business interruption and weeks of stress. We can refer to this as the Big Bang or BB. Sorry, it's not the big breakfast.
Incremental changes (INC) solve all that. What are they you may ask? Well in my own humble opinion its the gradual spoon feeding of tiny changes into a code base that is the beginning of a medium to large refactor (or new features), whilst letting everyone know exactly what is going on.
Practical examples anyone? Here are a few, and they are in the context of a large application with 10+ developers
Linting is the process of applying code style changes to an existing code base. Big bang: apply all the style changes in one go and raise a Pull Request or PR.Several things can happen here:The PR will sit there until the lifetime of the universe has expired, or until all the black holes have evaporated. Everyone in the team will be afraid to approve it, because who can approve 100k lines of code? If they are reluctant to approve it then who will have the nerve to merge it. It's a waste of everyone's time. The only feasible way to do this with a BB is to have the whole team know ahead of time that new linting will be applied, and schedule it to be done in a period of time quickly and merged quickly.Incremental: You create a branch called feature/linting-xxx and inform the team that you are linting the code base incrementally. You agree a number of files that you will lint, say 10-15 per PR and raise repeated PRs. You start with files that you feel are not being touched in the current sprints to reduce conflicts. You also advise the team to format any code they touch in order to make the transition easier.
When upgrading frameworks there are often subtle differences in how they effect existing codebase. Depending on the framework this can affect a large number of files.Big Bang: You address all the changes in one go, and push to development. If you have greater luck than being a 2x Lotto winner things might just work out well for you. A little bit later you have a meeting with the product owner and he explains how everyone is out to get him.
Incremental: Sensible frameworks will give warnings in the console to let you know what features will not be supported in upcoming frameworks. Ember has got this nailed with what are called depreciations. To use the incremental approach with this on a large code base you tackle all of the depreciations gradually over several PRs. The larger the team and the more complex the project, the more care you need to take. If things do go wrong in the process you can roll back the last incremental change, and still keep face.
I could go on and on about other various scenarios (eg introducing testing frameworks or migrating to TypeScript/ES6) but I think you get the point. Always remember the incremental approach and bear it as a secret weapon in time of need.
