> Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production.
I used to think this was true, but after talking to architecture/civil engineering friends a lot about this, I've learned that this is less true than I believed. There are often changing requirements for buildings due to different use cases, changing regulations or building codes, or a change in energy prices (or the social cost of using a lot of energy). Sometimes new technologies are used without a lot of experience with them, leading to high operating expenses for the lifetime of the building.
I asked my friend about your comment and he gave me a few interesting examples: 1) "flying form construction" that leads to exposed concrete slabs on buildings that bleed heat in the winter. This was really cheap to build but turned out to be really awful for energy efficiency (once we started caring). 2) a building in the 50s-60s that was built with automatic window blinds. The maintenance cost of fixing the blinds when they inevitably broke led to them not getting fixed, and the building becoming basically useless.
If you're interested in reading more about this, Stewart Brand's "How Buildings Learn" is a really good read for laypeople. I was really surprised by how much of the book could be applied to software engineering.
(This is not a field I'm familiar with so any errors are mine, not my friend's.)
"500 Lines or Less" is an entire book of articles just like this. Each chapter guides you through a small (500 loc or less) implementation of a common component (eg a web server). http://aosabook.org/en/index.html
When you say cyclists in Toronto can be awful, what do you mean? Are they mean to you, or do they not follow the rules of the road, or something else?
When I cycle I fear being killed by a motorist; when I drive I fear killing a cyclist. It's important to clarify whether cyclists are putting you in danger or if they are stressing you out. Both suck, but one sucks a lot more.
Most of them are good. But i've seen many run red lights, go the wrong way on a one way street, i've been nearly hit by cyclists a few times. In terms of driving with cyclists, I think the main thing is lack of space more than actual actions. So an infrastructure problem. When driving what tends to give me pause is people acting out of place. So someone jay walking, or a cyclist cutting across lanes, as I then need to be more aware for people doing things incorrectly.
You are quite right in terms of where the danger lies though. It's on the driver more than any other to be the most careful with their actions.
The rules are not made for cyclists, and you can see that in their riding. When you expend your own power for every acceleration and have better vision & hearing, a red pedestrian light with nobody using it suddenly looks less absolute. A one-way street that can easily take 5 of you next to each other, and probably nobody even driving there, when the way around is 500m longer - the same.
You can see the same behaviour from car drivers when the rules don't make any sense (as for example in some upcoming countries).
This is a great teaching moment for anyone who works in UX or observability, but it's worth keeping in mind that the FCC's Public Safety and Homeland Security Bureau (who operate the Emergency Alert Service (EAS)) has a yearly operating budget of around $17MM this year. The system itself was launched in 1997.
This is a legacy software (and hardware!) system with a relatively small budget and number of employees that needs to coordinate with other large organizations (FEMA, HI-EMA, NOAA, etc.). I think the most interesting lessons to learn from this have to do with long term software maintenance. I'm sure folks at the FCC/*EMA knew that this UI was janky but why did they not have the budget/power to fix it? How do we ensure that the public sector can benefit from the technical advances that most people on hacker news take for granted? Curious to hear from folks with experience in relevant parts of the government.
> I think the most interesting lessons to learn from this have to do with long term software maintenance.
Yes! And with re-engineering too! When you redevelop a system, you need to build up historical knowledge of its antecedents, and teach it to the current operators and maintainers. You shouldn't just start from scratch from the requirements.
In this case, there was an even older legacy system that had a similar incident in 1971, which they then mitigated. Apparently that lesson was lost.
> …In the past three tapes, one for the test and two for actual emergencies, were hanging on three labeled hooks above the transmitter… In the future only the test tape will be left near the transmitter. The two emergency tapes [will be] be sealed in clearly marked envelopes and placed inside a nearby cabinet.
I once got contracted to integrate with a large government web app that was created with some sort of legacy SPA generator. The app was written in .NET and the js on the page would render the views from specs it would get over XHR from the .NET app. It positioned everything on the page absolutely and everything was styled with inline styles. The people who manage it were quoting outrageous numbers to do the simplest style changes because it was so hard to work in. Very few improvements ever got made because the money was just not there in the budget to pay these ridiculous quotes.
They're making a joke about the misspelling of Matt Damon. "Daemon" is a computing term [0] and /sbin/ is a folder that you might want to put a Matt Daemon in. (Also, daemons are often named with a "d" at the end, like "etcd" or "mattd".)
> But the author's idea that you should generally plan to soldier through to newer code if things go wrong during deployment as a standard operating procedure betrays a lack of experience and sends a dangerous message.
The author says "reverting smaller diffs as a roll-forward is more verifiable" near the end of the article. I agree the title makes this a bit confusing, but I don't think he's arguing that the only way to recover is to write a patch under pressure.
Reverting a smaller diff is writing a patch under pressure. Reverting a section of your new code is just as difficult as authoring a new fix. You need to be just as sure that the partial revert will not interact poorly with other parts of the new code that you are not reverting.
> You need to be just as sure that the partial revert will not interact poorly with other parts of the new code that you are not reverting.
By partial revert, I'm imagining that three people have changesets (A, B, C, in that order) that have been deployed. You notice that A broke and you make A' to revert it. I think the author is arguing that it is easier to review A' to see if it is a safe change than it is to verify that A', B', and C' (the full revert) are safe to revert.
In other words, even if you don't use version control to record that you reverted A, B, and C, you still effectively do that by reverting in full. You just know that the combination of A', B', and C' was safe when it was deployed.
Is that what you're imagining or are we talking about different things? (I don't have strong opinions about this, I just want to make sure I understand your perspective (: )
Reverting smaller diffs out of order to roll forward IS a patch under pressure. Usually most interesting features, the kind that tend to cause bugs that are not caught until deployment time, tend to come in as several patches over time. So reverting those means cherry-picking a set of patches, making sure you got the full set, making sure no subsequent patches took some subtle dependency on the ones being pulled, and so on. If you're in a compiled language, the set of patches is not too big, and the churn on your repo is low, then you probably have a decent chance of getting it right under pressure even if you have to untangle some refactors and such. If not, good luck.
If you took all the time you spent writing comments like this and spent it instead on questioning why the norm for other companies is 10-90 or 20-80, we probably wouldn't be having this conversation quite so much.
Part of the reason why this announcement is significant is that people frequently argue that it is impossible to build a gender-equal team. This shows pretty clearly that it is possible. I don't think this is equivalent to saying that all companies need to be exactly even in the end.
> The men that don't get jobs because of these new 50-50 splits, where do they work?
Do you think there is a shortage of tech jobs? If the end state was equal for men and women it seems more likely to me that plenty of people would still be employed, but the best jobs would be going to the best people rather than just the best men.
Does all that make sense? I'm genuinely curious about why equality is uncomfortable for you.
It's certainly possible to build a gender-equal tech team. But to argue that all tech companies could build a gender-equal tech team, with the current hiring pool, is a hell of an assertion.
Two years ago, the university I went to (top engineering school in the Northeast US) hosted a big panel for computer-field majors at the annual admissions event. Any students remotely interested in technical majors were invited to attend - you didn't even need to be accepted to the university.
The marketing for the event makes it as clear as possible that no prior programming experience is required, they just want to get people excited about computing. When I served on the panel as a CS student, I looked out the audience and saw a fully packed room (300+ people) of almost entirely white/Asian male prospective students and their parents. At that point, how does the industry recover and get a 50/50 gender ratio? The problem seems to start way before industry, as much as some would prefer to think otherwise.
Can you look out at the audience and honestly say that all 300+ people are going to be good engineers?
There are a bunch of white/Asian males who suck at their jobs. If you don't believe me, note the demographics next time you angrily git blame something.
Stop hiring them. Easy.
The problem is from companies who care more about hiring someone at all than hiring good people. It's pretty well-documented that men are more likely to apply for jobs they're not qualified for than women (see, e.g. https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless...).
Then women should apply for jobs they aren't qualified for as well. Problem solved. You'd be an idiot not to do that.
There are a bunch of white/Asian males who suck at their jobs (there are a lot of people who suck at their jobs across all demographics really) but if that's the group of people who applied... well, I'd rather have somebody than nobody. I'm nog going to go walk around outside and find women on the street to try to get them to apply for a job. Plus, I'd probably have the cops called on me.
>"I'm genuinely curious about why equality is uncomfortable for you."
It's interesting how you straw-man the other person of being uncomfortable with a good-sounding word such as "equality". So, because they're against something noble as "equality" then they're automatically the bad guy?
I'm not the OP, but if you ask me I would tell you that we have different definitions of equality. People not like me want to write the wrongs of cosmic injustice and circumstance under the guise of fixing "discrimination" by treating people unequally. But really, at the end of the day, we would probably agree with you that equality is a good thing and we'd welcome a universe that was equal. But it's not; chance, circumstance and history dictate as much. It's not "equal" for the people being discriminated against so that this company can have a feel-good tick-box somewhere about being 50-50. Does this help out females that are potentially being treated unequally by society? Yes. Does this "throw out" perfectly good and capable males because they happen to be in the bath-water? Yes.
Two wrongs don't make a right. And it certainly isn't fair.
> people frequently argue that it is impossible to build a gender-equal team.
No one argues that. What is true is that it's impossible for everyone to have a 50/50 teams (because most fields don't attract precisely 50/50 men/women), and it also makes recruiting substantially more expensive if you hope to maintain a high and equal standard for both men and women. This is a consequence of the fact that, assuming skill distributions are roughly the same across genders, there are simply much fewer (in absolute terms) women of a given skill level than men of a given skill level in CS or engineering.
I've encountered this argument in real life. I agree it sounds a lot like a straw man though and doesn't help much with my argument -- thanks.
And I agree that it is more expensive to hire this way because of how diverse CS graduates are. Do you think it might be worth it in order to help nudge the industry at large in a more positive direction?
Not all programmers (engineer or otherwise) are guys -- probably worth keeping that in mind if you want this to be a welcoming community for everyone (:
I'm Canadian too. I sometimes use "you guys" when speaking to a group that has women in it; I don't use "guy" in the singular when talking about generic technical roles because it implies that being a guy is part of the job. In many cases this is effectively true due to sexism in the industry, so it's not something to take lightly.
I don't think this is what you intended, to be clear! But I do think that is how it would be interpreted, even by Canadian women.
Another article on the CBC from last summer has a good list of alternatives that I found helpful: http://www.cbc.ca/news/canada/bbq-cleaning-alternatives-bris...