2015-05-09

The End of the SCRUD Kiddy

(Preliminary musings on an upcoming crunch, which will penalise developers at large.)

The transistor, a simple device, enabled the microprocessor and the ubiquity of electronic computers. The arrival of these in turn heralded the arrival of wide area networks until their densities resulted in the fabric of electronic data transfers over Internet protocol. This fabric, or landscape, or space was insecure. Much data came within the grasp of many individuals, of various skill levels. It didn't take much effort for anyone to acquire a few popular patterns of electronic instruction... and to blindly deploy these towards the loosening of data. Some called these exploiters, "script kiddies."

That cycle of events, brought great liquidity to the global interpersonal communications. The subset of these which was the global financial system, also, experienced a similar opening of access levels. Cash, came within the grasps of many individuals, of various skill levels. It didn't take much effort for anyone to acquire a few popular patterns of software development... and to blindly deploy these towards the loosening of venture capital. I got out of the shower one Saturday and decided that I could, for the purpose of a short essay, call these exploiters, "SCRUD kiddies."

This isn't the first such cycle for finance - as the telegraph preceded the WAN, the public stock market preceded the venture capital ecosystem of today. History proceeds in what some romantically call a helical fashion.

The security of financial capital is increasingly protected behind the guarantees of enterprise branding, which separates the confederated developer from the developer at large. Eventually, the CRUD app developer who is incapable of administering systems beyond his or her stack, faces eventual extinction. While SCRUD kiddies may rely on PaaS-es to handle scalability, this promises only long-term lock-ins with vendors. The only alternative to this appears to be the establishment of open source PaaS frameworks, or infrastructure stacks that provided standard, it-just-works scalability to the SCRUD kiddies. 

Such automation of infrastructure erodes not the value provided by the SCRUD kiddies, except when the automation of business logic-customisation becomes accessible by non-technicians. Already, the availability of drag-and-drop workflow design tools, and the subsequent application of code generators, provides a compiler front-end which may receive input from non-technical systems designers (read: business users). Should it become possible for this "compiler front-end" to seamlessly target the compiler back-end which is an open-sourced PaaS as described above, then the SCRUD kiddies are rendered redundant. This is the goal of software developers who sell application workflow automation tools at this point in time.

So where are our open-sourced front- and back-ends for such a compiler toolchain, that takes input from business users, and spits out scalable software CRUD applications? I suppose, this is a market I am studying at the moment, with the likes of Superails (http://github.com/jerng/superails).

(Perhaps, to be continued)
Done jotting down thoughts from this morning's post-shower... only had to postpone that by 11.5 hours...
.
Next meeting in 12.5 hours. Erm. Heading home to rest. Perhaps some studying. But first perhaps a walk. And before that, perhaps some housekeeping. And before that...

No comments :

Post a Comment