I often encounter situations where a day or two were spent creating a mess of classes and abstractions, yet the actual logic to solve the problem still hasn't materialised. A defense about "code quality" or "not wanting to write spaghetti code" is often made.
My recommendations for a problem you don't have a clear solution in mind for:
1) Hack some pseudo-code spaghetti together in a blank file until you think "you got it"
2) Write some theoretical test scenarios in another blank file (given state, steps, outcome) to verify that it's actually "solved". Discuss with a team member if possible.
3) then write out those functions from 1) inside the existing codebase
4) verify stuff is working
5) only then do abstractions / splitting up into multiple files
For a problem where the solution is already existing, but the implementation lacking (e.g. a refactoring)
1) design the new code (data structures, interfaces)
2) always propose to the team - no ninja-architecture/refactors
3) ensure the solution can be tested, document what should be tested
Very much this. By wrapping your mind around the new possibilities the whole 'seperate style from content' becomes much more trivial (and so much more maintainable) that the discussion mostly ends at this point.
I get your point, but at the same time your argument is an odd one to make.
At least the SASS-port of Bootstrap declares it's variables as defaults - meaning they would not be set if they were set earlier (in your configuration). This makes upgrading the gem (or plain source files) rather simple. But sure, you might have to check if anything was renamed or added.
But with overriding you do not only create redundant, unnecessary styles (and bytes), but if you now upgrade your bootstrap files as you suggest, you also have to change your overrides - which depending on the amount of changes you did will be significantly more work (and 'mental gymnastics') - if changes were introduced.
So you gain very little (less setup effort) but lose quite a lot.
You can compile Bootstrap yourself from LESS or SASS, pushing your own values into the Bootstrap variables (and ideally sharing this configuration with your custom styles). In the process you can choose not to include some Bootstrap components, reducing it's weight significantly. It's NOT a lightweight framework.
I often encounter situations where a day or two were spent creating a mess of classes and abstractions, yet the actual logic to solve the problem still hasn't materialised. A defense about "code quality" or "not wanting to write spaghetti code" is often made.
My recommendations for a problem you don't have a clear solution in mind for:
1) Hack some pseudo-code spaghetti together in a blank file until you think "you got it"
2) Write some theoretical test scenarios in another blank file (given state, steps, outcome) to verify that it's actually "solved". Discuss with a team member if possible.
3) then write out those functions from 1) inside the existing codebase
4) verify stuff is working
5) only then do abstractions / splitting up into multiple files
For a problem where the solution is already existing, but the implementation lacking (e.g. a refactoring)
1) design the new code (data structures, interfaces)
2) always propose to the team - no ninja-architecture/refactors
3) ensure the solution can be tested, document what should be tested
4) execute on the implementation
YMMV