3 ms·

I believe that truly high-quality engineering actually looks like average engineering delivered at incredible speed. It's a fact of life that from an engineerin

I believe that truly high-quality engineering actually looks like average engineering delivered at incredible speed. It's a fact of life that from an engineering standpoint, most problems faced by most business are not actually hard. Most engineering doesn't need to be beautiful, performant, extensible, etc. It just needs to be done. The most common counter-argument I hear is that this view is 'short-sighted' and too focused on 'sales'. In my experience, the short-sighted view is that you already know what you need to be building. Over-investing in the problems you know about leaves you without the flexibility and agility to tackle the problems you don't know about yet.

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 ago
  The 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.
j45 10y ago
Average engineering also allows more engineers to participate in creating and contributing value. Clever architecture will often beat clever coding. Sales, as boring as they are, often pay salaries, and the bills to keep the lights on to keep. As a guy who has to pay those salaries and bills, and a developer, teaching junior and "think they're not junior" devs how to find the balance between how much abstraction, architecture and coding cleverness is enough remains the most key part of what I do. The best devs I find, especially the super experienced polyglots, still maintain a healthy distrust of their code, think about future devs touching their work, and often write enough love letters to their future selves explaining why they did what they did.

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 ago
The 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.

j45 10y ago

Average engineering also allows more engineers to participate in creating and contributing value. Clever architecture will often beat clever coding. Sales, as boring as they are, often pay salaries, and the bills to keep the lights on to keep. As a guy who has to pay those salaries and bills, and a developer, teaching junior and "think they're not junior" devs how to find the balance between how much abstraction, architecture and coding cleverness is enough remains the most key part of what I do. The best devs I find, especially the super experienced polyglots, still maintain a healthy distrust of their code, think about future devs touching their work, and often write enough love letters to their future selves explaining why they did what they did.