The World Where Nothing Works

I work in the World of Windows.

Software development, technical support, system administration – you name it. If it breathes Microsoft, I’ve given it CPR at some point. It’s a world where things are.. heavy.

And nothing works.

I’m a little jaded, nowadays. Part of it comes from the excitement I feel about my upcoming journey into the programming language called Python, and part of it comes from my analogy-generating brain which keeps comparing the work of publishing on this blog to the work of developing and deploying software using technologies such as:

  • C#, with Visual Studio, ASP.NET
  • Crystal Reports
  • BizTalk

You see – if I get one more “Unrecoverable build error” message after trying for the umpteenth time to build my Crystal Reports project that was building fine a few minutes ago, or if I get one more cascading series of breakages with the most unhelpful “symptoms” ever in a BizTalk Orchestration, well then I’m just gonna.. reboot. For good.

I am trying to be fair. As far as programming languages and runtime environments / deployment scenarios, I’ve barely scratched the surface with Python. I’ve only been “tinkering” with it for a few days. And I realize that it might not be the language of Python that is already making me feel better about the development process. Very well it might be that my code does not seem to reach in mysterious ways deep into the bowels of other software components which work in mysterious and unexpected ways. Also, it sure helps that my programs so far have been short-short-short. I really just haven’t done much yet.

But I have to say, there is something very liberating about firing up the text editor, and starting to write a program, without first spending 15 minutes configuring my project and solution files to work just as I like them. For all the good that Visual Studio’s project files give you, they are also an obstacle when you just need to quickly do a one-off project. Yes, I know I can keep a “scrap” project around where I can work with new code while doing my coding research, but somehow that sort of thing just doesn’t seem to be in the spirit of Microsoft C# programming. In any event, I don’t do it that way – it would seem like co-dependence.

Who really knows what my experience with this new outlook on programming will seem like in a few months. In any event, the best way to learn something is to get contrast, so working in a new language and runtime environment is sure to teach me more about my old-style fuddy-duddy C# programming work.

And, the second point, about analogies between system development / deployment and blog writing?

In writing a program, if something goes wrong it goes drastically wrong. Everything falls apart, and you typically can’t really move forward. This is true in all but the simplest of programs.

Why is that? Why should it still be that way, after eons of advances in programming languages and environments. Sure, things like the garbage collector in every modern language help a wee bit, but there’s still a significant problem which is not getting touched:

Software development is frustrating, fragile, and time-consuming.

I think what we need is “Fuzzy Development”, or “Fuzzy Programming”.

This means, a programming environment where you can write stuff and deploy it, without caring too much about the exact details. Just like I can do with this blog. I write a post and deploy (publish) it. And that’s like a program – the post is now out there in the World, doing some sort of work (creating new thoughts in a reader) based on some inputs (perhaps, the mindset of the reader at that moment). It’s out there doing stuff. But it has bugs, it was not deeply planned, and it really needs to be upgraded or re-deployed after some of the bugs are fixed.

But it’s fine, or at least “fine enough” for now.

You might say that it is an entirely different set of problems, with an entirely different set of expectations. That I am comparing the proverbial Apple with the proverbial Orange. But I don’t care. Systems that are fragile and break when programs don’t work well (notice, I didn’t say “perfectly” – I am downgrading the standard to a mediocre “well”) – well, those systems should be taken out back and shot.

Systems that don’t work well, all the time, should no longer exist. They don’t help anyone – or at least not quite as much as they collectively hinder. I’m not saying systems should be bug-free, but the bugs need to not matter very much, so we can all get on with the stuff that does matter much.

So, that’s a very opinionated opinion. But until I start to see something to indicate we should continue to support systems which limp from failure to failure, I’m afraid I’m going to be the Man In Black about technology.