Hacker News Reader

It's shocking to me how little data there seems to be to support what many consider to be "best practice". About the only real data point I see thrown around is that bugs per LOC being fairly constant. Thus, you get people saying long, two-page functions are bad and should be broken up. But never have I seen someone backup such an exhortation with data. Let alone more nebulous rules like "objects should be open for extension and closed for modification," or anything out SOLID, really.

Breaking up code can increase your LOC, so the remedy doesn't even follow the premise.

I really wish more folks understood that point.

In the olden times there were scientists actually researching project management, measuring, changing inputs, performing experiments, probably at IBM or NASA.

We don’t do this anymore, because IT is now less costly, and sometimes doing the thing is faster than writing the plan for it. So Agile won. Probably deterministic methodologies got stuck in a local minimum, which was ridiculously expensive to run compared to Agile. I still have my book of IBM RUP process.

It is there. E.g. The book Accelerate! by Forsgren et.al. explains, scientific, what methods and concepts produce better and worse software. In an accessible way.

There are numerous papers on how TDD does X to your software or team. Numerous theses on how static typing causes more or less Y and so on.

Yet here we are, ignoring all that and discussing the pro's and cons of TDD based on a YouTube video, a blogpost, an anecdote and mostly a giant pile of ego and opinions.

Do those papers all agree? And what's the right course of action if, for instance, everyone in your team hates using TDD and threatens to resign or switch teams if you attempt to enforce it? Though surely it's more likely that something like "TDD" isn't an either-or proposition, and even if the evidence clearly shows the effectiveness in particular scenarios or when done in a particular manner, its not a given that more TDD is always better, and hence there's still benefit to discussing the pros and cons.

Off course they don't agree. Though I have asked numerous times to come up with scientific research or arguments that prove the science in e.g. Accelerate! wrong, no-one, not even the strongest opponent of CI, TDD or such, ever has produced that.

Instead, people come with handwavy nonharguments that "in this particular scenario it is different". To which I neither agree nor disagree. I only have proof that it does apply, even to scenario X. It's up to "you" to then, scientifically prove that it doesn't apply.

Point being: again: we should have discussions about tabs, spaces, TDD, CI, lean, agile, microservices based on scientific research. In a scientific manner. Not based on anecdotes and personal feelings.

Sure, but unless someone's taken the time to do the studies, anecdotes are the best data we have. And I'm not entirely dismissive of personal feelings either, when they're formed as the result of years of experience exploring different techniques. Especially because I tend to feel there's more to software development than just "engineering", and there's a creative side to it that's never going to be completely reducible to whether technique A is measurably better than technique B. Certainly in a tech lead type role, being aware of how those in your team enjoy working individually while still sticking to basic principles and guidelines that allow the team as a whole to produce quality code in a timely fashion is one of hardest balancing acts to get right.

But when there's clear and accessible science proving those anecdotal and personal feelings the ball is with "you".

It's now up to you to show some scientific method, data and theses, to prove the other science wrong.

Or, in other words: if science and "personal feelings" disagree, it's very obvious what should be considered the right take. Until the time that personal feeling is proven right. Scientific.

Sorta. It isn't a lack of a scientific mindset. I argue it is a premature quantification of data such that you can objectively look at it in a scientific way.

We are taught that you can compare things objectively in most school level science classes. This leads folks to thinking their perspective is valid scientifically. Especially if they can put numbers to it. After all, isn't that native empiricism?

I'm in complete agreement with you. At this point, I also endorse threats of flogging for someone who tries to introduce a new framework to a project after the actual work has started.

And actual flogging for the management team if they accept that framework.

As a data point I've just joined a small project which already has a JS framework (Vue) and 2 build systems (1 broken) and the developer has just added React and a third build system. No talk of migration - they're going to run in parallel.

The migration is often also a source of problems in itself.

There's nothing wrong with neither Vue or React, but adding a second one of those for no reason deserves the flogging thing that the grandparent poster is talking about.

Build systems... well they're a dime a dozen and in Javascript all build tools kinda suck (yes, including Vite), but still no excuse for having two.

Curious why you suggest all JS build tools suck... previous company I was at had .NET, Java (backend), golang, iOS, Android and JS (react) builds, that all compiled, ran unit tests, packaged and deployed to relevant targets. The react build was the least problematic by far (though we did get bitten on upgrading the host OS which upgraded node to a version incompatible certain older packages being used, but it didn't take too long to fix). Accepted, there was probably a little less functionality in that component than the mobile apps , but iOS was far and away the most problematic, FWIW).

"Suck" doesn't mean "worse compared to others". It means it has problems by itself that I would prefer not having to deal with. Ideally we'd need no build tools for JS. Except for JSX, modern browsers are mature enough. Other languages build tools are often terrible too, the only one I actually enjoy is probably Cargo.

As for the real answer: for trivial stuff, all build tools work fine. For anything beyond that they still have varying degrees of problems. You seem to have encountered those in iOS but not in the JS tool you used. An engineer working on a super vanilla iOS project but a complex JS project would probably say the opposite.

Vite works quite well for most part, but there's still quite a lot that can go wrong with it. It depends on two other build tools (esbuild and Rollup), so some otherwise trivial configurations are difficult and prone to break with upgrades. But for happy-path stuff it works perfectly.

Most of the time a vanilla configuration is fine, but sometimes you have special requirements (sometimes due to vendors or specific technologies) that the younger tools aren't good for, while older tools have their own issues.

What's a language for which you don't think build tools "suck" then? Btw another data point is the C++ open source project I contribute to regularly, where I continually have all manner of problems with local debug builds (the CI builds are generally OK except for being unbearably slow, and it's a single desktop application!).

I said it in my reply. Rust/Cargo.

Amusingly, I'm using Cargo and CC for a large C++ project I have. It's unholy and certainly wrong, but works beautifully and is not as bad as every other C++ build tool I have to use.

This is a wonderful comment! There is missing descriptions of things, the quality, the metrics to use when describing such things and we, the users of those said tools end up spending a lot of time going through bad documentation and learning things by practice. For a trade that pushes the digital frontier to everything it touches, the learning is surprisingly analog.

Read the book About Face : Essentials of Interaction Design, it’s a great resource on design and make projects around interaction as the title suggests.

And still a lot of devs I have met haven’t read About Face : Essentials of Interaction Design. It’s a must read in my book to structure around a project. You don’t have to copy paste it’s ideas, but using its core features makes a project a whole lot smoother for both end user and devs.