mr_crankypants

I can follow your hypothetical right up to the point where the union official commits career suicide by trying to piss off every member single member of the union in a single stroke, and no further.

How often do labor unions campaign to impose salary caps on their own members? The very idea seems out of character.

A preceding B does not imply that A causes B, it only implies that B doesn't cause A. Which doesn't really reduce the world of possible causal relationships by all that much, since there may be any number of other factors that weren't considered.

For example, it could just as easily be the case that adjustments to dysfunctional aspects of the company's internal politics improve both morale and productivity, but the morale change becomes apparent more quickly.

Local governments, too.

In my neck of the woods, there are departments that have to make do with whole teams of low-skill employees because, while a more skilled person could do the work of at least four lower-skill workers, they would also require two lower-skill workers' worth of salary, and you just can't be paying any one person that much money because that would be Government Waste.

I suspect that that fact and our beliefs around it are being reflected in market prices, albeit with some heavy discounting for the uncertainty inherent in there still being so many companies out there.

So many people's first instinct to respond by buying more shares of that company, thereby driving its price and market cap higher. That's a reaction that implies that we think that the general trend is toward Buy-n-Large. If we expected regression to the mean to be the driving phenomenon, then we'd be more likely to respond by selling.

(Disclaimer: I'm not suggesting that's actually how things work, just that a lot of us behave as if we think that's how it works, or should work.)

It seems that the endgame we're unwittingly asking for is WALL-E.

I honestly think that both of those are weak reasons. The first is a problem for other generations; on our own time scale we should focus on the problems that affect us on our own time scale. The second is just not compelling; space exploration is hardly the only endeavor that produces spinoff technology, and it's far from certain that it's the best or most productive way to do so.

There has only ever been one goal that has actually driven us to push our horizons further out into space, and I think it's the only one that really makes sense: We do it for the challenge and for the adventure.

As John F. Kennedy so famously put it, "We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills."

It might depend. In the case I experienced, sales, marketing and support were already in place and quite successful beforehand, and the acquiring company did an admirable job of teaching all three how to do less with more.

To take the example of support, pre-acquisition, the support team had a reputation for being one of the best and most knowledgeable in the industry. That reputation went up in smoke rather quickly when the acquiring company decided to merge support into their existing support vertical and adopt its existing policies, including things like requiring the support and the product development teams to communicate through JIRA instead of using informal channels like instant messages or (in exceptional cases) pulling a developer into the call.

The end result was that the mean time to find a resolution for the non-routine issues went from hours to days. Ironically, while management claimed this would reduce disruption for the development team, it actually increased the time that developers had to spend on supporting the support team, since it made communication so much more difficult. Which, in turn, means that it slowed down both customer support and product development by bogging them both down with paperwork.

> I can't think of a single large software company that doesn't regularly draw internet comments of the form “What do all the employees do?"

I also can't think of a single large software company that doesn't, in the long run, survive by either endlessly buying and extracting all the value out of smaller software companies, or creating a moat that makes it almost impossible for new competitors to emerge.

Having worked for a small software company that got acquired by a large one that used the former survival strategy, and therefore witnessed firsthand the subsequent doubling of headcount and simultaneous halving of overall productivity, I can offer one of what I assume are several possible answers: Paperwork. And lots of it.

There is one thing I really like about story points: Disagreement about them drives a whole lot of useful conversation, and can reveal communication problems and misunderstandings that are difficult to root out otherwise. That, in turn, should give the PO useful feedback to help with refining the requirements. Which means that story pointing meetings should, in theory, have a huge multiplier effect on productivity, where every hour spent on activities like story pointing saves many hours effort wasted on building unnecessary or mis-scoped or miscommunicated features.

But that requires a very engaged PO who really gets what grooming is really about. Also, I don't know what it is with MBA types, but it really seems like anything that can be turned into a KPI, will be turned into a KPI, without ever pausing to think about whether it makes any sense to do so. And that makes story points radioactive: In the absence of intense and intelligent regulatory oversight, their potential value is more-or-less negated by their potential for abuse and misuse.

Incidentally, this is what fascinates me about the Forth approach: The unflinching dedication to stripping the system down to only the things that you actually need. The problem I see is, the Forth way of doing it seems to assume you're working with an army of one. How do you scale that up to a modern product team that may comprise 10, 50, 100, even 1000 people?

Scrum, in particular, is a fascinating beast. Looking at how it was in the early days, you can see that a huge motivation was to try to get the non-development bits of the process under control. For example, one of the big ideas behind the whole sprinting thing was to limit the time during which the requirements could be changed to one day in, say, every 10. The whole idea behind "as a/i want/so that" was to try and make it so that a clear motivation and context were being communicated to the development team.

And then, over time, it became clear that, for whatever reason, management just wasn't going for it. So all these different bits and bobs pivoted and morphed and re-scoped into a process by which the stone tries to squeeze more blood out of itself.

IMO, the most valuable bit of Scrum isn't user stories, or story points, or sprinting, or having a Scrum Master, or burndown charts, or anything like that. It's the idea of having a single, designated person whose job is to tell people, "no": The Product Owner.

The dirty secret is, velocity is a crap metric. It unskeptically measures total things implemented, even though we all know that only a portion - I'm guessing often less than half - of those actually needed to be implemented. Meaning that the best way to increase a product team's actual productivity isn't to increase velocity, it's to maximize the average usefulness of features being implemented. Preferably by identifying the useless and less-useful ones ones, and deciding not to implement them. Or, equivalently, identifying the ones that seem most likely to be useful given the currently available information, and making sure those are always the ones at the top of the to-do list.

My suspicion is that, the better your product manager is at that particular job, the less need there is for any of the fancy ceremonies. Because most of those ceremonies aren't there for the developers' benefit; they're really only there to make it easier for the PO to scope and prioritize features.

The problem there is that most "libraries" are actually frameworks.

The difference I'm drawing being, libraries just provide a mess of utility functions. Theoretically, even if your compiler won't strip the library stuff you don't need, you'd be able to take just the bits you need by copy/pasting a relatively small volume of code. And dropping the library would be a small change, that just requires finding replacements for the functions and classes you were using.

Frameworks tend to involve some Grand Unifying Abstraction that you need to inherit from, and that gets imposed on your own code. Things tend to be so tangled together at a conceptual level that it's not really possible to use them in an a la carte manner. Migrating off of a framework tends to require more-or-less a rewrite of all the code that interacts with it.

To take some Web examples: jQuery's more on the library side of things. D3 is more of a framework. React is very much a framework.

I don't know what Moore would say. Personally, I've retreated to the back end - used to be full stack, but I'm just sick to death of how overcomplicated front-end work has become.

I'm inclined to say that, e.g., the modern browser is a cautionary tale that complements the Chuck Moore approach to things: By forever piling thing on top of thing in an evolutionary way, you end up with a system that ultimately feels more and more cobbled together, and less and less like it ever had any sort of an intelligent designer. Perhaps the lesson is that it can be worthwhile to occasionally stop, take a real look at what things you really do need, aggressively discard the ones you don't, and properly re-engineer and re-build the system.

Obviously there are issues of interoperating with the rest of the world to consider there, and Moore has made a career of scrupulously avoiding such encumbrances. But a nerd can dream.

The more time I spend dealing with blowback from excess complexity being imported in the form of 3rd-party libraries that offer complicated solutions to simple problems, the more I think that Chuck Moore was very, very right on that point.