This applies very well to optimization, too. There are only really two ways to optimize code:
1) make it do less
2) make it do more at a time.
The first corresponds to using more efficient algorithms and data structures. The second is parallelism.
1) make it do less
2) make it do more at a time.
The first corresponds to using more efficient algorithms and data structures. The second is parallelism.
It is never a good idea to rush any large coding project. By rush, I mean just sit down and start churning out code just so you can have something tangible within a day or two. And by large, I mean anything requiring at least a few thousand LOC. Anything less can be okay to rush though; i.e., small projects where maintainability and scalability aren't as important; e.g., some MVP to test some market.
* We end up finding more crap to remove then we'd thought at the start.
* We can cut down misguided arguments from wannabe architects of "what if we'll need x" by saying "we'll add this back when someone asks for x". It's much easier to point out that x is currently pointless with concrete code than at the demiurge phase where everything is possible and timelines are ignored.
* We can chop at the problem as a team, without having a long sequential and solitary step of "designing the best system". Amdahl's law applies to dev teams as well.
It's like Fred Brooks said:
...plan to throw one away; you will, anyhow."Sketching in code" is a great analogy. Similar to how you'd trim off the rough edges in a sketched drawing, I've found myself cutting a lot of cruft when refactoring.
Yes, but less in a particular way. It's important to skip processing stuff that can't matter in the end. In this example, skipping over bytes that can't matter because the end doesn't match. In DBMS, it's important to skip over records/columns/values that can't contribute to the answer.
The surprising realization in optimization is that procrastination is a virtue. Lazy beats eager.
Or vectorization, or avoiding stalling, or filling all execution units, or...
For example, programmer requests a multiplication, compiler generates a shift; programmer requests a division, compiler generates a multiplication; programmer specifies a switch, compiler generates a jump table.