Paul M. Jones

The Fallacies of Enterprise Computing is good throughout. It's hard to excerpt; here only some of the highlights:

• After building IT systems for more than sixty years, one would think we as an industry would have learned that “newer is not always better”. Unfortunately, this is a highly youth-centric industry, and the young have this tendency to assume that anything new to them is also new to everybody else. And if it’s new, it’s exciting, and if it’s exciting, it must be good, right? And therefore, we must throw away all the old, and replace it with the new.
• How is “the cloud” any different from “the mainframe”, albeit much, much faster and with much, much greater storage?
• [B]y using relational database constraints, the database can act as an automatic enforcer of business rules, such as the one that requires that names be no longer than 40 characters. Any violation of that rule will result in an error from the database. Right here, right now, we have a violation of the “centralized business logic” rule.
• despite the fact that many enterprise IT departments are building microservices, they then undo all that good work by then implicitly creating dependencies between the microservices with no mitigating strategy to deal with one or more of those microservices being down or out. This means that instead of explicit dependencies (which might force the department or developers to deal with the problem explicitly), developers will lose track of this possibility until it actually happens in Production--which usually doesn’t end well for anybody.
• The enterprise is a constantly shifting, constantly changing environment. Just when you think you’ve finished something, the business experts come back with some new requirements or some changes to what you’ve done already. ... [A]nything that gets built here should (dare I say “must”) be built with an eye towards constant-modification and incessant updates.
• The cloud has nothing magical in it that makes things scale automagically, secure them, or even make them vastly more manageable than they were before. You can derive great benefits from the cloud, but in most cases you have to meet the cloud halfway--which then means that the vendor didn’t make the problem go away, they just re-cast the problem in terms that make it easier for them to sell you things.
• No matter what the vendor/influencer tries to tell you, no matter how desirable it is to believe, there is no such thing as a “universal enterprise architecture”; not MVC, not n-tier, not client-server, not microservices, not REST, not containers, and not whatever-comes-next.

This is the third of three posts I intend to make regarding the condition and actions of the FIG, and what they reveal.

The Future

[By way of presenting some context: I was the driving force behind PSRs 1 and 2; I conceived and then led PSR-4; I was a primary author on some of the early bylaws, including the voting protocol and the sponsorship model. I am a founding member of the FIG, and one of the two longest continually-serving members (along with Nate Abele). My perspective on the FIG spans its lifetime of 7+ years. It is that perspective which informs these posts.]

Regarding the rivalrous visions for the FIG, I see only two ways forward.

The first is that somehow the tension between the two visions is permanently resolved. It is this ongoing implicit tension that is the cause of recurring conflict. There is no common vision between all FIG members, and this causes resentment and distrust; sharing a common vision will provide a level of shared values and views.

I think the only way to relax that tension in the group is for one of the rival visions to supersede the other in an unmistakable and permanent way. That means one set of vision-holders would have to explicitly renounce its own vision in favor of the other. This could be accomplished by voice (i.e., by stating so on the mailing list) or by exit (i.e., by leaving the FIG).

Even though that would leave the FIG (per se) intact, I opine that sort of capitulation is unlikely from either set of vision-holders. After such protracted contention, the holders of each vision seem unlikely to withdraw, and even more unlikely to adopt the competing vision for FIG. (As a defender against the introduction of the newer “grand” vision, I certainly don’t to plan abandon the “founding” vision voluntarily.)

The second is that the holders of each vision all surrender simultaneously, and disband the FIG.

Disband The FIG?

There is already some level of interest for this idea, both from the wider community and within FIG itself, especially in relation to the FIG 3.0 proposal. From the thread Alternative to FIG 3.0 - Is it time to call FIG complete? (you should read the whole thing) we have these points from Joe Ferguson in two different messages:

As someone who feels like FIG 3.0 is a step in the right direction, and can empathize with those against it, I’d like to offer an observation:

Maybe it’s time to call FIG complete. FIG accomplished it’s primary goals (Bringing frameworks together to build interoperable packages / standards).

…

