> Building a piece of software is or at least was orders of magnitudes more expensive than maintaining it
This feels ludicrously backwards to me, and also contrary to what I've always seen as established wisdom - that most programming is maintenance. (Type `most programming is maintenance` into Google to find page after page of people advancing this thesis.) I suspect we have different ideas of what constitutes "maintenance".
A strict definition would be "the software is shipping but customers have encountered a bug bad enough that we will fix it". Most work is not of this type.
Most work is "the software is shipping but customers really want some new feature". Let us be clear though, even though it often is counted as maintenance, this is adding more features. If you had decided up front to not ship until all these features were in place it wouldn't change the work at all in most cases (once in a while it would because the new feature doesn't fit cleanly into the original architecture in a way that if you had known in advance you would have used a different architecture)
> If you had decided up front to not ship until all these features were in place it wouldn't change the work at all in most cases
In my experience (of primarily web dev), this is not true, and the reasons it is not true are not limited to software architecture conflicts like you describe (although they happen too). Instead the problems I usually encounter are that:
* once you have shipped something and users are relying on it, it limits the decisions you are allowed to make about what features the system should have. You may regret implementing feature X because it precludes more valuable features Y and Z, but now that X is there, the cost of ripping it out is very high due to the backlash it will cause.
* once you have shipped an application, most of the time when you add new features you are probably slightly changing at least some UI, and so you need to think about how that's going to confuse experienced users and how to address that in a way you wouldn't have to when implementing something de novo. For an internal LOB app, that might mean creating announcements and demos and internal trainings that wouldn't be necessary for greenfield work.
* the majority of professional web dev involves systems with databases, and adding features frequently involves database migrations, and sometimes figuring out how to implement those database migrations without losing data or causing downtime is difficult and complicated.
* as web applications grow their userbase, the scale of the business often introduces new problems with software performance, with viability of analysing business-relevant data from the system, or with moderation or customer support tasks associated with the system, and these problems often demand new features to keep the broader business surrounding the software afloat that weren't needed at launch.
* software that has actually launched and become embedded in existing business processes inherently tends to have many more stakeholders in the business that care about it than pre-launch software, and those stakeholders naturally want to get involved in decision-making about their tools, and that creates meeting and communication overhead - sometimes to such a degree that stakeholder management and negotiating buy-in ends up being an order of magnitude more work than actually implementing the damn feature being argued about.
To the extent that the amount of work involved in implementing a new feature is inflated by these kind of factors relative to what would have been involved in doing it de novo, I personally conceive of that as "maintenance" work; and in my experience my work on big teams at successful businesses has on average been inflated severalfold by those factors. (I also count work mandated by legal/compliance considerations that arise only after a successful launch as "maintenance". My rough conception of "software maintenance" is that the delta between "the work involved in building a product de novo with the same customer-pleasing features that ours has" and "the work we actually had to do to incrementally build the product in parallel to it being used" as "maintenance".)
Would most people agree with my broad notion of maintenance? I reckon they roughly would, but it's hard to say since people who talk about maintenance rarely attempt to define it with any precision. You give a precise but extremely narrow definition above. Wikipedia likewise gives a precise but extremely broad definition - that maintenance is "modification of software after delivery", under which definition surely over 99.999% of professional software development labour is expended on maintenance! I guess my definition puts me somewhere in the middle.
More importantly, employees with options are generally not sophisticated enough to realise liquidation preferences may exist and may dramatically devalue the common stock options they have, and even if they are sophisticated enough, they will often have no means to find out what liquidation preferences exist. (They theoretically have information rights that probably entitle them to that info, but companies simply find spurious excuses to refuse books and records requests, knowing no options holder is going to drop six figures on a lawsuit to exercise those information rights.)
Liquidation preferences that merely guarantee you get back the cash you put in before anyone else gets anything are a perfectly reasonable protection for investors.
Otherwise, the risk is investors put in $1m for 10% of the company, only for the founder-CEO to decide a month later - perhaps totally genuinely and honestly after initial R&D - that the entire business plan wasn't viable after all and the best thing for stockholders is to liquidate the company... and then walk away, personally, with $900k while returning only $100k to the investors. And obviously because this scenario is possible, there would be great temptation among dishonest founders to "realise" their companies "aren't viable" in order to walk away with all the cash. Something has to protect investors from this outcome, and remove the perverse incentive on founders to promptly liquidate after getting investment. A liquidation preference where the investor gets repaid before any distributions go to other stockholders is one way of achieving that protection; what alternative would you prefer?
As for liquidation preferences with a multiplier (i.e. we get paid back X times our investment before anyone else gets anything), eh, I wouldn't outright make them illegal, but it's less clear to me they are always serving a legitimate purpose, and they may grossly mislead the public about the actual valuation of the company implied by a given funding round AND mislead naive common stockholders and options holders about how much of the company they really own and what they can really expect to make in an exit.
I wouldn’t mind liquidation preferences with a multiplier so long as they are served after the 1x preferences. That way someone can’t come in and reap 900k on a 100k investment while the rest of the shareholders walk away with 1/10th of their investment.
At the heavy end, SUVs weigh about 3 tonnes, while at the light end buses weigh about 12, a 4x difference. 4^4 = 256. So if the claim about the fourth power is true, you'd need to replace 256 SUVs to break even on wear, which is obviously impossible.
(I don't really understand how the fourth power of axel weight thing can possibly be true, though. Why would joining two vehicles together into a mega vehicle with double the weight and double the wheel count suddenly cause the combined vehicle to inflict 16x more wear than before you joined the two together? It makes no sense.)
A Ford F-150 weighs about 2 tons and has two axles, for an axle weight of 1 ton. 1^4=1.
A garbage truck weighs maybe 30 tons and has three axles, for an axle weight of 10 tons. 10^4=10,000.
So if you drive an F-150, you’re doing as much road damage driving down the street 10,000 times as the garbage truck does once. Rural areas that don’t have garbage trucks and just expect everyone to haul their garbage to the dump in the back of their pickups are onto something.
Ah, right, sorry, I misunderstood the definition of "axle weight" I got when I hurriedly googled it even though the name should've made the meaning obvious.
The classic British Routemaster double decker weighs 7.5 tonne and can be configured with 72 seats. Newer double deckers weigh 12.5 tonne and have a capacity of 60 seated and 20 standing.
Doubling the weight and doubling the wheel count leaves the axle weight unchanged.
Plus the SUV is usually point-to-point, leave home, go to work, come back. Whereas the bus is going back and forth ten times per day.
In Europe, the numbers differ even more. Lighter weight cars typically 1.5-2 tons, a new London bus can be upto 18 tons when loaded - that's ~5-16 units of wear for the car to 104,976 units for the bus...
But this is all supposing we're optimising for road wear, which isn't really the point of a bus system.
I certainly claim that almost nobody "commits" that "fallacy" and that it is not a remotely notable viewpoint in the civic discourse of any country I know about.
No doubt in a world of 8 billion people, there exists someone, somewhere, who has for some reason voiced the belief described - i.e. that if institutions really heavily based their selection of applicants on skin color rather than merit, that would be good, but that because in reality institutions have only been convinced to somewhat compromise on merit-based selection in favour of skin-color-based selection, it's bad, and should thus be abandoned completely in favour of total meritocracy. But that belief would really be rather odd, and I have never seen it expressed even once in my entire life.
Nor am I convinced, despite its oddness, that it is properly considered to contain a fallacy! After all, sometimes it really is the case, for various reasons, that some endeavour is only worth doing if total success can be achieved, and not worth the downsides if you can only succeed partially. No doubt if someone really held the allegedly fallacious view described, they would believe affirmative action is exactly such an endeavour and be able to explain why!
You haven't remotely described the alleged critics' belief. Which is that since scholarship recipients still drop out at a higher rate, the scholarships don't work.
How many people actually hold such beliefs is a debate between you and the author.
I assume someone typed it in (possibly on a mobile device with autocorrect) rather than copy & pasting it (which you would have to do twice, for the URL and for the title).
Well, actually, no, not everyone is free to use alternatives. Anyone using CI for "Trusted Publishing" of packages to PyPI or npm needs to use GitHub Actions or GitLab CI/CD. CircleCI and Travis CI are not supported. So many big open source projects for the two most popular languages in the world are now locked out of the alternatives you propose.
(I find it extremely sketchy from a competition law perspective that Microsoft, as the owner of npm, has implemented a policy banning npm publishers from publishing via competitors to GitHub Actions - a product that Microsoft also owns. But they have; that is the reality right now, whether it's legal or not.)
I was never convinced that trusted publishing solves any security problem, other than letting pypi eventually solve the problem of banning russian/iranian/whatever people just by relying on github doing it for them.
Trusted Publishing on PyPI supports Google Cloud and ActiveState as well. It’s not tied to GitHub or GitLab. To my recollection I looked at CircleCI support a while back, and ran into limitations on the claims they exposed.
(It can also be extended to arbitrary third party IdPs, although the benefit of that is dependent on usage. But if you have another CI/CD provider that you’d like to integrate into PyPI, you should definitely flag it on the issue tracker.)
The 30% figure is "correct" if you look at the absolute number of deaths instead of deaths per VMT. But I basically agree with you; that clearly the wrong stat to cite if you are attributing the change to vehicle safety regulations.
Even that is still wrong because you'd have to use the high water mark during COVID and not the more recent numbers which are starting to come back down.
2020 wasn't just the start of Covid, but also the start of BLM. The narrative I always see from the American right is that BLM caused many police forces across the US to radically reduce traffic enforcement, since:
1. traffic offenders are disproportionately black,
2. stops for minor traffic offences can sometimes spiral into violence in various ways, and some viral ones have involved absurdly bad use of force decisions by officers involved, and
3. no force wants to take the blame for another George Floyd
Per this narrative, a significant antisocial tranche of the public has responded to the effective suspension of traffic law in the way that you would expect them to, and that is why road deaths are up.
The timing lines up but that's more of a vibes argument.
The majority of traffic stops in the US are, cop parks on the side of the highway somewhere the speed limit is lower than the speed people drive there, every car on the highway is doing 70 in a 55, whoever drives past gets a ticket and the government fills their coffers but the speed everybody actually drives on that stretch of highway remains 70.
Now suppose the cops stop doing that for the stated reason. If you then drive past them at 110 instead of 70, are they still going to not pull you over? Good luck with that. Even if they're actually trying to minimize traffic stops, that one's the one that makes the cut.
So then what happens if they stop doing the usual ones? People are then going to drive 70 in a 55 because they can get away with it, but that's what they were doing to begin with. You could argue that the fatality rate would be higher at 70 than 55, but then why would that change relative to the baseline where that was what was already happening?
So the argument would have to be that idiots had the impression that they could do 110 without getting pulled over, even if that wasn't true, and then did that and managed to make contact with an overpass before driving past a cop. Which doesn't seem as plausible, because speeds like that on empty desert highways shouldn't have raised the fatality rate that much (e.g. it's not that high on the autobahn in Germany), and speeds like that in traffic where there are other cars traveling significantly slower will trigger a visceral feeling of danger in nearly all humans unless they're on drugs or have significant mental health issues, and in those cases they wouldn't have been deterred by the prospect of traffic enforcement anyway. Which is why people drive somewhat over the speed limit even when that could get them a ticket -- because it doesn't feel dangerous -- but also why they don't drive a lot faster than the other cars -- because that does. Traffic enforcement or not.
Moreover, regardless of how much of a contribution was made by that vs. COVID, the numbers still don't line up with it being vehicle safety regulations.
I would guess that what matters most is stops for driving disqualified/uninsured/unregistered, DUI, running lights, and failing to yield (especially at crosswalks), and perhaps for speeding on non-highway roads where it has more of a safety impact. As you say, in the USA as in virtually every culture, almost everyone speeds in some contexts, and especially on big, multilane, motor-vehicle-only roads; enforcement of speed limits in that context is likely one of the lowest impact things police can do, but I think it's a massive error to treat "traffic stops" as a category as equivalent to that sort of enforcement specifically.
I assume you're an American? As a Brit, your comment confuses me. Why would anyone ever have high beams on at all in anything reasonably described as a "neighbourhood"? Do built-up areas in the US not reliably have street lighting?
Here in the UK, it is pretty much universally the case that if there are buildings, there are street lights. (Maybe there are occasional exceptions where there's a single building in the middle of nowhere on a rural road; I'm not sure. And I suppose there must be occasional outages of street lighting even in e.g. dense city centres. But such things are rare.) Having high beams on in almost any context where there are buildings around is therefore unnecessary, against the Highway Code, and quite possibly criminal under RVLR reg 27.
I'm not the one you asked, but I think a lot of 'wealthy' neighborhoods in the US mean suburbia with larger single-family-home lots, and roads often feel a bit more rural. In my area in California, these are often unincorporated (county) lands just outside larger towns.
You sometimes see a very clear boundary. The more middle-class housing is subdivisions built all at once somewhere in the 1960s-2000s, with underground utilities and street lights. This infrastructure was mandated by the city, when the developers were looking to get their newly built neighborhood annexed into it. Around the next corner, darker streets with overhead utilities and more spread out lots with oversized "McMansion" houses. These are following the more relaxed county building codes and had the space available for such construction.
These roads are also more likely to have expensive new cars with all the computerized functions. Walking in this limbo world at the edge of our town, I've also noticed being blinded by cars as a pedestrian with more dynamic effects. I suspect are the car's system actively painting me with more light. It is a little bit like the "fringing" you see when the cutoff of older HID projection lamps sweeps over you due to road undulation. But it happens too quickly and both vertically and horizontally. It feels like being hit with a targeted spot light.
I wish the engineers spent the same care to put a dark halo on a pedestrian face as they do for oncoming drivers. Even when carrying my own flashlight, such encounters can be dazzling enough to basically go blind and not be able to see the dark paving in front of me for a minute. My light is more to make me visible to the cars than to really illuminate my path for myself. It doesn't stand a chance against the huge dynamic range of these car lighting systems.
This feels ludicrously backwards to me, and also contrary to what I've always seen as established wisdom - that most programming is maintenance. (Type `most programming is maintenance` into Google to find page after page of people advancing this thesis.) I suspect we have different ideas of what constitutes "maintenance".
reply