Let the tools do it for you?

Tim and Erv seemed to have taken this quote from my last post to task:

if you don’t understand all the specs, don’t worry about it. Tools are being created by people everywhere to make it so you can just indicate the capabilities you need and the rest will be done for you.

Erv referenced a piece indicating the problems we face when we accept pieces of our applications as black boxes and don’t understand what is going on under the covers.  I understand the concern, but there are some things that you should depend on the infrastructure to provide for you.

Let’s take security.  I don’t think any of us will sit down and start writing algorithms that factor large numbers so that we can do proper encryption.  Of course not.  When is the last time you wrote an SSL 3.0 implementation?  I started whipping one out the other day, but then I noticed that if you put the letter ‘s’ at the end of “http” it will actually do all that for you. 🙂

Microsoft is in the infrastructure business.  Among other things, we make operating systems for computers.  This allows people to write applications that solve their problems without having to remember what value to put in AX before making that int10 call.  Yes, let us do the digital signing and encryption for you when it comes to Web services.

Finally I just wanted to make the point that specs are not being created just to make specs.  We, and I assume the others in the industry, are constantly talking to our customers who have demanded interoperability, security, reliability, etc.  Let’s face it, while things like RSS are nice and simple and you can do a lot of things with them, there are business scenarios that need things like security, a message-queuing infrastructure, ATOM constructs.  If we can do all this in an interoperable way, that would be a good thing, right?  And fundamentally, we can still, even with all this infrastructure around us, still get at the angle brackets if we so desire.


Comments (2)

  1. The problem is one of obscurity. By limiting the number of paths a developer could possibly follow, you’re backing your developers into an architectural corner. With well-written, smaller components, that _are_ well documented, and provide the same access to core OS systems, Microsoft would be doing all of their developers a favor. Instead, we get these large, impossible to digest, over-marketed chunks that say ‘trust us’, but then can’t be made to work in the plethora of business models that actually exist in the real world (and usually they can’t be interpretted out of marketing-speak to get a decent model in the first place).

    Oh, and on the specs? I absolutely agree – except companies like Microsoft have to use them _and_ document them to be effective, not hide them deep in their QUOTE MSDN UNQUOTE website where nobody can find them.

    Not that I’m bitter, I only caught this post because I have to be… ~ AE