My comment is that maybe its time PHP get a standards body, led by the people who want to see FIG 3.0 happen. Let your work in FIG stand on it’s own. PSRs aren’t going anywhere. Start a Standards Body Group that adopts the work you’ve done here and picks up all the currently in progress PSRs and continues working on them. Close FIG down since it’s work as a Framework Interoperability Group has been completed.

This would be a perfect time to start fresh, get your bearings, and sort your stuff out with all the lessons learned from FIG. I would rather see this than people oppose FIG 3.0 and it being shoehorned in.

If you take away absolutely nothing else from my comments: FIG 3.0 is such a shift that it warrants the consideration of a new organization with leadership based on the people doing the work to make things happen in FIG.

I feel a sort of resignation toward this idea. I don’t really enjoy it, but something like it has to happen, and it’s probably for the best.

It certainly would eliminate the tension between the competing visions for the FIG, as there would be no FIG to contest over.

Benefits

Let’s say, for a moment, that FIG dissolves itself, and the FIG 3.0 plan architected by Larry Garfield and Michael Cullum is realized as a new organization with a new name. What would be the benefits?

• As a brand-new organization, it can define its vision and mission without in-group rivalry.

• It can curate its membership, bringing in only the people and projects that adhere to its vision (and keeping out those who do not).

• It can establish any organizational structure (hierarchical or otherwise) from the outset, without having to worry about precedent or prior expectations.

• It can have any code of conduct it wants as part of its foundational structure.

• Whatever negative baggage is perceived as being part of the FIG is dropped.

I’m sure there are other benefits as well.

Drawbacks

There is one major drawback that I’ve heard voiced regarding a “disband the FIG and start a new group” approach. It is that new standards groups have a hard time getting off the ground. As one example, the PHP-CDS project does not seem to have gained much traction.

My guess is that an organization that forms after the FIG disbands would not have that trouble, especially given that FIG would no longer exist.

Note that some member projects such as Composer, Drupal, PEAR, phpBB, and Zend Framework have shown explicit support for the FIG 3.0 re-organization plan. I imagine that those projects alone would grant legitimacy to any new non-FIG group in which they were members.

Furthermore, as the architects of the FIG 3.0 plan, Larry Garfield is the Drupal representative to FIG, and Michael Cullum (while not a voting member) is directly involved with phpBB. The new group is guaranteed to have at least those two members from the start.

I have heard other drawbacks as well, but they seem primarily administrative in nature.

Administrative Issues

What happens to the accepted PSRs?

Accepted PSRs remain in perpetuity as the true product of the FIG, for any and all to adopt or ignore as they see fit. They were built to be immutable, and they will live on for as long as anyone cares to refer to them. Any new group that forms after the FIG would be free to adopt, or ignore, the finished PSRs (though it would not be free to claim them as their own).

What happens to the in-process PSRs?

There are at least two options here.

1. In-process PSRs might convert to *-interop projects, a la container-interop and async-interop. Indeed, Woody "Shadowhand" Gilk has had the foresight and initiative to create an http-interop group already.
2. If the migration out of FIG produces a new group, e.g. a FIG 3.0 style organization, that other group might adopt them in some fashion, perhaps by making those PSR owners initial members in the new group.

What about new PSRs?

After disbanding, no new PSRs would be admitted in any state.

What about the FIG website, Twitter account, Github account, etc. ?

I think this is the toughest problem with disbanding. It will be necessary to prevent the misappropriation of the FIG or PSR names after the group disperses, and at the same time make sure the various artifacts of the FIG (i.e., the PSRs) continue to be publicly available.

To that end, I suggest appointing an archivist (perhaps more than one) to receive ownership of the Github, Twitter, Google Mail, etc. accounts, as well as the FIG domain names. The job of archivist is is to hold the FIG name and accounts in trust and guard them from ever being used again. The archivist(s) might also merge errata and insubstantial changes on existing accepted PSRs, but I expect the activity on those should be minimal.

I assert that the archivist should be some nominally neutral party, one who has no designs on the FIG name or brand, and who has not participated in the production of PSRs or bylaws.

Finally, I would suggest that no follow-on group be allowed to claim to be the “successor” to the FIG, or somehow “approved” by FIG, but that’s a difficult thing to prevent. Members exiting the FIG would have to be on their honor for that one.

Conclusion

