Professional Sports, Or Programmers And Public Speaking?

Whom does the following quote describe: athletes or developers?

The attainment of certain skills unavoidably gives rise to an urge to show them off. At a higher level of mastery, the performer no longer wishes merely to display his virtuosity—for the true connoisseur can easily distinguish between the performer who plays to the crowd and the superior artist who matches himself against the full rigor of his art itself—but to ratify a supremely difficult accomplishment; to give pleasure; to forge a bond between himself and his audience, a shared appreciation of a ritual executed not only flawlessly but with much feeling and with a sense of style and proportion.

The author is talking about professional sports, but it strikes me that the same thing is true of programmers who although being intraverted still have a desire to speak in front of an audience. Via A Hail Mary, A Deep Connection « Gucci Little Piggy.

“Planning” and “Doing” In Software Development: A Lesson For Product Managers

Taylor confused the logical proposition that planning and doing are distinct functions with the empirical claim that these two functions are always best performed by two distinct classes of people endowed with distinct educational pedigrees, clothing styles, and patterns of speech. The one is nonfalsifiable; the other is simply false. Cutting up your food and eating it are distinct functions too, but it is not the case that they are always best performed by two different people. In manufacturing businesses, separateing planner from doers sometimes makes sense; but, as Japanese carmakers proved to the dismay of their American rivals, getting the doers involved in the planning can result in higher-quality products and lower costs.

— Matthew Stewart, “The Management Myth”, p 55-56

I see a lesson here for software product managers: if you get the developers involved in the product planning process, you may end up with higher-quality products. The developers are not mere tools that serve the ends of your planning process; they can be very useful in helping you devise and define that product, espeically since they are the ones that have to actually build the thing.

Efficiency vs Quality in Software Development

Implicit in Taylor’s approach is the idea that management always aims at the single goal of effciency (understood as labor productivity). But efficiency is just one of several possible competing goals that management might pursue. Profitability, customer satisfaction, or maintaining good community relations can always conceivably outweigh the goal of efficiency. Later management theorists have argued that Taylor’s obsession with efficiency came at the expense of the goal of quality.

— Matthew Stewart, “The Management Myth,” p 54

I cannot help but read that paragraph and think of software development practices. We want efficiency of algorithms, but the quality of the code (understood as its comprehensibility and maintainability by other programmers) is an equally important goal.

Symfony Components: Sometimes Decoupled, Sometimes Not

Previously, on decoupling and dependencies, I said: “Some [Symfony] commenters were dissatsifed with my use of unit testing requirements to discover what a package really depends on, as opposed to what its composer.json file states.”

I’m willing to allow that the Symfony commenters here might be right. Let’s try looking at Symfony’s claims and see how they stack up. Regarding the decoupling of their components, the Symfony website states:

Beside being a full-stack framework, Symfony is also a set of decoupled and standalone components.

What is a Component?

Symfony Components implement common features needed to develop websites. They are the foundation of the Symfony full-stack framework, but they can also be used standalone even if you don’t use the framework as they don’t have any mandatory dependencies.

That page then lists the following as their “decoupled” “standalone” components that “don’t have any mandatory depedencies”:

- BrowserKit             ~ EventDispatcher    ~ Routing
+ ClassLoader            + Finder             - Security
+ Config                 - Form               + Serializer
+ Console                + HttpFoundation     + Templating
+ CssSelector            - HttpKernel         ~ Translation
~ DependencyInjection    + Locale             ~ Validator
~ DomCrawler             + Process            + Yaml

After reviewing the master Github branches for the components’ composer.json files, and in some cases the code itself, I conclude that Symfony’s claim of “decoupled” “standalone” components is clearly true for 11 of those packages (marked with a + above) and clearly false for 4 of them (marked with a -). I think the claim is debatable for the remaining 6 components (marked with a ~) and I may take up that debate at some later time.

The 11 components for which Symfony’s claim is clearly true are: ClassLoader, Config, Console, CssSelector, Finder, HttpFoundation, Locale, Process, Serializer, Templating, Yaml. These composer.json for these components has no “require” for another Symfony component, and my brief review of the codebase did not reveal any hidden dependencies.

The 4 components for which Symfony’s claim is clearly false (i.e., composer.json notes at least one “require” for another Symfony component) are:

  • BrowserKit (requires DomCrawler)
  • Form (requires EventDispatcher, Locale, and OptionsReslover [which is not listed in the components])
  • HttpKernel (requires EventDispatcher and HttpFoundation)
  • Security (requires EventDispatcher, HttpFoundation, and HttpKernel)

As such, I think it is clearly false that all Symfony components are standalone and decoupled with no mandatory dependencies. Does having mandatory dependencies make it a bad project? Not at all. It just means their statement of “no mandatory dependencies” (and related statements) is not true for all the components listed.

Now, it may be that the Symfony folk have a different idea of what “decoupled” and “standalone” mean. Are they decoupled from the framework? Sure. But are they decoupled from each other? The answer appears to be “not always.”

In comparison, all Aura packages (aside from the Framework package as previously noted) are fully decoupled from the framework composed of them, and also from each other. There no mandatory dependencies, and there are no suggested/optional/sometimes/maybe dependencies. Does that alone make it a good project? Not at all. It just means my claim about decoupled packages in Aura is completely true.