Forcing Functions in Software Development • Hacker News Board

Re: Forcing Functions in Software Development

#31

Post by OJFord » Wed, Oct 21, 2020, 1:06 PM UTC

auggierose wrote: post #22

swyx wrote: post #13

Earlier quoted context omitted.

HN resorts to the "just quit your job lol" far too easily. people are in all sorts of different situations. you don't know if they are struggling to find work and this is the one shot they have been given. you don't know if they are in extreme demand and get paid well to fix bad situations like this. you just don't know. and telling people to blithely change jobs when they can't or don't want to isn't helpful

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 better's out there at that point.

Re: Forcing Functions in Software Development

#32

Post by glenjamin » Wed, Oct 21, 2020, 1:12 PM UTC

If a tree falls in a forest with no-one around, does it make a sound?

While the list of techniques here look like excellent ways to uncover unknown unknowns, be sure that it's actually valuable for you to resolve these issues.

In almost all cases the goal isn't to create perfect software, it's to create effective software - and sometimes the ROI on these unusual cases doesn't stack up (or doesn't stack up _yet_).

Re: Forcing Functions in Software Development

#33

Post by OJFord » Wed, Oct 21, 2020, 1:14 PM UTC

nullsense wrote: post #23

2rsf wrote: post #8

Earlier quoted context omitted.

actually having a newcomer install everything and fix the documentation while doing it is even a better option, cloning has some of the dependencies but other might have been installed by the developer for example global packages for NPM or Python, setting of system wide environment variables etc.

This happened at my org... 8 separate times. It was always slightly wrong each time, even after it was fixed. I think it's better now, but I never considered doing it myself as an established team member. Though I once inherited a large enterprise code base that I had to study and build a dev environment for pretty much all by myself. I had maybe 2 calls with the original team and a couple of emails but was mostly by…

Unless you're hiring like crazy, it's never going to be and stay perfect, but hopefully with fixing whatever issues each time you stay relatively on top of it, and it's never too much work.

Re: Forcing Functions in Software Development

#34

Post by couchand » Wed, Oct 21, 2020, 1:24 PM UTC

mjburgess wrote: post #16

swyx wrote: post #13

Earlier quoted context omitted.

HN resorts to the "just quit your job lol" far too easily. people are in all sorts of different situations. you don't know if they are struggling to find work and this is the one shot they have been given. you don't know if they are in extreme demand and get paid well to fix bad situations like this. you just don't know. and telling people to blithely change jobs when they can't or don't want to isn't helpful

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.

Re: Forcing Functions in Software Development

#35

Post by inopinatus » Wed, Oct 21, 2020, 1:49 PM UTC

dkersten wrote: post #11

inopinatus wrote: post #7

Earlier quoted context omitted.

It's more a concern when shipping library/platform code. Applications can be as tightly coupled as they like.

Should library code really be relying on a database? If its a database library, then ok, maybe it can stick to a subset of database features that works across all supported databases, but in that case, testing against these databases is no longer a "Forcing Function", but a core part of the libraries test suite to ensure correctness. The same goes for platform code, really. If you are advertising your platform to wor…

> Should library code really be relying on a database

Yes, many libraries need, or are enhanced by, persistence, whether that's a double-entry accounting module, a headless cms, or an e-commerce engine.

> you really need to be testing against those

Library authors need tools and guidance, not arbitrary constraints and high-watermark QA demands. Most of us have one or two DBs that we work with day-to-day but still want libraries we contribute to be broadly portable across any of the backends the framework they plug into supports. e.g. I can't maintain a test suite vs Oracle when I don't license it, but I still want to know that It'll Just Work if someone uses it in such combination, or that it's at least close enough they'll not have trouble making it work.

More broadly I think the myth of testing every supported combination leads to a brittle mindset of saying "not supported, won't help", especially when systematised in a commercial environment, and to me it's the antithesis of good engineering.

Re: Forcing Functions in Software Development

#36

Post by tylerscott » Wed, Oct 21, 2020, 1:56 PM UTC

mikewarot wrote: post #27

Long ago, in the mists of time, (1987) I wrote a program that worked with hand held computers, barcode scanners, and was meant to be run by folks working in a power plant. I wrote the code, and got it working in about 2 months. It did everything in the spec, and the customer (Russ) loved what we had, but it turned out (of course) there were many things missed in the spec. A week or two later, we worked out a deal for…

That was great story. Thanks for sharing!

Re: Forcing Functions in Software Development

#37

Post by dkersten » Wed, Oct 21, 2020, 2:14 PM UTC

barrkel wrote: post #19

dkersten wrote: post #2

> Try to add support for a completely different database. Details of your current database that have leaked into your data layer abstractions will soon become obvious Well, details of Postgres have leaked into my database queries and schemas, but it was a conscious decision to use Postgres and its features. Sure, it seems nice to be able to swap one database for another, but you lose out on a lot of what a database c…

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 have an easy or direct way to port.

Re: Forcing Functions in Software Development

#38

Post by dkersten » Wed, Oct 21, 2020, 2:17 PM UTC

Kiro wrote: post #18

dkersten wrote: post #9

Earlier quoted context omitted.

> How often do people really migrate to a different database? Well, I have been part of a migration from MySQL to MariaDB, which was a lot more effort than one would expect given that they're meant to be more or less the same thing. It was a ton of effort and the abstracted ORM logic didn't actually help with this. So if it doesn't really help that much for a simple case like that, then it doesn't seem like there's m…

I've done the same migration and I'm curious of what issues you had. For me, it was truly just plug'n'play with no additional work whatsoever.

I don't remember, it was ~4 years ago and for a different company. I believe there were a small number of incompatibilities somewhere (composite indexes maybe? I remember doing stuff with them but don't remember why, could have just been for query optimisation) and a few areas where the performance was degraded (again, I think around indexes, but I could be mistaken).

It wasn't a big deal over all, but it wasn't simple plug'n'play either and required some porting work.

Re: Forcing Functions in Software Development

#39

Post by dkersten » Wed, Oct 21, 2020, 2:21 PM UTC

inopinatus wrote: post #35

dkersten wrote: post #11

Earlier quoted context omitted.

Should library code really be relying on a database? If its a database library, then ok, maybe it can stick to a subset of database features that works across all supported databases, but in that case, testing against these databases is no longer a "Forcing Function", but a core part of the libraries test suite to ensure correctness. The same goes for platform code, really. If you are advertising your platform to wor…

> Should library code really be relying on a database Yes, many libraries need, or are enhanced by, persistence, whether that's a double-entry accounting module, a headless cms, or an e-commerce engine. > you really need to be testing against those Library authors need tools and guidance, not arbitrary constraints and high-watermark QA demands. Most of us have one or two DBs that we work with day-to-day but still wan…

Well, if your library can use the "lowest denominator" of supported databases, then there's nothing wrong with doing that. I'd still argue that you don't really support something you haven't tested against, but I guess this is pretty off topic. My overall point was more that sometimes being locked into a single database is a conscious decision because you want to make use of everything a database has to offer.

In the context of the article, for "Forcing Functions", I absolutely agree that switching databases is a useful way to find weakness in your solution.

Re: Forcing Functions in Software Development

#40

Post by gridlockd » Wed, Oct 21, 2020, 2:28 PM UTC

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 it, which is the reason why pretty much all successful software is kind of buggy. We all like to complain about it, but then we don't want to wait an extra year for the next version either.

At the other end of the spectrum, if you need really reliable software, the solution is not to eliminate all the bugs, that's impossible. Even with perfect software, hardware can fail, bits can flip the wrong way. The solution is to make sure that errors can't bring down the airplane.