There is a tension in the FIG between two rival visions: a “founding” vision (mostly implicit through the history of the group) and a “grand” vision (explicitly described in the FIG 3.0 proposal). This tension reveals itself through things like the vote to remove me involuntarily, as well as ongoing conflict over internal processes, the direction and audience of PSRs, and other bureaucratic maneuvers.

The only ways to relax that tension are for one vision to supersede the other permanently and explicitly, or for the FIG to disband so there is no organization to contend over. Whereas I feel the former is unlikely to occur, the latter becomes the better course.

Disbanding leaves the products of the FIG intact (i.e., the PSRs). It also frees the holders of the “grand” vision to form a group of their own in their own way, to achieve their own ends without a competing group in place, and without compelling the holders of the “founding” vision to accede to a vision they do not share. The administrative issues of disbanding are minor in comparison.

Read the Reddit discussion about this post here.

This is the second of three posts I intend to make regarding the condition and actions of the FIG, and what they reveal.

The Present

The complaint against me (and the subsequent show trial and vote) are only a symptom of an underlying cause. The true cause behind the complaint, as well as many other events, is that there is a rivalry of visions regarding the FIG.

One vision holds that the FIG should remain true to its originating mission: focus on member projects, find existing commonalities among them through research and discussion, and codify those commonalities as PSRs. It is a more bottom-up approach, and is represented mostly implicitly, in the minds and actions of those who hold it. (Some artifacts of this vision remain on the FIG website, but I realize now they are not explicit enough.) I will call this the “founding” vision.

Another vision holds that the FIG should change its mission and broaden its scope to the entirety of PHP land, and in doing so accept the role that some people feel it should have: that of an overarching PHP Standards Group for all PHP coders, member projects or not. It is a more top-down approach, and is represented explicitly by the FIG 3.0 proposal. I will call this the “grand” vision.

These two visions are mutually exclusive. They are rivalrous.

This rivalry of visions might not matter, if the FIG had not already gained a level of perceived authority to many people in PHP land. It has earned a level of legitimacy through wide adoption of PSRs 0, 1, 2, 3, and 4 (and to some extent 6 and 7). That authority and legitimacy are valuable commodities, hard to come by among PHP developers (who are notoriously independent-minded). That means the FIG is perceived as a high-value property, which makes it worth being rivalrous over.

Those holding the “founding” vision, under which the vast majority of accepted PSRs have been published, believe the high value of the FIG derives from that “founding” vision and mission. Those holding the “grand” vision wish to use that value to launch what is effectively a new organization, without any achievements of its own, and claim the value built under the “founding” vision as its own.

To me, as a holder of the “founding” vision, the “grand” vision is an expression of conceit, of hubris. I think the holders of the “grand” vision believe they are entitled somehow to capture the successes earned by the “founding” vision, and claim those successes as their own. They have not earned those successes through the vision they espouse.

Until the conflict between these visions has been resolved, the contention within the FIG will continue, because neither set of vision-holders wants to relinquish the FIG territory.

I see only two ways out of this dilemma. I will present them not tomorrow, but the day after.

Read the Reddit discussion about this post here.

This is the first of three posts I intend to make regarding the condition and actions of the FIG, and what they reveal.

The Past

The show trial and subsequent vote to remove me has concluded, and I remain: the complainants were defeated, 15 to 9.

Now that the vote is done, I can assert openly that this was a “clearing the decks” operation. It was intended (in large part) to remove the most-vocal opponent to the FIG 3.0 proposal by Larry Garfield and Michael Cullum, and to prepare the way for implementing the Contributor Covenant (or some other SJW-inspired code of conduct). I predicted that conversations about both would resume very soon after the vote no matter which way it went, and that looks to have been prescient.

The complainants, and their secretarial collaborator, wanted a vote (not mediation) from the outset. I guess they figured it would be a slam-dunk to have me removed. What they didn’t expect was that roughly half of the participants would be either against my removal, or against the complainants themselves.

So instead of a slam-dunk, they had actual resistance on their hands. That’s why the secretarial collaborator dragged it out past the 2-week point, so there could be some chance of rallying support for the “removal” side. Little support was raised that was not shortly pushed-back against.

