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

Forcing Functions in Software Development

coderefinery.wordpress.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Forcing Functions in Software Development

#41

Post by mjburgess »

couchand wrote: post #34
mjburgess wrote: post #16

Earlier quoted context omitted.

Indeed, I encounter this anti-pragmatic personality a lot in tech people. It's an extreme intolerance to imperfect circumstances: a preference for nothing at all over compromise. The issue is that tech attracts the mathemetically-minded who reasons from universal principles. Rather than the empirically-minded who start with cases, and abduce to provisional principles from those. To a aximoatic mind: when a universal…

Okay, that's a reasonable universal principle, but in this case it's Inapplicable. To quote the OP: > Everything is a rush and quality is required but never budgeted for. It doesn't really sound like this is a situation where the principle is wrong, it sounds like this is proving the principle correct: you get what you pay for.

I think the "you get what you pay for" is the kind of heuristic reasoning I'm advocating. It's essentially balance/tradeoffs/etc.

That trading off thought process isn't the same as the ACCEPT|REJECT process of the axiomatic mind.

I think a person who says "quit" is really saying that the very question of trading off heuristics of value isn't applicable.

It's a bit like Poisonous|Edible, or Gold|NotGold. There's nothing to be traded. A Copper apple is Poisonous and NotGold. No two ways about it.

That reasoning only works when the concepts (Gold, Edible, etc.) are natural kinds -- or otherwise disjoint and universal classifiers.

In life, situations fall both into the ACCEPT and REJECT categories, into both GOOD and BAD, into both VALUABLE and WORTHLESS. These concepts are heuristic ones, and not disjoint & universal.

The attempt to apply this "disjoint, axiomatic, ..." reasoning to life is a recipe for catastrophe.

EDIT: my point about principles vs. cases, is that i take: def. heuristic "a resemblance amongst cases"; and def.., principle "a universal rule which disjointly classifies cases"

..ie., a slightly more extreme meaning to "principle" than is in general use

Re: Forcing Functions in Software Development

#42

Post by auggierose »

OJFord wrote: post #31
auggierose wrote: post #22

Earlier quoted context omitted.

I think it is perfectly fine to remind people that looking for something better might be an option. Even if you have good reasons to stay in that situation, this reminder will do you no harm.

The reason might be they've been looking for a different job for a while without luck, and the harm might be... pretty depressing having someone tell you how easy it is? I sort of agree and am just playing devil's advocate, but I also think everything of 'there's better things out there you know' has probably already come up thread just before the person complained of their situation not being as good - they know bet…

I didn't say it is easy.

Re: Forcing Functions in Software Development

#43

Post by cjfd »

gridlockd wrote: post #40

I don't buy the "bugs caught early are cheaper to fix" paradigm. Most bugs are caught early without special precautions, but special precautions can be quite expensive. Most software doesn't have truly catastrophic failure cases. If there's a bug slipping through, someone will run into it, report it, and it'll get fixed. If nobody runs into it, the bug doesn't cost anything. This is the most economic way to go about…

I don't think so. When one is fixing bugs locally before the thing goes into production one can use each and every debugging strategy under the sun to find the bug. If it runs 10 times slower because of generating massive logs that is acceptable when debugging locally. In production one is constrained to debugging techniques that do not disturb production. This constraint quite often makes debugging times longer by factors of 10 if not 100 while at the same time a customer is getting somewhat impatient.

Also, the bug that would be discoverable locally but not in production is a bit of a strange animal. It does happen for cases where the developer has a better idea than the user what should be happening so the user will not even notice the bug. That sounds more like features that have been specified in too much detail than true bugs, though. More commonly everything that can go wrong locally will go wrong in production sooner or later. And in production you will, on top of that, hit all of the bugs that occur once every month and that only occur if the order of inputs is a bit strange while the database is under some load. If you have not done all possible debug/test work locally the application will hit production when there still is a lot of debug work to do and there will probably be so many problems that they even start interacting with one another and produce some really 'interesting' failures.

Re: Forcing Functions in Software Development

#44

Post by hyperpape »

The reference to bugs being more cheaper to fix the earlier they're found is one of those claims that gets passed around without much attempt to look at the supposed sources. I believe the most common citation trail bottoms out in a study that no one has access to anymore, and the whole thing seems dodgy. One link: https://www.techwell.com/techwell-insights/2013/10/what-does....

Re: Forcing Functions in Software Development

#45

Post by dockd »

gridlockd wrote: post #40

I don't buy the "bugs caught early are cheaper to fix" paradigm. Most bugs are caught early without special precautions, but special precautions can be quite expensive. Most software doesn't have truly catastrophic failure cases. If there's a bug slipping through, someone will run into it, report it, and it'll get fixed. If nobody runs into it, the bug doesn't cost anything. This is the most economic way to go about…

This is just pushing testing to the customer. Why would the customer report a bug instead of switching to a less buggy product?

Why do you think the customers are going to report bugs? I can't say that I've ever attempted to report a bug on an iPhone app, Windows, etc. It's like yelling at the wind.

Re: Forcing Functions in Software Development

#46

Post by gridlockd »

dockd wrote: post #45
gridlockd wrote: post #40

