Scott Bellware has posted something about perfection.
Ayende has posted a response to a post by Nick Malik.
As always read all the originals, as I'm going to be paraphrasing a lot, and so probably misinterpreting to make my point. Whatever that turns out to be.
So anyway, Scott, in his usual style, says in a number of paragraphs something that I think could be said in a sentence (see my own posts for a similar style):
"In software development, you cannot achieve perfection, but when developing, you should strive to achieve it."
I agree with this (well, to an extent, see below).
He includes this quote:
"The failure statistics for the software development industry is an expression of the dumbing-down of software development through short-sighted squelching of acts of perfection."
This is really wordy, but the 'dumbing-down' part is important.
Ayende, in his usual style, disagrees with Nick pretty much completely, and includes this:
"Sorry, I really can't accept this approach, and while it explains some of the stuff that Microsoft puts out, the only thing that it helps is to stifle innovation and development on the platform."
A number of things jump out at me when I think about what both Scott and Ayende said, and try to tie them together.
1) My dissertation was entitled "The Conceptual Theory of Meaning: God, The Universe, and Everything." It was by far the longest dissertation in the history of the Department of Philosophy at the University of Miami (at something like 150,000 words, I had to make the font typeface almost illegibly small to get it to bind in the book properly), with I think the longest dissertation defense in the history of the department.
Trying to sum it up quickly, the main thrust as it relates here was something like this:
The meanings of words are tied to something I called 'Conceptual Schemes'. To the extent that people share the same Conceptual Scheme about a subject, communication works. But, when you talk about almost anything of complexity, a massive amount of time ends up figuring out how people's Conceptual Schemes differ.
When it comes to Nick's understanding of 'Mort', his Conceptual Scheme is radically different from, say, Ayende's, Sam Gentile's, Scott Bellware's, and a host of others. Because of this, that portion (and more) of the blogosphere though Nick was out of his mind when talking about Mort being inherently agile. They were all using the same term, but because of the significant difference in Conceptual Scheme, conversation broke down very very quickly.
But while I think that is important in understanding the nature of conversation in meaning, that's not the most important point here.
2) Starting with Ayende's point, though I think it dovetails with Scott's point as well, what he objects to in the proliferation of 'no code' designers/wizards/etc. is that they place a default level of 'imperfection' in the 'no code' (btw, there's always code, you just don't write it yourself, so the claim that no code is needed when using designers/wizards/etc. has always struck me as stupid) that is produced.
While 'dumbing-down' may be more pejorative than required, there is something to this. When you use the wizards, you don't get the strictest separation of concerns that you can. Hell, in many cases, you don't get much of any. Ayende has been working with SSIS in places recently, and I've had experience with that. You use the nice drag and drop stuff and for basic functionality, it works perfectly. Get the *slightest* requirement to do functionality more than basic, and you fight with the IDE tooth and nail. In SSIS' case, you have all these XML crap documents and if you try to hand-edit them, all goes to hell. If you have a flat file that doesn't fit exactly the basic types (csv, fixed-length, ragged right) and you face the prospect of having to write obscure custom code, and only in VB since C# isn't supported, implementing obscure interfaces, generally you end up (in my own cases at least) jettisoning SSIS altogether and handwriting long T-SQL scripts because that's the only way I could get the code to do what I wanted it to do *precisely*.
And then I read this comment from Ayende:
"I am a Mort on quite a few levels (the entire WinFX stack comes to mind), does this mean that I am bound to write unmaintainable code and should be locked down to a very small set of "safe" choices, which were chosen for me by those Above Me ?"
And it made sense. It was exactly (I think) the same experience I had with SSIS. I've gotten (apparently) very good at hand-writing T-SQL. SSIS prevents me from writing the code that I know needs to be written, because it prevents me from easily writing what I need to write.
And I started to think about Scott's claim that the Entity Framework prevents you from doing TDD/BDD. I always thought this was an absurd claim and asked him (more or less) "Don't you just mean you can't refactor easily?" To which he responded (more or less), "Yes."
And so, what I'm starting to 'get' is basically this: when you absolutely need to have the code do what you absolutely need it to do, Microsoft's tools almost always get in the way. The tools generate code for you (so, so much for 'no code'), and unless you are a masochist, you don't want to try to modify that code.
This also begins to explain to me why people are high on things like . I philosophically don't like Rails in general, the idea of throwing out (basically) all controls and having to hand-write every single control you want to use makes me cringe (you can't really use them even though they are 'supported'), and having to do it in a PHP style syntax makes me cringe even more. But isn't this exactly what I did with my T-SQL? Screw the pretty auto-generated SSIS stuff, I want to do *exactly this*.
3) Having said all that, Nick's general point, and Microsoft's general trend, are correct.
When I work with SSIS, a large majority of time, it does exactly what I want it to do. I don't have to hand-write all that crap. It just does what it needs to do.
Because I am *painfully* aware of when it fails, I know to look for this. But, with the people I work with, most of the time, it doesn't fail. It does what it needs to do.
And for a huge percentage of people, the John Matthews' of the world, the tools that Microsoft provides do just what needs to be done. And for those people (and when I say 'those people', I *absolutely* do not mean it in a derogatory fashion), to force them to learn the depths of T-SQL would *greatly* inhibit their productivity, in the same way that if I had to go back and learn how to do garbage collection in a non-CLR environment would inhibit my own. I don't *want* to have to know about any of that.
To repeat my paraphrase of Scott Bellware's point, "In software development, you cannot achieve perfection, but when developing, you should strive to achieve it." As I try to deliver value to clients, I try to do this every step of the way, to the best of my limited ability. And to Ayende's point that Microsoft's tools limit (one could say 'prevent') one's ability to extend beyond what they dictate, I can't really disagree with that either.
But, ultimately, in yet another post, maybe, I would expand on why their idealistic dream that everyone who develops in .NET would even need to extend beyond the tools is, for the lack of a better term, 'silly.'