I don't know, I've had some years where without "off" would also make sense.
396 karma · joined May 26, 2018
There's nothing wrong with that, but if you're a user of one of these services you might take it as a hint to find an alternative.
Meanwhile, component makers will surely be spinning up more capacity, some of them in a foolhardy manner, and if the bubble does burst, 3-6 months later we'll be seeing fire sales on components and component makers going bankrupt (or getting bailouts, if considered of national importance)
I would much prefer a really well-crafted ios Native App with extensive attention to detail than anything, even a web app made with similar detail (in most cases). And also ios apps are far more likely to receive that level of attention than just about anything else.
Fixed time and fixed scope is essentially impossible, except in trivial cases. What I read the author saying is that he chooses to make it fixed time and has flexibility around scope in his work, because the requirements are more like loose descriptions than a description of exactly what a product should do, while ignoring edge-cases. That sounds like a nice situation. And a perfectly fine way to manage an engineering team. But it also sounds a bit to me like an abdication of responsibility to the engineering team by product, to allow the engineering team to decide what exactly the scope is. Again, that’s a perfectly good way to do it, but it means that product can’t come back and say “that’s not what I was expecting, you didn’t do it.”
I don’t think the author really tackles estimation here, nor the reasons why estimation is a hard and controversial issue, nor what junior engineers are looking for when googling “how do I estimate?”
The real reason it’s hard in this industry is that in general, product controls both scope and time, which are the two major dials by which delivery is managed, but abdicate responsibility for them by going an ill-defined but nonetheless more fixed (and unyielding) scope than described in this article, then demanding engineers give them specific date estimates to which they’ll commit, and work free overtime if they turn out to be wrong.
The author correctly defines a way to resolve this conflict: give engineering more say over scope—but fails to recognize that the root cause is not poor estimation, but rather that product or management denies engineering much say over scope past the initial estimation, and then demands they set fixed dates they commit to before enough is known. Death march projects, in my experience, are generally a failure of product, not engineering.
As an example in US government bureaucracy, government software teams digitizing forms at one point weren’t allowed to utilize features like autofill or automatically filling fields based on previous answers because it would relatively disadvantage users using paper forms.
Government capabilities do need to serve everyone, and from the perspective of the whole society that is beneficial, but they are often are of low quality to the individual consuming them for this very reason.
Let’s exclude taxes, because obviously many people would hate them under any circumstances. Does the government do a good job providing the other services people interact with regularly? Do people love their visits ti the DMV? Are they satisfied with their interactions with the police? Heck, in my town, just renewing a dog license is a pain.
Most obviously, why do executives need to be the proxy to customers? Why can’t development teams simply talk to real customers? This isn’t just an abstract idea in agile, it grew out of actual Japanese product development practices practiced at large organizations: Toyota, Canon, and others, and documented in “The New, New Product Development Game” HBR review article that was so influential to early agile.
The point that in large organizations, most of the work is coordination, again demands the question, why? It’s been understood since at least World War I by some military planners (with organizations far larger than Google) that coordinating dependencies was far more complex than reducing or minimizing them. Goldratt wrote about it when designing a project management system for Theory of Contraints (indeed, you could argue this is a fundamental learning of ToC). And one of my favorite software conference talks of all time is Mary Poppendeck’s excellent “Tyranny of the Plan,” where she notes that as computer systems have been used in planning, we seem to have become more confident but no more competent in coordinating, rather than focusing on flow, in large-scale projects.
Finally, on the importance of software created at large organizations, I agree, something that will have millions of users on day one has a greater responsibility, but that doesn’t mean that loads of bureaucracy and checking are the pathway to quality software. First of all, does anyone believe that highly scrutinized and bureaucratic functions are general high quality services? The often provide access to even the most extreme edge cases, but they do so by reducing the quality of service to everyone else. Anyone who’s ever filled out their own tax forms in the United States knows that it covers every base of possibly income, but 80% of people really only need to be concerned with 2-3 common forms, and 99% could simply be asked about 10 forms or so. Instead we have to answer questions for “directors of foreign corporations who also happen to be Us citizens,” instead of just requiring those people to fill out an additional form. And, of course, to (probably badly mis-)quote Deming, “you can’t check quality into a product.”
I would turn it around in the author: yes, the software practices operate this way in large orgs because large orgs are structured differently—but why do large orgs need to be structured that way? Is it inherent when absentee owners with low domain context (shareholders) pass ownership over to a manager? Is it because hierarchies insulate good but not great managers from genuine value creation as long as they play politics well? Is it because these are first order ways to understand complexity, and again, low-context absentee owners aren’t going to do the work to understand the more complex dynamics at play?
Whether they were worth removing is another question, but if you could flip a switch and magically replace them with something better (with no cost and a guarantee the replacement would not be a murderous authoritarian) you would of course do it.
The former is the scammy type, the latter is the type we love to work with.
But the same is true in any industry. Too many of us in technology are doing the technology equivalent of 1--becoming experts in C++ or React--instead of becoming deep domain and user experts.
Although illegal now, San Francisco used to have a widespread practice of "key money"--a bribe you paid the landlord to choose you to rent the apartment that due to rent control or other factor was priced below market demand.
Because the landlord was capturing the extra value directly, a cultural practice of high broker fees never developed there, while it did in the east, where bribes were less common. Thus someone other than the landlord captured the excess value.
It's also entirely possible that the broker's fee is being illegally passed as "key money" to the landlord in a way that's harder to detect/litigate in NYC because it's not direct from the tenant.
Now, not a lot of developers are really doing this. But it's still a good reason for those who are.
Simplicity is great, how can we combine it with the 17 other frameworks we saw on HN this week and have to use?
Astro is an SSR more tuned to generate static sites than SSR with hydration. It uses the islands architecture instead of full page re-hydration. So if you’re generating a static site with a few react components sprinkled in, it’s a good thing to use.
Because of the islands architecture, you can also mix and match component libraries. So one component can be react, one can be vue, one can be svelte, etc.
Next and remix are both less focused on SSG than Astro. A lot of people are making very content driven sites using react or Next—sites that aren’t really or shouldn’t be SPAs—and this is a great tool for content driven sites that don’t benefit from SPA-level interactivity (which is probably most sites using SPA frameworks)
I mean, there's a large body of evidence (I personally like the economics methodology of this study, which has been repeated many times: https://www.shrm.org/hr-today/news/hr-magazine/pages/0203hrn...).
But just like many will never be convinced that vaccines are safe and the earth is round, many will never be convinced that racism in the US is real, I suppose.
After that, these two groups were substantially discriminated against in law, and other races were added to the mix to be given less rights than others.
Today, there are huge disparities between outcomes for different races in large part due to this historical discrimination. There's also an ingrained culture of stereotyping and discrimination that's hard to lift. It doesn't matter if you're the first generation of Americans descended from African immigrants who came in the 1980s... you still are impacted by this legacy.
The concept of affirmative action was to specifically counteract the effects of these negative, historical circumstances and provide a countervailing effect.
I can't speak to other countries, but in the US, it is definitely the case that poor people of color have a harder time getting ahead than equally poor white people. (I suspect it's similar elsewhere, but we are also a pretty racially diverse country, so the effect is larger)
720p is fine for watching movies, even if it's not home theater perfect. But it's absolutely fine and way better than the alternative of watching on a terrible IFE seatback (which probably gets the aspect ratio wrong)
"MVC was conceived in 1978 as the design solution to a particular problem. The top level goal was to support the user's mental model of the relevant information space and to enable the user to inspect and edit this information."
This sounds a lot like event sourcing.
I did a deep dive reading the early papers and watching the lectures from the 70s, 80s and 90s on this a few months ago. The early Xerox employees developing smalltalk seem to have originally thought the idea of encapsulation would compose at all levels. That as object interaction got more complicated, you would simply group a few related objects together inside a larger object, and the rest of the application would use that encapsulating objects interface, and you could go infinitely deep that way while managing the complexity. Later, in the 80s, Kay would talk an about writing objects in smalltalk then gluing them together with a glue language (usually Mesa C), because he felt smalltalk worked well for programming in the small but not the large.
Again, I think erlang got a lot right here, using a different model for programming the small (functional) vs programming in the large (actors/otp).
But to hear the OOP pioneers talk about objects, they consistently describe the objects not in terms of data but in terms of behavior, similar to Erlang actors being processes. Each object is supposed to represent a “computer” and the network of objects is supposed to work like a distributed system.
I know which mental model I like better, but objectively, it’s a very different concept from what most developers think of as OOP today (although very similar to microservices).
The source is Trygve Reenskaug, the originator of the idea.
How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persistence would be necessary, of course, but an implementation detail. Models were smart and mapped to human perceptions of a thing, rather than dumb data persistence layers.
These kind of business logic operations have often been moved into controllers, which couldn’t have been further from the original intention.
MVC, smalltalk, OOP we’re all about stopping and thinking about the way humans think while interacting with computers. It was about designing nice interfaces for interaction based on human expectations, not database requirements. Internal object schemas and data persistence were implementation details of an object that could—if you did it right—be easily changed without changing the interface.
But we can’t help ourselves, and instead OOP today is a world of getters and setters with a little bit of data validation (if we’re lucky) and models are just a schema plus a generic data persistence interface (maybe an orm). And the business logic exists in the controller, the least important, least reusable component of the architecture.