I don't buy the "bugs caught early are cheaper to fix" paradigm. Most bugs are caught early without special precautions, but special precautions can be quite expensive. Most software doesn't have truly catastrophic failure cases. If there's a bug slipping through, someone will run into it, report it, and it'll get fixed. If nobody runs into it, the bug doesn't cost anything. This is the most economic way to go about…

This is just pushing testing to the customer. Why would the customer report a bug instead of switching to a less buggy product? Why do you think the customers are going to report bugs? I can't say that I've ever attempted to report a bug on an iPhone app, Windows, etc. It's like yelling at the wind.

> This is just pushing testing to the customer.

Correct.

> Why would the customer report a bug instead of switching to a less buggy product?

All products are buggy to varying degrees. As a user, you can't easily tell if another product is "less buggy". Would you risk investing time into figuring out another program that may turn out just as buggy? No. You most likely move on with your life.

Once users are invested into your product, it takes a lot to make them switch. Every single piece of software that I use regularly is either extremely simple or somewhat buggy. I haven't switched once because of it. It's a nuisance, but not a dealbreaker.

That's not to say that I like this situation, of course I would prefer software that doesn't have bugs and glitches, but I also prefer software that exists today, not tomorrow. The market has spoken: worse is better.

> Why do you think the customers are going to report bugs?

If it's an important bug, somebody will most likely report it. If it's not an important bug, not having it reported is most likely not important either.

> I can't say that I've ever attempted to report a bug on an iPhone app, Windows, etc. It's like yelling at the wind.

So, did you switch to Android or Linux/MacOS then? Is the grass really greener on the other side?

Re: Forcing Functions in Software Development

#47

Post by jasonpeacock »

hyperpape wrote: post #44

The reference to bugs being more cheaper to fix the earlier they're found is one of those claims that gets passed around without much attempt to look at the supposed sources. I believe the most common citation trail bottoms out in a study that no one has access to anymore, and the whole thing seems dodgy. One link: https://www.techwell.com/techwell-insights/2013/10/what-does... .

Checkout the book "Accelerate", it covers a lot of operation excellence practices supported by data, including shortening the iteration cycle (e.g. discovering bugs early):

https://smile.amazon.com/Accelerate-Software-Performing-Tech...

Re: Forcing Functions in Software Development

#48

Post by hyperpape »

hyperpape wrote: post #44

The reference to bugs being more cheaper to fix the earlier they're found is one of those claims that gets passed around without much attempt to look at the supposed sources. I believe the most common citation trail bottoms out in a study that no one has access to anymore, and the whole thing seems dodgy. One link: https://www.techwell.com/techwell-insights/2013/10/what-does... .

Here is more from Laurent Bossavit, showing the history of shoddy citations surrounding the 100x claim: https://gist.github.com/Morendil/f9c2e9f3f450d3a76de8aeee7cf....

Re: Forcing Functions in Software Development

#49

Post by ojgiojgisefohg »

gridlockd wrote: post #46
dockd wrote: post #45

Earlier quoted context omitted.

This is just pushing testing to the customer. Why would the customer report a bug instead of switching to a less buggy product? Why do you think the customers are going to report bugs? I can't say that I've ever attempted to report a bug on an iPhone app, Windows, etc. It's like yelling at the wind.

> This is just pushing testing to the customer. Correct. > Why would the customer report a bug instead of switching to a less buggy product? All products are buggy to varying degrees. As a user, you can't easily tell if another product is "less buggy". Would you risk investing time into figuring out another program that may turn out just as buggy? No. You most likely move on with your life. Once users are invested in…

The cynicism in this comment really bums me out. You think it's ok to give customers a buggy product, and expect them to report the bugs, because they don't really have a choice and every other product is buggy too. You say you don't like the situation, but you're doing nothing to challenge it either.

Is your motto "When life gives you lemons, make a market for lemons?"

Re: Forcing Functions in Software Development

#50

Post by barrkel »

dkersten wrote: post #37
barrkel wrote: post #19

Earlier quoted context omitted.

I don't significantly disagree with you, but let me take the devil's advocate approach. Adding support for a different database doesn't mean restricting yourself to the lowest common denominator. It means using different techniques, more appropriate for the different database, that may optimize other parts of your data access and modification path, while pessimizing stuff your current database does. More importantly,…

Just checking if I understood your point: for the purpose of Forcing Functions, running against a different database than the one designed for (and therefore where the tradeoffs may be different and things may run inefficiently) is still useful because it helps unearth design flaws, corner cases or brittleness? If so, then, sure , I agree with you. Not all reliance on a target database is actual features that don't h…

Almost.

More that being forced to separate church and state, forced to keep business logic separate from database manipulation, and forced to go through an abstraction interface, then lets you leverage the interface later if and when the database becomes a bottleneck.

It's a devil's advocate position. I actually think it's unrealistic and probably not worth it at the time. The forcing function is what's useful, not the database portability per se. And whether it's actually useful depends on being so successful that you have so much data that your regular RDBMS can't cope with some access or update patterns. That's a hefty bet early in anything, and probably doesn't make business sense, until it does, then you wish you did things differently.

(Not coincidentally, it's a position we're in at my workplace; the database has hit its limits and we're needing to use hybrid approaches to hit latency NFRs.)

Post reply on HN