Peanut, Peanuts, Get Yer Peanuts Here! This One Will Go On And On
Nick's thoughtful reply to my post, yet again deserves it's own post.
I have seen many magic quadrants, however they all tend to suffer the same limitation, they attempt to squeeze infinitely variable properties into a limited set of constraints or qualities.
I do appreciate that many of your comments of explanation were an attempt to explain away this ambiguity, but it still exists, I don't think Mort fits into any of those boxes (infinite axis / compressed attributes or not), as I don't think Mort follows any of the good coding practices built up over decades of development.
You also took only two of the Agile manifesto principles, ignoring the other two, which probably also excludes Mort from being Agile. In addition, Agile places more value on the items on the left, but it doesn't exclude them - for example you can be fully Agile, and yet provide totally comprehensive documentation.
Nick said:
I tried to make the case that the attribute that most greatly differentiates Mort from agilists, code maintainability, can be factored out of the equation if we constrain Mort to a "little or no code" or "disposable code" environment.
The qualification that Nick is excluding code maintainability within his criteria is a little bizzare, because in my opinion, maintainability is one of the most fundamental of good development practices.
We can constrain Mort to the "no code" environment, but does he know what happens under the covers when he calls a service? Does he know how many data access requests that might make? Does he know how to properly secure his requests? Sadly not.
We can also constrain him to the "disposable code" environment, and from a cost issue point of view, many organisations will hire Morts for precisely that reason, their business case doesn't justify doing it properly. But those organisations will almost certainly end up paying more in the long run, if not paying exactly the same in the short run in addition.
As I don't see Mort following any good development practices, he either isn't a professional developer (in any traditional sense), or development is heading down a very rocky road.
I believe there is a very good reason why it is exceptionally hard to produce high quality software via outsourcing, or via hiring a lot of Morts and a couple of Einsteins.
Development is not a technical craft. Development is part technical, part creative and part psychology.
You can mass train all the developers you like, and teach them all the technical aspects of .NET, C# or whatever other platform is flavour of the day, but you will have a hard time teaching them the psychology part, and creativity is impossible to teach. Nick is proposing that now they don't even need to know the technical aspect, just how to drag and drop.
So we are now heading towards the infinite monkey scenario.
As I conceded to Nick fairly early on in the debate, Nick may well be right that Mort is the future - I just don't want any of the aspects of my life depending on the software he is going to write!
Peanut, peanuts, get yer peanuts here!