Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Professional Corner-Cutting (2016)

blog.ometer.com

Post reply on HN
Print view View original

111–120 of 142 posts

Re: Professional Corner-Cutting (2016)

#111

Post by delusional »

strken wrote: post #77
justin_oaks wrote: post #20

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the fea…

The name "tech debt" has always been a bit of a misnomer. Financial debt does come with interest, but it's structured, proportionate, and you can just go pay it off with sufficient money. Tech debt is unpredictable, needs a lot of context to comprehend, needs even more to fix, is subject to the mythical man month, and taints everything else it touches in your product. It can be worth accepting such a structural flaw…

It's an incredible share that we've accepted the "technical debt" metaphor so deeply into our vocabulary that we can't discuss the practical problem without devolving into interpreting the metaphor.

The practical definition is clear. It's a lack of maintenence of core abstraction. Leftovers from different designs, deeply embedded into our solution. Sometimes we plan for it to live in a corner somewhere, but more often we discover the failure of some abstraction all too late.

It doesn't work like debt at all. We didn't sign a termsheet, and we didn't calculate the impact. We need to move beyond this hopeless metaphor such that we can actually discuss what software needs, because right we're staring at a field emptied of nitrogen by years of farming and saying it has a "resource debt"

Re: Professional Corner-Cutting (2016)

#112

Post by noisy_boy »

gofreddygo wrote: post #108
plufz wrote: post #84

Earlier quoted context omitted.

> no one bought Apple products for Apple's marketing or advertising. That statement would require quite a source. Of course a lot of people bought Apple products because of the ads, like for any company that is a serious advertiser.

Apple had been doing great ads since 1977 [1] Apple revenue not so great till 2000s [2] What changed ? [1]: https://www.macworld.com/article/670956/the-14-best-apple-ad... [2]: https://www.statista.com/chart/4574/apples-revenue-since-197...

Social media and it's amplification of the desperation to show off. Apple products are cool/expensive and I am cool/above average/have buying power/ to have them while I sip my pumpkin latte at Starbucks. They are also high quality machines but I don't think for everyone that buys them, the motivation is solely the software/hardware stack.

Re: Professional Corner-Cutting (2016)

#113

Post by justin_oaks »

YZF wrote: post #51
justin_oaks wrote: post #20

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the fea…

This is not the right answer for a real business. Sometimes we'll fix that later is perfectly acceptable. If that was good enough for Facebook it can certainly be good enough for others.

"We'll fix that later" is at best a hopeful fantasy, and at worst a lie intended to manipulate. It doesn't happen.

We need to be clear here. If what needs to be fixed is something that will inevitably cause serious problems down the road, then it should be fixed immediately. If it may cause minor problems then maybe you should never fix it. And there's a lot in between.

The biggest problem is that bosses aren't in a good position to understand the code you're looking at. So if you're a professional, you'll make the call as to whether or not some tech debt is worth fixing now or not.

The boss's job is to communicate the urgency and importance of your task, how it fits in with the company's goals, etc. Your job is to carry out the task with a reasonably balanced ratio of quality to time.

Re: Professional Corner-Cutting (2016)

#114

Post by noisy_boy »

justin_oaks wrote: post #20

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the fea…

> Sometimes they add "We'll fix that later."

The answer to that answer is more questions:

- how will we fix it, properly, later when we can't fix it now? Won't there be more features to be done later?

- what if we fix it later and it creates its own issues and then someone will ask why did we touch it when it was working? If it breaks now, we can fix those breakages because we are already touching it.

- if later, as part of which release?

Don't actually ask these questions - they will piss-off your boss even more.

Re: Professional Corner-Cutting (2016)

#115

Post by justin_oaks »

thayne wrote: post #98
justin_oaks wrote: post #20

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the fea…

That's all well and good until you have to explain that the reason building something they think should take a week will take 6 months because you have to fix tech debt, or avoid adding new tech debt.

A professional balances the need for quality with the urgency of the task. Your example shows a clear imbalance that indicates the person is not a professional; that person is someone who can't be trusted with that balance.

Re: Professional Corner-Cutting (2016)

#116

Post by lloeki »

delusional wrote: post #111
strken wrote: post #77

Earlier quoted context omitted.

The name "tech debt" has always been a bit of a misnomer. Financial debt does come with interest, but it's structured, proportionate, and you can just go pay it off with sufficient money. Tech debt is unpredictable, needs a lot of context to comprehend, needs even more to fix, is subject to the mythical man month, and taints everything else it touches in your product. It can be worth accepting such a structural flaw…

It's an incredible share that we've accepted the "technical debt" metaphor so deeply into our vocabulary that we can't discuss the practical problem without devolving into interpreting the metaphor. The practical definition is clear. It's a lack of maintenence of core abstraction. Leftovers from different designs, deeply embedded into our solution. Sometimes we plan for it to live in a corner somewhere, but more ofte…

> We didn't sign a termsheet, and we didn't calculate the impact.

Which is very much like going to the bank and trusting it that it's going to be ok without looking at numbers; or going to a mob shark for a loan, but it's actually Darth Vader and he'll make sure to alter the deal any way he sees fit.

