http://qs321.pair.com?node_id=883816


in reply to Nobody Expects the Agile Imposition (Part VI): Architecture

I find myself pondering, more and more and more these days, precisely how much “really new” code there now needs to be in this world... and, how long we are going to continue to run that code on “our” machines.   I am beginning to suspect that we might well see core business functionality becoming a “software service” that is “hosted in the cloud,” such that the role of traditional software development – scrum or otherwise or what-have-you – just might change quite radically.   We might soon find ourselves being referred to as “assemblers,” tho’ not in the traditional computer sense at all.   Having built more-or-less the exact same things so many times, we ought to be getting very good at being able to buy them, instead.   We say that we build, applications.   But, is that definition changing before our eyes?   If the only thing that you need to do anything is a web browser . . .

Replies are listed 'Best First'.
Re^2: Nobody Expects the Agile Imposition (Part VI): Architecture
by fullermd (Priest) on Jan 24, 2011 at 04:54 UTC
    We say that we build, applications. But, is that definition changing before our eyes? If the only thing that you need to do anything is a web browser . . .

    Well, speaking as someone who for a living writes things that happen in a web browser, the definition sure seems about the same. I have a pre-written cross-platform UI toolkit with a weak but usually sufficient set of control primitives... but the hard part of most applications isn't assembling the UI anyway.

    I tend to believe that if the set of pre-written inter-pluggable primitives ever actually becomes rich enough to do all the stuff we "program" to achieve, all we'll have really done is just made a new programming language; it's not qualitatively different, and it's still going to require people with the same skill set as "paleoprogramming".

      I tend to believe that if the set of pre-written inter-pluggable primitives ever actually becomes rich enough to do all the stuff we "program" to achieve, all we'll have really done is just made a new programming language;

      I think that was one of the lessons of the 4GL (forth generation language) movement. Any toolkit sufficiently expressive to cover all of the client's business cases inevitably needed the full set of control flow statements. It quickly ceased being something just anyone could use and turned into something that required a programmer.

      What makes programming programming is not the units we work with - bits and bytes vs. complex objects. Rather it is the logic that binds them together into something useful. Once that logic begins to include conditionals, loops and the need to organize collection of data and functionality into discrete loosely coupled sub-systems or objects, it requires, as you say, "the same skill set as 'paleoprogramming'".