Don't waste time trying out the latest-and-greatest cutting-edge development techniques. Except SPAs (Single Page Applications) because those (somehow) take less time to implement and are 'easier' to iterate than a traditional UI.
Don't waste time perfecting the data models. Unless you're talking about data structures (ie they're totally not a type of data model) because your data structures should be perfect from the start so as to avoid the technical debt of modifying them later.
Don't waste time enforcing the SRP (Single Responsibility Principle). Unless you're talking about 'siloing areas of concern into microservices' because splitting responsibilities (and designing custom APIs to drive them) isn't just another approach to enforcing SRPs. Designing APIs that connect your app to it's dependencies in a manner that won't change (and break things) later is easy right?
So, code, code, code fast. Don't waste time early on developing a sane architecture, except when you want to spent time developing a sane architecture early on to iterate quickly later.
Forgive the sarcasm, this isn't a troll. I'm just pointing out the blatant contradictions.
The only valuable advice I can grok from this article is. Disregard TDD, build a MVP, push it into alpha/beta ASAP, fix bugs later.
Don't waste time trying out the latest-and-greatest cutting-edge development techniques. Except SPAs (Single Page Applications) because those (somehow) take less time to implement and are 'easier' to iterate than a traditional UI.
Don't waste time perfecting the data models. Unless you're talking about data structures (ie they're totally not a type of data model) because your data structures should be perfect from the start so as to avoid the technical debt of modifying them later.
Don't waste time enforcing the SRP (Single Responsibility Principle). Unless you're talking about 'siloing areas of concern into microservices' because splitting responsibilities (and designing custom APIs to drive them) isn't just another approach to enforcing SRPs. Designing APIs that connect your app to it's dependencies in a manner that won't change (and break things) later is easy right?
So, code, code, code fast. Don't waste time early on developing a sane architecture, except when you want to spent time developing a sane architecture early on to iterate quickly later.
Forgive the sarcasm, this isn't a troll. I'm just pointing out the blatant contradictions.
The only valuable advice I can grok from this article is. Disregard TDD, build a MVP, push it into alpha/beta ASAP, fix bugs later.