Then the complainants realized they had no options other than a vote, which they now thought they might lose. This is why they revived the idea of “alternative resolutions”. But they themselves presented no alternatives other than “shut up” and “go away”.

Even at the end, to keep their actions and their bias hidden, the secretaries suggested (to me personally) making the vote private, on authority they have not been granted.

Remember: the secretaries, in particular Michael Cullum, overstepped their bounds once again to enable this drama.

Even so, I must caution against reading too much into the results of the vote. The voters did not approve of me per se, so much as they disapproved of the complainants, the complaint itself, or the act of throwing someone out. It is not so much a vindication for me personally, as a repudiation of the complainants.

This is now all in the past, and a permanent part of the FIG. Tomorrow I will talk about the current state of the FIG.

Read the Reddit discussion about this post here.

I am currently modernizing a legacy PHP application for a client. (The codebase was written earlier this year, in fact; new code can be "legacy" from the outset.) The original developer pulled a dirty trick with global that I had not seen before, and I thought I had seen everything.

Legacy codebases often use global to import a variable into the local scope, usually a global function. For example, they might drag in a database connection:

<?php
// define $db in a config file somewhere
$db = new DatabaseConnection(...);

// this function uses the $db connection via global
function fetch_user_by_id($id)
{
    global $db;
    return $db->fetchAssoc("SELECT * FROM users WHERE id = ?", $id);
}
?>

I see that kind of thing all the time in legacy PHP. However, what I have not seen before is a function exporting a global.

Take a look at the following code. If the $bar variable is not already defined in the global scope, PHP will define it in the global scope for you automatically when you call foo().

<?php
error_reporting(E_ALL);

function foo()
{
    global $bar;
    $bar ++;
}

// $bar is not defined yet, so PHP will show an
// "undefined variable" notice
echo $bar. PHP_EOL;

// calling foo() defines $bar in the global scope,
// and increments it
foo();

// $bar is now available in the global scope, having
// been exported from function foo()
echo $bar. PHP_EOL;

The legacy developer did that because he wanted to keep the variable initialization outside of the global scope for some reason, even though he used the variable in the global scope elsewhere.

It is exceptionally difficult to track down where an exported global is coming from when refactoring a legacy application. If you must write legacy code using globals, initialize them in the global scope. Better yet, don't use globals at all: pass values as function arguments, or use dependency injection techniques.

Read the Reddit discussion about this post here.

As long as the Muslim population remains around 1% of any given country they will be regarded as a peace-loving minority and not as a threat to anyone. In fact, they may be featured in articles and films, stereotyped for their colorful uniqueness.

At 2% and 3% they begin to proselytize from other ethnic minorities and disaffected groups with major recruiting from the jails and among street gangs.

From 5% on they exercise an inordinate influence in proportion to their percentage of the population.

They will push for the introduction of halal (clean by Islamic standards) food, thereby securing food preparation jobs for Muslims. They will increase pressure on supermarket chains to feature it on their shelves -- along with threats for failure to comply.

At this point, they will work to get the ruling government to allow them to rule themselves under Sharia, the Islamic Law. The ultimate goal of Islam is not to convert the world but to establish Sharia law over the entire world.

When Muslims reach 10% of the population, they will increase lawlessness as a means of complaint about their conditions ( Paris --car-burnings). Any non-Muslim action that offends Islam will result in uprisings and threats ( Amsterdam - Mohammed cartoons).

After reaching 20% expect hair-trigger rioting, jihad militia formations, sporadic killings and church and synagogue burning.

At 40% you will find widespread massacres, chronic terror attacks and ongoing militia warfare.

From 60% you may expect unfettered persecution of non-believers and other religions, sporadic ethnic cleansing (genocide), use of Sharia Law as a weapon and Jizya, the tax placed on infidels.

After 80% expect State run ethnic cleansing and genocide.

100% will usher in the peace of 'Dar-es-Salaam' -- the Islamic House of Peace -- there's supposed to be peace because everybody is a Muslim:

Of course, that's not the case. Muslims then start killing each other for a variety of reasons.

Edited for brevity, from What Islam Isn't; see the original for lists of percentages and countries.

