4 ms·

Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite

Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_. That never happens in the real world. One always has limited time to produce a viable product. There is always some extrinsic constraint to how much time can be spent taking your time and understanding what you're doing. Moreover, if you are operating in any commercially viable product space, you're always competing against other firms for finite market share. If it takes x years to ponder and understand how to build and ship a masterful feat of engineering, while some other company ships a "sort-of-works" product with bugs and engineering flaws in <<< x years, the other company will usually win in the marketplace. Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days.

Silhouette 5y ago
This is the popular wisdom but I question how universally applicable it is. We all know that having the best technology doesn't necessarily mean you win in a commercial market and we all know that being first mover can be an advantage, but those observations don't tell us what will be successful in the long term. How often does substandard technology and technical debt become a drag on a business not long after that first move, allowing someone else to overtake because the poorly built system couldn't scale to production levels or wasn't adaptable enough for changing requirements or failed so often that the early users drifted away? How often do we see developers advocating shortcuts and showing limited understanding of basic software development or computer science ideas, only to see the product they work on being rewritten within a year or two, or the whole team shut down? You can try to be fastest always. You can often succeed, at first, if you take enough shortcuts. But you can't sustain that pace without enough quality in your people and your code. Planning to throw each implementation away and rewrite with more resources every year or two is a very unicorn-like strategy. It reminds me of VCs whose strategy is to invest liberally, who are fully aware that most of those investments won't work out but they're hoping for one or two in each batch to become the next big hits. Real engineering isn't done in a vacuum and its goal isn't perfection. Real engineering takes issues like costs and timescales and staffing into account and aims to find a solution that is good enough on all counts. But it still has to be good enough. Producing junk but quickly and cheaply is an effective strategy until it's not and the success of any product using that strategy comes down to little more than the luck of the draw.
- pjlegato 5y ago
  I totally agree. Engineering should be the best it can be, within the constraints of the resources available. My post was addressing the common case where an engineer seems to ignore the 'resource constraints' side of the equation altogether. Balancing these factors is more art than science. No two projects have the same set of resource constraints, nor the same set of engineering challenges. Luck is a big factor. The solution depends heavily on the exact details of each particular case.
  - JamesSwift 5y ago
    See also: engineers who think that engineering considerations trump all other business considerations. You need to know when it makes holistic sense to rewrite, or ship a hack. There are a lot more people at the decision-making table than just engineering.
    - Silhouette 5y ago
      That is certainly true but somehow I suspect under-engineering is a more frequent problem in our industry than over-engineering. IME retrospectives rarely sound like "We hired a team of strong developers, they did a solid job, but then the business failed as a result". The kind of developers who are strong enough to do a solid job are probably also experienced enough to recognise the other considerations in play and adapt if necessary.
0xFACEFEED 5y ago
> Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_. While this is obviously true, I don't think it depicts the actual decision making process that leads to messy codebases and crappy products. In my experience lack of experience and/or laziness play a big part. A competent tech lead that's passionate about quality AND is willing to be annoying for the greater good makes an enormous difference. I'm talking multiple orders of magnitude difference. It's the difference between spinning up a k8s cluster + service mesh vs tiny single server vps with basic failover. The former is thousands of hours of dev time across multiple disciplines while the latter a seasoned engineer can handle by themselves.
PragmaticPulp 5y ago
> Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days. This is precisely why I try to interview tech leads about what they shipped rather than what they built. There are a lot of otherwise very talented developers out there who will spend years playing around in your codebase, writing beautiful code, but not actually shipping anything useful. Replacing them with shipping-focused engineers, even if they're not as technically competent, usually results in big productivity boosts. This isn't a popular opinion among developer communities, but it's a common theme in the management forums I'm part of. It's important to have fun and budget some time for things like open-source contributions and library building, but the top priority must always be on shipping product.

Silhouette 5y ago

This is the popular wisdom but I question how universally applicable it is. We all know that having the best technology doesn't necessarily mean you win in a commercial market and we all know that being first mover can be an advantage, but those observations don't tell us what will be successful in the long term. How often does substandard technology and technical debt become a drag on a business not long after that first move, allowing someone else to overtake because the poorly built system couldn't scale to production levels or wasn't adaptable enough for changing requirements or failed so often that the early users drifted away? How often do we see developers advocating shortcuts and showing limited understanding of basic software development or computer science ideas, only to see the product they work on being rewritten within a year or two, or the whole team shut down? You can try to be fastest always. You can often succeed, at first, if you take enough shortcuts. But you can't sustain that pace without enough quality in your people and your code. Planning to throw each implementation away and rewrite with more resources every year or two is a very unicorn-like strategy. It reminds me of VCs whose strategy is to invest liberally, who are fully aware that most of those investments won't work out but they're hoping for one or two in each batch to become the next big hits. Real engineering isn't done in a vacuum and its goal isn't perfection. Real engineering takes issues like costs and timescales and staffing into account and aims to find a solution that is good enough on all counts. But it still has to be good enough. Producing junk but quickly and cheaply is an effective strategy until it's not and the success of any product using that strategy comes down to little more than the luck of the draw.

pjlegato 5y ago
I totally agree. Engineering should be the best it can be, within the constraints of the resources available. My post was addressing the common case where an engineer seems to ignore the 'resource constraints' side of the equation altogether. Balancing these factors is more art than science. No two projects have the same set of resource constraints, nor the same set of engineering challenges. Luck is a big factor. The solution depends heavily on the exact details of each particular case.
- JamesSwift 5y ago
  See also: engineers who think that engineering considerations trump all other business considerations. You need to know when it makes holistic sense to rewrite, or ship a hack. There are a lot more people at the decision-making table than just engineering.
  - Silhouette 5y ago
    That is certainly true but somehow I suspect under-engineering is a more frequent problem in our industry than over-engineering. IME retrospectives rarely sound like "We hired a team of strong developers, they did a solid job, but then the business failed as a result". The kind of developers who are strong enough to do a solid job are probably also experienced enough to recognise the other considerations in play and adapt if necessary.

0xFACEFEED 5y ago

> Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_. While this is obviously true, I don't think it depicts the actual decision making process that leads to messy codebases and crappy products. In my experience lack of experience and/or laziness play a big part. A competent tech lead that's passionate about quality AND is willing to be annoying for the greater good makes an enormous difference. I'm talking multiple orders of magnitude difference. It's the difference between spinning up a k8s cluster + service mesh vs tiny single server vps with basic failover. The former is thousands of hours of dev time across multiple disciplines while the latter a seasoned engineer can handle by themselves.

PragmaticPulp 5y ago

> Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days. This is precisely why I try to interview tech leads about what they shipped rather than what they built. There are a lot of otherwise very talented developers out there who will spend years playing around in your codebase, writing beautiful code, but not actually shipping anything useful. Replacing them with shipping-focused engineers, even if they're not as technically competent, usually results in big productivity boosts. This isn't a popular opinion among developer communities, but it's a common theme in the management forums I'm part of. It's important to have fun and budget some time for things like open-source contributions and library building, but the top priority must always be on shipping product.