Yes - I'll admit to being a bit pedantic on this topic. I've always worked in systems software development where you can't ship the product, or let the customer try it out in a meaningful way, without about 90% of the core capabilities being implemented and those capabilities are often most of the work in meaningful features. As well, there is no "single customer" - every feature is available to all customers (sometimes at an additional cost) so for long term success one must think beyond just the few situations that might have motivated a particular feature's development at this time - indeed, most eventual users of the feature may not be customers yet but may eventually become customers, in part, because the feature meets their needs.

In these environments, Transaction Management is not optional, Recovery is not optional, Redundancy is not optional, avoiding Performance degradations is not optional (i.e., the addition of a new feature must not degrade existing features beyond some minimal amount and the feature itself must perform adequately to be useful). Every new feature needs to take these, and other, aspects into account and they often represent the bulk of the work. Once in the field, one will discover that there are additional things that would be "nice to have" (either based on customer feedback or your own support issues) but these are often known in advance and were simply deferred as a feature not essential to the first release of the new feature and fell off the schedule to meet customer delivery commitments.

As well, in these environments, using "agile" methodologies as a substitute for up front architecture can end up with a horrible hack of an architecture and a system that, after a few years, is extremely expensive to add new features to. For example, I've heard the "agile" argument that feature A "didn't need recovery because the customer wanted it to be super fast [who doesn't want "super fast"!] and will deal with recovery for that feature in the application". As a result, feature A gets implemented outside of the system's consistent recovery model. Of course, we know what comes next, it turns out several customers really wanted some recovery so partial recovery gets added to A (largely outside of the main recovery model though - because that's really costly now because it wasn't done in the initial implementation and adding it now will degrade performance of the feature for the few customers who really don't care about recovery of the feature and have had their expectations set unnecessarily high for performance of the feature). Now, for years, you have two recovery models to consider in implementation of every feature - which can break your business far worse than having made feature A simply "very fast" and fully recoverable rather than an infected pus sack on the architecture that everyone needs to avoid puncturing when working around it.

However, I think the closer you are, for example, to the View of MVC, the more sense agile makes (or, maybe I'm just not very good at human factors aspects so my first pass usually sucks and I don't know why -- so user feedback is very helpful as early as possible -- I think a shell is a fine UI).

On the one hand, the explanation for a "shortage" of women in tech fields is that somehow they are excluded because of gender in spite of being otherwise indistinguishable from men (for example, no different than men in skills, desires, education, or training).

On the other hand the linked article includes, without critique or outcry,

[...] founder Megan Tweed, who says that women's ownership of social skills not only opens up opportunities for them over their geek brethren - that technological savvy can flow from these social skills. "Women understand relationships, and tech's about relationships too [...]"

without being slammed for sexism by implying that women tend to be stronger in some skills (in this case social skills) than men because of gender.

Let's try some word substitution and see how that might fly

[...] founder Mike Tweed, who says that men's ownership of technical skills not only opens up opportunities for them over their socialized brethren - that social savvy can flow from these technical skills. "Men understand technology, and tech's about technology too [...]"

There seems to be a double standard here. It's unreasonable to fail to label a claim that "women have better social skills" due to gender as sexist while labeling a claim that "men have better technical skills" due to gender as sexist.

In my career in systems software development, the overwhelming majority of my colleagues and reports have been male. In senior positions, I think the average skill set of females has been higher than the average skill set of males. However, in junior positions, I think the average skill set of males has been higher than the average skill set of females.

What I have noticed is that the less skilled females seem to drop out of the development arena more quickly and in larger percentages than males. I don't know why this is. Perhaps...

• some females got into the field because attempts at diversity steered them towards a career which they didn't actually have a passion or aptitude for and are happy to get out of?,

• males have fewer options outside of software development (perhaps because Megan Tweed's apparent premise that females have superior social skills is accurate so jobs requiring those skills are less available to mediocre male developers)?,

  males are more likely to have some form of ASD and that helps with concentration, obsession, and attention to fine detail which can be quite useful in systems software development?,

  males and females are socialized differently at an early age and (unsurprisingly) that is reflected in their priorities and interests?,

  males are less willing to admit that they made a bad career decision and then take action to rectify that?,

  males feel more pressure to earn as much money as they can for their families so try to stay in higher paying positions?,

  males are (much) less likely to have babies and decide not to return from maternity leave after realizing how much it sucks to be towards the bottom of the skill heap.

Who knows...

Managers introduce methodologies like Agile because the word "sprint" seems to mean that they can overwork you.

Although, I don't think that's the primary reason that managers like agile.

As far as I can tell, the primary reason is that they are completely unable to manage and plan long term and agile is a perfect refuge for those who lack these skills but nevertheless covet the 'manager' title.

(Oh, and because it sounds cool - like "Pivoting", "Cloud Strategy", "Leveraging Our Strengths", "Coopertition", etc.)

In the area I live, we have something referred to as "tenure" for unionized public elementary and high school teachers.

What this roughly means is that once a teacher is past their probationary period (something around two years I think), they can only be let go for gross misconduct (like showing up drunk too often and swearing at their students in a drunken slur) and only after a lengthy and costly hearing process (during which they collect their pay but are assigned duties that don't put them in contact with students or simply do not come to work).

During probation, they can be fired for incompetence, but once they make tenure that's extremely difficult.

Teachers can still be laid off if staffing needs decline - but then seniority rules. The most recently hired is the first laid off. I think this is within classification - if a decline in students results in the need for one less Science teacher, I think the least senior Science teacher goes even though there is a less senior Art teacher at the same school/district.

Maybe the tax software development department at Intuit got jealous of the Quicken software development department.

Perhaps the tax folks saw the Quicken folks changing the colors in Quicken X++ and tweaking a few settings to make sure that online banking no longer worked for older releases and coming out with a new version every year with little work. Then they looked at the actual work (gasp!) they have to do every year to conform to new tax laws and decided to find some way to extract more money to keep up with the Quicken scam.

[Actually, I suspect there's just a cron job at Intuit that makes these software "upgrades" to Quicken automatically every year. They probably don't even have to hire a contract programmer. Unfortunately (for Intuit) someday someone will unplug the dusty old 286 machine in a closet somewhere that does this work because they assume it must not still be in use and Intuit will realize too late they didn't come out with a Quicken #### that year.]

There have been extraordinary advances in our understanding of science and technology in just the last few hundred years. We can now do something effective about disease, drought, and the like. It's now counterproductive to expend the energy on worshiping an extreme being in hopes that they will resolve these things -- that energy would be better spent addressing the problem with science or engineering.

Unfortunately, religion brings with it irrational behavior that disrupts society. Consider the Crusades or, more recently, radical Islam killing "non-believers" (well, not really NON believers, believers in a slightly different mystical entity). Or, consider the bigotry justified by religion that is widespread in the United States.

Nothing prevents people from helping others in their society who are needy even though neither themselves or those they are helping believe in a deity.

IMHO, religion is now largely superfluous and, on the balance, does more harm than good. Unfortunately, humans evolve slowly so the genetic propensity to follow a religion will probably outlast mankind. However, I wish I could see the look on the face of the last human as they realize they are going to die and their imaginary god isn't going to do a thing about it.

...refute ID or any notion of a god (or, to avoid offense, God).

It's really hard to find a recent (last 40 years) validated scientific result that validates, rather than debases, long held religious beliefs.

Decades ago "factory religions" (i.e., the smart ones, faced with irrefutable evidence, decided to abandon their beliefs and retrench in a new fantasy) abandoned the notion that God (who?) created everything in seven days.

The ignorant and unscientific still cling to "Intelligent Designer" fantasies just as the Taliban (ISIS et al) do to their irrational beliefs. Eventually, all of these will crumble under the advance of logic and reason and the sheer weight of evidence.

Humans, for good ecological reasons, seem to want to create a "supreme being". Even as recently as the Dark Ages, this was probably helpful. When all looks bleak, 1000 civilizations that give up because logic dictates that are are going to fail will fail. One of the 1000 that have the "God Gene" and persevere against all logic may survive and propagate their sperm.

We are all likely offspring of that flawed logic and it is our duty to crush support of that logic just as we, much more recently, reversed our opinions on slavery (i.e., anyone you can beat into submission is now your property).

charged excessive fees to people trying to leave the scene of a hostake crisis after public transit was shut down

Okay, the government decides to shut down the government subsidized/run public transit (i.e., reneges on their implied commitment to their customers) and you blame a company that tries to provide at least some people a substitute service? How do you suppose Uber might increase supply of drivers to meet demand? Hmm..., maybe they could offer drivers more money to show up and offer rides? How might they fund that effort? Hmm..., how about by charging the consumer more?

This is a case, fairly rare actually, where supply can actually be increased to some degree almost instantaneously - but there has to be a motivation to the supplier to do so. If an Uber driver is at home gardening because they decided that the pay for rides wasn't high enough to motivate her to offer rides instead of garden at that moment, the most efficient means to get her to change her mind and thereby increase demand is to offer her more money. This is no different than how employers staff their positions -- if they have a need that they can't fill, they increase the pay until a qualified person is motivated to take the position.

From what little I know, Uber does seem like a pretty crappy company but I don't see how them utilizing well understood market forces to match supply and demand is a bad thing.

Agreed - but if one considers cost vs. benefit, two monitors may have a bigger payback.

Private offices are expensive (but well worth it IMHO), but it's hard to convince management of that today. Most of current management were raised w/o private offices while in the trenches and don't realize the stark contrast. Those of us who routinely worked in private offices decades ago see that contrast clearly.

It's difficult to "try" private offices to see if they work better for a particular small/mid sized organization. However, it's not hard to "try" second monitors (or perhaps enormous 4K monitors now) to see how they increase productivity for a few and then deploy incrementally if they pan out.

Spoken by someone who probably never had a house cat snap at their forearm and have one of their fangs neatly catch the middle of a tendon as it sunk in. True, not as bad as a lion or tiger, but weeks of pain and discomfort nonetheless. And, it was our cat who did this -- a rescue cat who was very affectionate but had, shall I say, some "quirks" that if your attention wandered could result in suboptimal results.

Not quite. One has to add the cost of capital, depreciation of assets, insurance and other operating expenses to the product price also. For example, these robots are not "free" and themselves require raw materials to build so their initial and operating costs must be amortized over all the stuff they pick. Similarly, the warehouses don't just spring spontaneously from the ground when Bezos says "let there be a warehouse".

and far more costly at night

A great opportunity for an innovator to develop lunar panels to supplement solar panels! That reduces the problem to moonless nights.

One problem with discussions like this is that there is a lack of consistency in titles and job role naming across companies.

For example, in some companies first level managers of developers are not very technical (fortunately, I've never worked at a company where this was the norm) and can only manage work units and people but not solve technical problems themselves or provide detailed technical guidance. They can be good people managers, good at working the politics, good at making sure that the project dependencies (both inward and outward) are being tracked, and good at protecting the group from abuse. However, they need to rely on project leaders/lead programmers for the technical stuff. In other companies (fortunately, the most of the ones I've worked at as a developer or a manager), managers are de facto project leads and/or psuedo-architects and are able to (and do) look at code, review specs, make technical decisions when necessary.

Similar story for "project managers". At some companies they just push lines around on PERT charts and note and track that there's an issue that needs to be resolved by next Thursday about if the asdfasdf is to provide some data to the lklkjfsdf or if the lklkjfsdf should independently fetch it. At other companies, "project managers" would actually know what asdfasdf and lklkjfsdf were and be able to understand, at some level, that lklkjfsdf couldn't possibly independently fetch the data because security policies don't allow it no matter how loudly the owner of asdfasdf insists otherwise (and, knows who/how to bring in to shut the owner of asdfasdf up).

It's November and 1L students have been in class for a while.

HLS should teach vocabulary on the first day of class to 1Ls - particularly the meaning of the words "frivolous" and "standing". Sad that these students managed to get an undergraduate degree without understanding the meaning of those words and their applicability to lawsuits.

OTH, maybe they will learn a lot from this experience as the judge laughs uncontrollably and the entire courtroom joins in. Oh, and sanctions them. Hopefully they get a judge who went to Yale Law School - double humiliation.

However, in a widespread outage like this, I'll bet the big cloud providers have a better record of rapid recovery than their customers had in-house. By necessity, MS, Amazon et al have very competent engineers who know the product well available to pull off what they are doing (including sleeping) and jump into any really serious problem. There simply are not enough such engineers to go around all the mid-sized IT organizations in the world nor interesting enough work to keep these engineers interested and sharp at most of these IT organizations (to say nothing of the cost of keeping such engineers around).

For a car analogy... When your high end car has a nagging problem that your local mechanic can't figure out, the dealer often can figure it out quickly, possibly with the help of a factory specialist who deals with (say) ECUs on only this make all day, every day. Rarely can an independent mechanic specialize enough to come close to the factory specialists in diagnosis. Now, if your car just has a dead battery, your local mechanic may give you faster, better, and cheaper service than the dealer.