Let us take the second [argument] first. And let us strip it of the illegitimate emotional power it derives from the word ‘stagnation’ with its suggestion of puddles and mantled pools.

If water stands too long it stinks. To infer thence that whatever stands long must be unwholesome is to be the victim of metaphor. Space does not stink because it has preserved its three dimensions from the beginning. The square on the hypotenuse has not gone moldy by continuing to equal the sum of the squares on the other two sides. Love is not dishonored by constancy, and when we wash our hands we are seeking stagnation and “putting the clock back,” artificially restoring our hands to the status quo in which they began the day and resisting the natural trend of events which would increase their dirtiness steadily from our birth to our death.

For the emotive term ‘stagnant’ let us substitute the descriptive term ‘permanent.’ Does a permanent moral standard preclude progress? On the contrary, except on the supposition of a changeless standard, progress is impossible. If good is a fixed point, it is at least possible that we should get nearer and nearer to it; but if the terminus is as mobile as the train, how can the train progress towards it? Our ideas of the good may change, but they cannot change either for the better or the worse if there is no absolute and immutable good to which they can recede. We can go on getting a sum more and more nearly right only if the one perfectly right is “stagnant”.

And yet it will be said, I have just admitted that our ideas of good may improve. How is this to be reconciled with the view that “traditional morality” is a depositum fidei which cannot be deserted? The answer can be understood if we compare a real moral advance with a mere innovation. From the Stoic and Confucian, “Do not do to others what you would not like them to do to you”; to the Christian, “Do as you would be done by” is a real advance. The morality of Nietzsche is a mere innovation.

The first is an advance because no one who did not admit the validity of the old maxim could see reason for accepting the new one, and anyone who accepted the old would at once recognize the new as an extension of the same principle. If he rejected it, he would have to reject it as a superfluity, something that went too far, not as something simply heterogeneous from his own ideas of value.

But the Nietzschean ethic can be accepted only if we are ready to scrap traditional morals as a mere error and then to put ourselves in a position where we can find no ground for any value judgements at all. It is the difference between a man who says to us: “You like your vegetables moderately fresh; why not grow your own and have them perfectly fresh?” and a man who says, “Throw away that loaf and try eating bricks and centipedes instead.”

Real moral advances, in fine, are made from within the existing moral tradition and in the spirit of that tradition and can be understood only in the light of that tradition. The outsider who has rejected the tradition cannot judge them. He has, as Aristotle said, no arche, no premises.

(Extra line breaks added for readability.) Source: The Poison of Subjectivism, in which I am reminded how much I like C. S. Lewis' writings.

The advantages of Free Trade are lower prices for stuff. That means they are more cheaply produced. As the economist David Ricardo wrote, there is a principle of comparative advantage that coupled with free trade guarantees maximum profits for when there are no trade restrictions, and impediments to free trade are supposed to be mutually disadvantageous.

But do understand, what is conserved is lower prices. Nor social stability. Not communities. Not family life. Indeed those are often disrupted; it’s part of the economic model. Under free trade theory, it’s better to have free trade than community preservation, better to have ghost towns of people displaced because their jobs have been shipped overseas; better to have Detroit as a wasteland than a thriving dynamic industrial society turning out tail finned Cadillacs and insolent chariots and supporting workers represented by rapacious unions in conflict with pitiless corporate executives.

Source: Back to Normal. Beginning a discussion of Free Trade by Jerry Pournelle. He goes on to say that a "conservative" should ask himself, "What precisely is being conserved?"

Because of this "What is a senior developer?" conversation on Reddit, I am reminded of the Construx Professional Development Ladders, as mentioned to me long ago by Alejandro Garcia Fernandez. Here is a sample ladder for developers.

Higher-than-average intelligence doesn't make you any better than anyone else, any more than being taller, or faster, or stronger does. What it often does, however, is allow others to convince you that you should be something different than you are, or than you want to be. Even worse, it gives you the ability to successfully rationalize away your failures, to both yourself and others.

Nassim Taleb says something similar. Too often, "being smart" makes you better at rationalizing, not better at being rational. How much the worse if you make "being smart" part of your identity. (File under "being smart is overrated.")

Source: Vox Popoli: Always an excuse.