Early in my career, I really bought the stuff the Agile founding fathers promoted (Martin, Uncle Bob, Beck, etc). I tried bringing it into my code and pushing it on my teams, but it never went well. I tried finding great examples they've implemented to use as, well, examples - but never found anything. Turns out, these gurus of coding almost never release any open source code to be scrutinized outside of toy examples in their books.
I've realized the reality is that many of their suggestions are actually pretty reasonable, but they take time to implement. Most business software is written under a relative time crunch, and the time required to slow down and properly implement them is excessive and unaffordable.
More specifically, in the case of DDD, most businesses cannot afford to make every developer a domain expert so they can properly refactor to the DDD guidelines. The required think time and one-on-one time with an expert to learn the domain would be far too costly.
Further, it pushes a different type of complexity into the implementation that a non-expert cannot understand, which actually slows down future development when new hires fumble the domain. Thus, new hires end up having a longer ramp up time with less productivity and more handholding during it.
I studied a number of books in that field last year, and much of this entire thread is missing some key points.
The learning psychology field often differentiates practice from deliberate practice, where practice is just about anything and deliberate practice is focused learning.
In deliberate practice, you have to work at near your skill level, you need to apply proven learning methods, it should take maximal effort, you need a feedback mechanism to course correct, etc. A great deal of focus goes into creating effective mental models and intentionally removing ineffective mental models. It requires good coaching. As you progress in expertise, your practice should involve more risks and failures. (And there's still much more to be said here)
Gigging and noodling aren't going to make for efficient practice as it likely won't be full concentration, won't involve feedback, won't involve challenging material at your skill level, etc.
Also, you can spend 10,000 hours jamming alone in your bedroom on same set of guitar tabs and make shockingly progress compared to someone who spends just a few hundred hours intensely studying music books with a metronome and tape recorder.
You won't necessarily have to have ?client_type=xyz params on your endpoints if the BFF can do the filtering, so it saves having to build out all sorts of complexity in each backend service to write custom filtering logic. Of course, you'll pay the price in serialization time and data volume to transmit to the BFF, but that's negligible compared to the RTT of a mobile client.
I'd much rather issue 20 requests across a data center with sub-millisecond latency and pooled connections than try to make 20 requests from a spotty mobile network thats prone to all sorts of transmission loss and delays, even with multiplexing.
The article doesn't do a great job at explaining that this isn't always just filtering, sometimes it's aggregation too.
A mobile client may need data points to display a single page that require calling 20 different APIs. Even if every single backend offered options for filtering as efficiently as possible, you may still need an aggregation service to bundle those 20 calls up into a single (or small set) of service calls to save on round-trip time.
My company uses this pattern extensively, just as indicated in the post. Frontend teams deliver their own backend-for-frontend and the backend teams just worry about their own microservices. Generally, it works out pretty well most of the time.
The big issue I've been seeing is that occasionally frontend teams will decide to develop "features" by stringing together massive series of calls to the backend to implement logic that a singular backend could do much more efficiently. For example, they commonly will have their backend-for-frontend attempt to query large lists of data, even walking through multiple pages, in order to deliver a summary that a backend service could implement in a SQL query. Unnecessary load on the backend service and on the DB to transmit all that data needlessly to the BFF.
I know the easy answer is to blame the frontend devs, but this pattern seems to almost encourage this sort of thing. Frontends try to skip involving the backend teams due to time constraints or just plain naivety, and suddenly the backend team wakes up one morning to find a massive increase in load on their systems triggering alerts, and the frontend team believes its not their fault. This just feels like an innate risk to promoting a frontend team to owning an individual service living in the data center.
The optimist in me hopes this really is a quality of life improvement for the cattle. The pessimist in me fears this a way to begin patenting livestock.
> He most certainly did not. Of all the different takes out there, his is very weak.
I think Adam Neely did a good job explaining what infringement lawsuits mean in the context of popular music production. Whether or not you agree with the strength of his case on this particular lawsuit, well that's not quite the point I was trying to make here. Still, what do you consider to be a strong take on this case?
It's a fun concept, and maybe will be useful in some weird edge case of a lawsuit, but no. Most recent music infringement lawsuits seem to argue that some combination of the sound design, groove, rhythms, chord progressions, melody or reduced melody, structure, and lyrics wind up giving a song the same "feel" as a prior song, and that's the basis of the copyright infringement. Then pseudoscientific experts come in and pick and choose common musical elements that both the songs share to attempt to justify the claim, oftentimes wrongfully taking credit for inventing genre-wide defining musical elements. Adam Neely did a good job touching on this in his recent analysis of the Dua Lipa Levitating lawsuit [1].
An AI generated song machine would have to nail a lot more elements than just the melody notes to properly stop music copyright cases. In my view, a more interesting project that might be more effective in defusing lawsuits would be to try to catalog all of the musical tropes that define genres, then attempting to detect how common they are in that genre. In an ideal world, maybe this would be able to drive a metric of how similar specific two songs are vs. picking any two songs in that genre at random.
Most superstar pop singers have fantastic singing voices and great pitch control. Autotune shows up because of some mix of 1) the modern pop aesthetic demands superhuman tuning, 2) some degree of autotune artifacts are expected as part of the modern sound, and 3) it can intentionally be used as an effect (T-Pain).
To give some more detail about both 1 and 2 -
Pitch control is more than just hitting the note; its about how well you can onset at the right pitch, how well you can hold the pitch once hit, how well you can jump each pitch interval and land on the right pitch, how well you can pitch through different articulations, different vocal ranges, etc. The modern pop sound has accepted that superhuman levels of pitch control that lock the vocal into tune with the perfectly tuned synthesizers/samplers are more important than a natural sound.
Also, since we've been using autotune for so long, it has almost become natural. We expect to hear it to some degree on every track, especially in more difficult vocal areas. If it wasn't present, one might feel the song sounds "indie" or worse, dated.
Lastly, one thing that fascinates me about the autotune complaints are that it's just one stage of a very long vocal processing chain. To my ears, the tweaks provided by dynamics processors are much more dramatic than autotune when applied to a reasonably proficient singer. Autotune is just one step of a processing chain that can easily run through 10+ processors to end up at the right sound.
Oops, we lost your data - but don't worry, the team here all agrees that it was a mistake.