The UK left the EU and is pushing very similar sorts of dangerous nonsense legislation when it comes to the internet, so this is clearly not just a EU thing.
> The point I’m making is that: my boss would laugh me out of the room if I told him “You can’t measure the quality of my electronics designs or my delivery process; it’s art.”
You can find some kind of objective metric, e.g. bug count or time spent developing new features. That alone is super hard to get right, but even if you could, it wouldn't necessarily tell you which techniques lead to a better result. People have tried studying such things (e.g. do static types help) and the studies rarely come up with any effect.
I don't think that's necessarily because these things don't have an individual effect, but because there are humans involved and so, personal ways of thinking probably play an outsized role, so technique X might be a very good fit for person A, but not for person B.
Few people who advocate for software quality want better software just because it's more aesthetically pleasing.
Often, we've worked on codebases that were nearly collapsing under their own weight, where adding even small features would take an inordinate amount of time, where most changes would have unintended consequences, where onboarding was incredibly hard, etc. And we've worked on other codebases where changing things was easy, so we know the difference.
Often, the business has no clue how to fix this because a) they're non-technical, b) we unfortunately have no consensus in the industry about what "good code" is, c) humans are much better at short-term than long-term thinking.
This is a frustrating comment because it doesn't engage with anything the article is saying and just tries to counter it with the truism that "he doesn't owe anyone anything", something which the author specifically addressed at the beginning of his post.
Guess what, if the project leader doesn't owe anyone anything, then the author of TFA also doesn't owe him anything.
Microservices are distributed and distributed systems are inherently more complex than non-distributed ones.[0]
> A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time.
In a statically-typed monolith, function calls are typed, I can jump to the declaration site with a mouse click and if I pass the wrong type, the code won't compile. That's way easier than "you can observe the inputs and outputs" (and hope that your observations generalise sufficiently). And yes, there are solutions for this (contract tests, Avro schemas, etc.), but they are inherently more complicated (maybe the most interesting idea I've seen in this space is Unison[1], but that's not gonna gain a lot of traction anytime soon, I predict).
Of course, microservices have valid use cases, but they come at a significant cost. I don't understand how one can argue that that cost doesn't exist.
> - The ability to find the n most or least used tags with a single method call - The ability to track which user tagged a record - The ability to find records with the same tags - Calculation of tag statistics for a tag cloud
What's the chance that this is the exact set of features that you're gonna need and not a slightly different set of features? E.g. maybe your users are part of teams and you need to know which tags were set by a given team? Or maybe your tags are hierarchical? Will the library be flexible enough to accommodate that?
It just seems that this library makes a lot of assumptions about the business logic of your application - but that can change at any point and then you're possibly stuck with a library that you have to weirdly workaround, or rip out entirely.
I would understand that tradeoff if the library solved an actually complex use case, but every competent developer should know how to implement these use cases from scratch in a relatively short amount of time, and while it undoubtedly takes longer than just adding 2-3 lines of config, what you get in return is code that you own and understand and can modify in whatever way you want.
As someone who started his career writing Ruby (but has since migrated to statically typed languages), I agree with your criticism. One big problem I had with the Rails community was the overemphasis on libraries/frameworks that make the code superficially look nice ("just put this dependency in your Gemfile, and it will automagically work") but aren't actually well-designed enough to be composable. The moment you're gonna have to do something out of the happy path, you're often out of luck.
The tagging problem in particular isn't such a hard problem that you' should need to pull in an extra dependency just for that. It's basically just a nested set of hash maps, the "hardest" part about it is the persistence - and I do believe it's worth spending maybe 2 hours on a proper DB schema in exchange for having code you own and understand.
There are other libraries in the Ruby ecosystem that take different approaches (dry.rb for example, which IMHO, strikes a better balance between the expressivity of Ruby and solid design), but they're not all that popular.
Every company? What about banks that have old codebases running on Cobol?
I'm also very skeptical about big bang rewrites, but there are points where you need to migrate off certain tech. Ideally you can make that transition piece by piece though, but that also introduces its own set of problems (now you have two systems and the new one has to inherit some of the baggage of the old one in order to be compatible).
I think a lot of distinct, but interrelated topics are being brought up here:
* Using tests as a (or even the primary) design tool (strong TDD)
* Test-first development (weak TDD)
* Integration vs. unit testing
* What is a unit test?
* Should one use mocks and if so, when and how?
I think each of these topics merits a separate discussion and you can be e.g. in favour of at least weak TDD while maintaining that unit tests have little value, or you can be in favour of unit tests but disagree that "unit test" means "unit = class/method/function". You can have differing opinions on the value of mocks even if you subscribe to strong TDD (that's essentially the classicist vs. mockist divide in the TDD scene - for example, Bob Martin is more skeptical of mocking than, say, the "Growing Object-Oriented Software, Guided by Tests" crowd is).
IMHO, the biggest problem with testing is that most developers are not very good at it. I routinely see tests that are so complicated that it becomes very hard to understand, let alone debug them. In my experience, a lot of people also skip tests when reviewing code.
Well-written tests make a code base a joy to work with. Bad tests make everything painful. I don't know how to fix this, but we should pay more attention to it. If we had better tests, it would be easier to argue about the merits of TDD, unit testing, mocking etc. With badly written tests, everything devolves into a "why even test [this specific thing]?" kind of discussion.
It's not commutative, yes, but it should still obey the property that the relative error terms add instead of multiplying, no?
(i.e. in the parent's case of "checking that, if you add a bunch of disjoint probabilities, they're at most 1", doing that with approximate equality seems fine to me?)
> Using exact equality comparisons with floating point numbers, while fairly uncommon, seems a lot more frequently the right thing to do than math.isclose: for example, sorting algorithms, hashmaps and caches, checking for equality between structs, sentinel values.
I mean, math.isclose() doesn't even form an equivalence relation, so of course it doesn't make sense to base struct or hash value equality off of it.
I don't think anyone was suggesting to use approximate equality as a form of actual equality. The only reasonable equality for floats is exact equality, yes. However, it's also an equality which is useless for calculation.
> I think much of the time when people feel like they should use floats they can actually use floats
I disagree, many LOB applications deal almost exclusively with discrete settings, and in such cases, floats are generally not necessarily appropriate. Money, for example, should generally not be represented as a float, unless you're doing e.g. financial mathematics on it, estimating return rates and so on (and then with the understanding that these calculations won't be exact).
FWIW, I thought the advice in the article was generally correct (at least I couldn't spot anything I knew to be wrong). I agree that, if you actually need exactness and can spare the extra CPU cycles, floats are not your best bet (e.g. banking, accounting). But for the use case:
> There are cases where one does need to check for convergence to arbitrary values [...]
the advice in the article doesn't strike me as wrong per se. If you're implementing a numerical algorithm for some reason and you want to check that it's well behaved, adding a couple of tests where you check for approximate equality of some results as detailed in the article seems fine to me. (Of course, ideally you would additionally also formally prove the numerical stability of that algorithm.)
I guess the article is maybe missing one crucial piece of advice, namely that floating point computations are not guaranteed to be well-behaved. If you don't know much about floating point computations and just read this article, you might be tempted to think that every computation involving floats should lead to a result that is "close" to the "real" result. But that's not true, numerical algorithms can be poorly behaved and error terms can multiply, leading to catastrophically wrong results.
I mean, he's using relative tolerance, not absolute. Most common arithmetic operations should be well behaved w.r.t. relative tolerance, unless you're using denormalised numbers.