5 ms·
And it is incredibly hard to predict the future. So I just try to engineer things forcefully for only today's needs. And instead of future-proofing, I try to ma
by jasim 10y ago
And it is incredibly hard to predict the future. So I just try to engineer things forcefully for only today's needs. And instead of future-proofing, I try to make it easily comprehendible. Make their intentions as explicit as possible. Comprehension trumps everything. Because before we can actually change code by typing it in, we need to be able to hold it in our head and mend it there. And if you can clearly see in your mind's eye what is currently there, you can see what it can become.
The above applies only when we have to 'predict' the future. Oftentimes we know the future already - there is going to be ton of traffic, we are going to need an API for this use case, we are actually going to stay in business etc.
- tempodox 10y ago> Comprehension trumps everything. I couldn't agree more. This is as close to a “silver bullet” as we will ever get.
- xupybd 10y agoThis comment is so on point, I love working with code that has been built with that philosophy. The code remains simple and you don't waste hours trying to seperate useful complexity from bloat.
- qznc 10y ago> ton of traffic This comes with assumptions. Depending on the magnitude of the traffic you need very different architectures. For example, see Pokemon Go https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html https://cloudplatform.googleblog.com/2016/09/bringing-Pokemo... > an API How flexible should the API be? For example, do you need multiple representations (JSON, YAML, XML, etc)? Maybe it makes sense to build it representation-agnostic, but maybe it is over engineering.
- 0xCMP 10y agoThis is true, but unless you understand the problem then (which you might not since not all of us work at 50x expected load) then how do you architect it properly while also not wasting time?