Evaluating what tech debt is going to cost (through coupling and accidental complexity) is definitely part of the job. That responsible engineers yelling it's going to cost a lot are then ignored is part of the systemic cultural problem.

Re: Professional Corner-Cutting (2016)

#117

Post by Vinnl »

pilgrim0 wrote: post #89
Vinnl wrote: post #47

One of my frustrations is how people often seem to drift towards one of the extremes on either side of this argument. Technically, the approach described in this article is called 'pragmatism', but in practice, people have used that term to describe the bad kind of corner cutting. And whenever you're arguing against someone drifting too far to one of the extremes, you'll often get lumped in with those on the other: t…

IME, even the word “perfectionism” is weaponized against us who actually mind risks, results and sustainability of work, beyond of just doing it for the sake of completion and compensation, like the other group. Why is it safe to “denounce” perfectionism in the workplace while the opposite, of calling out a shitty job, is seen as offensive and of bad taste? “Perfectionism” has become shield and shelter for the lazy a…

Either label needn't be used: if someone thinks the effort isn't worth it, you can have a discussion on what risks will or won't actually play out in practice without having to label anyone anything.

Re: Professional Corner-Cutting (2016)

#118

Post by Vinnl »

strken wrote: post #83
arnorhs wrote: post #68

Earlier quoted context omitted.

This is ambiguously stepping into "overly general / building for the future" territory. Perhaps that is not what you meant. There is a fine line where I do agree with you. Cases such as creating a relation table for categories, when you could have made a string array field instead. Or structuring a code in a way where you are not preparing for the future, but also not painting yourself into a corner. Examples such as…

The given examples of utf-8 support and reading headers from CSVs are things that (depending on stack etc.) can be nearly or actually free if you build that way from the start. I read the original post as saying something like "good engineers don't shoot themselves in the foot as much".

One challenge is when eg you're doing a code review and see that someone set it up with a non-utf8 column. In that specific case it's probably easy to fix, but it's still strictly extra work even if it hadn't been if it had been set up as such in the first place.

I struggle with making that trade-off in terms of what's worth pointing out. Often what I'll do is point it out, but with an explicit disclaimer that I'm mostly pointing it out because it's good to know for the future, but that it's not a blocker (for larger chunks of work).

Re: Professional Corner-Cutting (2016)

#119

Post by makeitdouble »

nebula8804 wrote: post #74
matusp wrote: post #61

Earlier quoted context omitted.

It is not about the backs of cabinets. It is about telling your customers how big of a deal the backs of cabinets really are.

The back of Apple cabinets are are actually pretty good even in the Tim Cook era. [1]: https://www.cultofmac.com/320883/why-samsungs-design-sucks-i... [2]: https://ioshacker.com/iphone/image-compares-ugly-samsung-bea...

On the first, having the off-center hole helped with thicker plugs. The iPhone had less of these issues as cables were thinner (and more expensive) in general, while micro USB had a flurry of cheap cables in the while that could be much thicker.

Apple never really cared for ports practicality, we've had the same discussion with the finewoven cases that wouldn't allow for regular thickness usb-c cables. Other makers made more of an effort on that front.

The second would be a better point if iPhone's repairability was on par with Samsung's. Granted Samsung also became worse with time, but it was in no small part because of what the market leader could get away with.

That said, I think your general point stabds: Apple cares about the back of the drawer. But not in the way I personally wish they cared.

Re: Professional Corner-Cutting (2016)

#120

Post by bee_rider »

YZF wrote: post #110
bee_rider wrote: post #85

Earlier quoted context omitted.

The IEEE code of ethics https://www.ieee.org/about/corporate/governance/p7-8.html Would seem to preclude working on a site, like Facebook > 1. to hold paramount the safety, health, and welfare of the public , to strive to comply with ethical design and sustainable development practices, to protect the privacy of others , and to disclose promptly factors that might endanger the public or the environment; Given that si…

I'm not an expert in ethics but to me this stance goes too far. The Internet in general is also used to spread medical conspiracy theories. If I work on network switches is that also unethical? Compilers? The job of regulating this sort of stuff is the government and the courts. There are laws concerning privacy, and speech, and companies need to operate within those laws. I would say an ethical engineer should not b…

One reason to have an ethics code is that the law can’t possibly cover everything. Law is read in a fairly hostile manner (in the sense that people are looking for technicalities and loopholes), and also has to concern itself with enforceability, jurisdictions, etc.

Ethics are self-enforced mostly, and they are to be followed in good faith. An ethical engineer should not break the law, but nobody should break the law, that’s the bare minimum for existing in society.

If you thought the internet was overwhelmingly harmful and had little-to-no redeeming value, yes, working on network switches would be unethical.

> I would interpret IEEE's statement as it affects a single engineer to e.g. ensure that they are following best practices in protecting user information, e.g. if an engineer is asked by Meta to take some shortcut that exposes people's information publicly that would grounds for refusing to do that on an ethical basis.

I don’t see any particular reason to think they just mean exposing personal information to the public, when they talk about protecting privacy. I’d tend to assume Meta, like every other entity, is something we ought to protect people’s privacy from.

It is up to you to interpret the meaning personally. But nobody is going to punish you if you don’t obey the code, so why look for an out? Just don’t follow it.

Post reply on HN