4 ms·
>> I believe that truly high-quality engineering actually looks like average engineering delivered at incredible speed As somebody who's building new product o
by Floegipoky 10y ago
>> I believe that truly high-quality engineering actually looks like average engineering delivered at incredible speed
As somebody who's building new product off a ~20 year old perl codebase, I strongly disagree. No matter how easy the problem the system you're building to solve is, architecting and implementing a complex system that will stand the test of time is itself a hard problem. And if it doesn't need to be maintained, I would argue that you're not engineering, you're hacking. Nothing wrong with hacking, but it's a completely different approach to development optimizing for different attributes (time to market vs quality).
Now, that's not to say that they don't both have their place within a given project. Hacking together a MVP and then applying more rigorous engineering practices after it's been "proven in battle" seems to be a good balance. I'd highly recommend checking out David Black's work if you aren't already familiar, he has a lot to say on the subject! https://www.amazon.com/Wartime-Software-Building-Matters-Better-ebook/dp/B00CUGHDT8 https://www.amazon.com/Wartime-Software-Building-Matters-Bet...
- AbrahamParangi 10y agoThe trick here is that the only software metrics that I count as contributing towards 'quality' are: 1) did the goals get accomplished? 2) did it get done fast? 3) did we avoid accumulating critical-path tech debt? (I'd like to emphasize that only actually critical-path tech debt matters. Tech debt off the critical path doesn't matter.) Frankly, if you have time to build a perfect solution you've allocated too much time to the task.