Re:Three Tribes of Programming (2017)
by michaelscott on Friday September 06, 2019 @03:35PM
(#20899088)
In practice, a great engineer should be relatively well balanced in all 3 aspects and know when to favour one over another (such as the time sensitive case where performance in the code execution is more important than writing something that the next engineer can easily understand).
Re:Three Tribes of Programming (2017)
by inamberclad on Saturday September 07, 2019 @01:31AM
(#20901989)
You can't make it better until you make it work.
Re:Three Tribes of Programming (2017)
by adrianN on Saturday September 07, 2019 @03:03AM
(#20902251)
But you can start off with an architecture that requires a full rewrite to make it better.
Re:Three Tribes of Programming (2017)
by hellisothers on Sunday September 08, 2019 @12:05PM
(#20911336)
The number of times I’ve seen this sentiment end in a project being late or never ship is easily 10x more than the number of times a project became crippled later because of performance issues.
Improving performance isn't the only way you can make something "better". A system could be architected in a fragile or rigid way that makes extending it or adding new features extremely difficult without a rewrite.
I can't tell you how many times I've seen people "make it work" and create a mess that has to be rewritten later with much greater difficulty than if even the slightest amount of forethought had been given before hand.
For example, I’ve seen diffing / recomputation code operating in O(n^3) or O(n^2) where O(n) or O(1) is possible and necessary for reasonable performance. I’ve also seen extremely poor use of network requests (multiple serial requests) that happen because the developer doesn’t understand network latency and networking performance (in this case with a single data center in the world).