Wednesday, November 16, 2011

The Pakled Philosophy of Development

A rambling, opinionated, and very poorly justified rant. Please don't shoot me, I'm just venting. 

A few months ago I blogged on my disenchantment with PHP.  It isn't just PHP, but Java, Perl, and ASP/.NET that make me feel similarly estranged.  The thing is, I want to work with languages, platforms, and systems that don't really, truly, deeply suck, on projects that are worth doing.  Sadly, that's a rare combination. 

I'm not sure exactly what it is about server-pages platforms that gives rise to such feelings of discomfort. I've worked with Joomla and Drupal and ASP sites, so perhaps it is in part the layering of immature cultural cruft inherent in their codebases that gives me the stray thoughts of "what a freakin' mess," and "are you kidding me?"  

But as convoluted as some poorly written components can be, it isn't the primary reason these platforms suck. They suck because, for a dollar you put in today, you have to put a dollar plus change more in tomorrow just to keep the stack from completely collapsing in on itself.  In effect, these platforms encourage a kind of codebase Ponzi scheme or a development Hell.

"We look for things."

All development builds upon previously constructed artifacts. Those artifacts must be available, demonstrably functional, and comprehendible to contribute to the next generation.  Our objectives should not be merely to "make things go", but should include incorporating our knowledge into our archetypal forms, a process of language refinement.  With PHP, Java, and so many other languages, we focus our efforts on entraining more and more information into the platforms, like some sort of junk DNA as it were; the languages and libraries grow in complexity much faster than they grow in value. Similarly, artifacts in these languages seem to have a very limited impact in advancing the system to higher levels of functionality. 

Web Developers using server-page approaches produce piecemeal patchworks of solutions that last for a few months to a few years. Do such systems get increasingly easier to understand and maintain, or do they get increasingly cluttered and ever more risk laden?  Is there repeatability, refinement, increasing transparency, and data unencumbered by private licensing, or a daily slog of Development Hell?

PHP systems rarely gain the level of maturity needed to be approach either self-consistency or completeness and closure over a domain.  The intelligent fall-back position when you're ignorant is Lean -- sacrifice completeness and reduce the feature set to that which is minimally viable. Focus on what provides value. But if you just want to make it go, Pakled style, even when provided sufficient resources it won't contribute to the process of exposing and refining the domain language. Developing a domain language to incorporate new knowledge simply isn't a value proposition that is often pursued in that development culture, and it isn't well supported by the language. 

In mathematics, there is the concept of the derivative. In the context of a function that plots a curve, the derivative tells you the rate at which the function output values are changing at a given point on the curve: it tells you the slope, as it were.   In order for solutions to remain viable over time, the slope of the curve of revenue generating features must be greater than the slope of the curve of hidden costs and intangible liabilities.  Otherwise, you're creating a shell hollowed out of real value.  My sense on server page technologies is that feature incorporation has a relatively flat slope, the cost curve increases more rapidly, and hidden liabilities arise very abruptly and without warning.

For most clients of technology, it is a lose-lose proposition: they know they need to spend the money to stay in the game, but the game is rigged with goods frequently subject to erratic and unplanned obsolescence. 

But that begs two questions. Are there any more sustainable alternatives? Would a more sustainable alternative slow down the pace of innovation? I don't pretend to know the answers but after blathering on in this article, I at least understand some of the reasons why languages like PHP rub me the wrong way. 

No comments: