Hacker News Reader

I would do 4.5) escalate to PM boss everytime 1,2,3 happens.

> PM says build it the naive way

Why PM has an option to choose here?

> will fail for cases 1,2,3

a) tip QA to test these cases

b) add cases 1,2,3 to "Known issues"

After all that is the reason they call it "beta": "Cause it beta then nothing"

Seems like you’re working with a PM who thinks agile is an excuse to release bad software. MVP should still solve a customer pain point.

To play devils advocate though, maybe case 1,2,3 are low enough risk to release. Having metrics set to watch if these are actually big problems could be “good enough.”

Without details, it is really, really, really hard to say whether cases 1, 2, 3 are real, important issues that need to be fixed or just needless complexity that 99.9% of users are never going to care about. The PM is trying to distinguish between those two cases because they've been burned before on developers double, tripling, and quadrupling their estimates as they find "one more thing" that is inelegant or could potentially be improved and delaying the launch schedule. You need to convincingly make the case to the architect (and to the PM) that issues 1, 2 and 3 are critical to the users, fundamental to the design and going to be much harder to clean up later if we don't spend the time to get them right now. Or you're wrong, and you should just suck it up and build the simpler thing today and leave the complexity of the new thing for the future, when you can decide whether the feature is even worth the cost of having whatever new architecture it would require.

This is a good answer. Determine how much the deficiencies matter and make your case. If you're being asked to ship something with a major deficiency and being ignored by the team you need to inform someone higher up. Not always the most fun part of the job.

Exactly. Also to add it depends on your business model of how you are selling software. Some customers are perfectly fine with MVP and iteration. Others will want everything spelled out beforehand in a contract 3 inches thick. That many times depends on how you are selling your work and what the company you are selling to expects. One place I worked we always shipped MVP. Then would get customers to pay for any new features. New features could be cases 2 and 3 do not work correctly for the customer, however case 1 works just fine for the first customer but they never use 2 and 3. It can come down to how your companies budget works which will drive the business model you have. Now if you are shipping 'boxed' software that mentality could end your product. As instead of a reputation of 'works nicely with the customers' you are 'this junk software is broken out of the box'. It is one of the things I ask during an interview. I want to know what sort of shop it is 'how do you sell your software'. Each are viable methods to make money but some people do not like working that way. I am flexible but I would like to know up front.

You'd have to take my word for it I guess that these were real cases.

The first time this happened was a physical product with intention to sell to a very large American company with which my company had a relationship going back decades. I did as I was told (did not get to step 5 until after release, there were steps in between 4 and 5 which caused me significant political blowback). Ultimately they did not appreciate the corner cutting and declined to purchase. My quitting moment came when I was asked to be involved in mislabeling product to indicate it was up to standard X when it did not come to our supplier that way. The pressure I was put under to do that put me in therapy. I was a recent graduate with a young child, tough times. A year after I quit, my former company was parted out.

The last time this happened was software used for planning national infrastructure. Case 1,2,3 were common cases that would give very obviously incorrect results. The naive case was if a sliding parameter was always set to one particular value, opening that value up to change was a can of worms that required a whole new architecture. Ultimately I held my ground with the PM and said I would not build it incorrectly and implied it was a dealbreaker for me. I convinced the architect and PO of the correctness (PM was former frontend and had no clue what any of the backend stuff meant). Ultimately I ended up on the PM's (my manager) shitlist and the PO (apparently with the memory of a goldfish) couldn't understand why that feature slipped several sprints. I had better things to do so again I quit. I don't really expect that company to last too much longer at least in its current form. There were already "pivots" on the horizon which gave me deja vu (I expect company owner was gearing up for a sale).

In both cases there were pretty bad shakeups (unbeknownst to me) in the year prior to my joining. In the last case I would have appreciated a friendly heads up from a buddy at the company (they no longer had a real QA dept, they were all fired for "poor communication").

I guess I joined these companies because I have a soft heart for companies with deep history. I certainly learned a lot but my beard is a bit greyer than I'd like for my age. I think the rot was too deep to point out in each case without royally pissing of some of the longest tenured, better than betraying my ethics I guess.

I've had good work in between the first and last where my raising the flag was taken quite seriously and procedures were updated to mitigate, but still I feel I have a black mark on my name.

Some truths to keep in mind:

- Every company is navigating the marketplace, and making decisions with imperfect information

- Not every decision will be perfect (or even, good)

- Not every decision-maker will be perfect (or even, good)

- Even a collection of individually smart/reasonable people, can end up collectively making pretty awful/illogical decisions

- "Good" decisions don't guarantee market success; conversely, "bad" decisions can still result in good outcomes

- Judging the quality of decisions and decision-makers based on outcomes, is an imperfect measure of the actual "quality" of those things/people

In your first example, you were presumably an entry-level engineer, but you either mistakenly took on too much burden (emotional or practical) in terms of decision-making yourself, or you misunderstood what types of expectations you should have for the actual decision-makers.

Decision-makers are allowed / expected to make such bets: "how many and which corners can we cut as a company, to get a product out to market, that clients will want to purchase, in a sensible time-frame?" This is not unusual, this happens all the time, at every single company, all around the world. The companies who do this more successfully, are the ones who find a sweet spot between cost-cutting, efficiency, time-to-market, and customer demands/satisfaction/delight. This is a very difficult thing to juggle, and really really smart business leaders consistently fail to find the right balance, or make the wrong calls. Hopefully the mistakes aren't fatal to a company, but unavoidably sometimes they will be. So yes, your company leaders made a bad call based on the outcome, but that on its own is not enough to indict the decision or the decision-makers as being fundamentally wrong.

The fact that your company made a set of decisions that ultimately led to failure, doesn't necessarily prove that they were a bad company. And to be a devil's advocate for a second, even "mislabeling standard X" might be forgivable under certain circumstances, such as launching a product with an "X pending" label, even though you didn't finish certification process for X yet, or maybe you didn't even start (but hey not starting doesn't mean it can't say "pending").

As a manager, I actually actively filter-in for what Amazon would call "Have Backbone" as a value, when interviewing engineers, and I ask them to provide examples of times where they fundamentally disagreed with the product team, disagreed with what they were asked to build, disagreed with a proposed architecture, etc. I want engineers on my team who will speak up, who are opinionated, who care enough about their work to take pride in it and put forth effort to improve beyond the status quo.

That being said, your examples seem to indicate a rigidity of black/white thinking, all-or-nothing thinking, and an inability to collaborate towards finding a solution. These were probably the most extreme examples you had, so I'm not judging every interaction or your entire personality as being so rigid, but hopefully you have by now experienced other examples in your career, where collaborative problem-solving was possible, where you did more than point out fatal flaws but also helped formulate a path to mitigate or solve them. The companies where that was more encouraged or made possible, are the ones you probably want to work for.

Thank you for your kind advice.

Trust the Engineer. PMs care only for date.

Well, this isn't prima facie unreasonable without more info (or knowledge of the implicit assumptions you are making but not publishing).

- Are cases 1,2,3 named that way, because they are the top priority cases (i.e. the #1, #2, and #3 most important product features that customers care about)? Even if they are, what is the cost of a new architecture? Will it take you 3 years and 20 engineers, to rebuild Y or to make Y.v2, just so you can support X "properly"? By then the market may have moved on, the feature may be worthless, so it may make perfect sense to deliver a bad version of X that relies on Y.

- Or, are cases 1,2,3 legitimately either rare, or low-impact, or do have viable manual workarounds? If so, then it's entirely reasonable to defer/punt on doing new architecture right now, because either you know these cases are unimportant, or at least you don't have positive proof that these cases are important enough to justify new architecture. With more data, or clear customer demand, you can make a better case for rebuilding Y "properly". The real problem comes later: what happens if you do get strong signals of customer demand, you can prove the current solution is not scalable or extensible, and yet the business still decides that Y is good enough to never touch... well that's a business that doesn't want to stay in business.

Agile is about practicality/pragmatism, over adherence to dogma or preconceived notions. Just because Y is the wrong architecture to deliver X, does not mean it is the wrong decision to ship partial feature X. Don't be dogmatic about "correct architecture", if you care about for-profit software engineering as a profession.

Of course, if your goal is different, if SWE is a craft or a hobby or an ivory tower pursuit for you, then feel free to make whatever decisions you want that don't fit your vision of "correctness".

See this comment for more specifics: https://news.ycombinator.com/item?id=32953007

I think there its a little unclear that by case, I mean testcases that would fail to pass to fulfill a single feature. E.g. "I need an addition feature for a calculator" but naive implementation will result in it working for 1+1 and fail for all others.