Seiter's Blog

Today was supposed to be epic. I had my snacks, my drinks, my go fast shorts and my yoda bobblehead all set to grind out some ownage in Aion. I fire up my three thousand dollar computer built specifically for these types of tasks and with an amount of anticipation only rivaled in moments I won't describe here, I logged into the brilliant game, only to presented with this.



You've got to be shitting me. Thank you for your patience? Fail. I want my 60 dollars back. I'm so pissed off right now. It's one thing to make a shitty game and have it fail on launch. (Anyone ever heard of Vanguard?) It's another thing entirely to make a half-way decent game only to absolutely BOMB it's deployment. What's the population cap on those servers anyway? You have those bad boys running on Pentium 3s or something? This is great promotion for your game NC soft. Check out the great publicity you're getting, like

THIS ONE

and THIS ONE.

I hope you guys realize you are losing money by the thousands every minute these queues exist. Kick the afk shoppers. Increase your pop caps. Fix this garbage immediately. This better be fixed by tomorrow.

Pictures speak louder than words.

Brother Hamlen, Record Five, Day Twelve

It's been almost two weeks now since I left the monastery. It was sunny out then, a few white clouds floated lazily across the afternoon sky and a tired eastern wind picked up petals from autumn blooming flowers.

Brother Mikus came to me panting and terribly excited.

“Brother Hamlen, you would not believe the strangeness I have witnessed in our friend Brother Tarnus.”

“Oh?” I replied as I set the red ribbon inset in Mark, shifted my study with crossed legs and smiled curiously at my visitor.

“I spoke to him just briefly. His faith has passed! He believes that the Holy Father has left him. He despairs and speaks of leaving these walls.”

Curiosity turned to disbelief. “Not possible. Tarnus was here nine season before I and his faith has been as unshaken as any.”

“You have asked a question and I have produced no lies! Do unto him as I have and you too will witness this as truth. His faith is shaken and cold and even the fires of Father have produced no warmth in his spirit.”

I closed my eyes then and pondered this development for a moment. And as I open my eyes now, I still have no answers. How could I have known then that such a minor event would precede such major, terrible ones? It was sunny out then.

C# delegates rock. If you've never used them, I highly suggest you read up on them. So anyway, I was playing with them today and discovered, much to my chagrin, that the order in which methods chained to the same delegate will be called is non-deterministic. That is, C# doesn't guarantee that your stack of 4 functions bound up to the doSomeStuff() delegate will always execute in the same order or in the order that you added them to the delegate.

Well that's crap. Turns out, the solution is pretty straight-forward. C# provides a function, GetInvocationList() that will give you a Delegate [] to iterate through. But that sort of sucks too, who wants a foreach every time they use multicast delegates? Fear not friend, turns out, you can just write another delegate to do that work for you too. Awesome.

class Program{

    public delegate void Builder( Person p );
    public delegate void DelegateDriver( Delegate d );

    static void Main(string[] args)
    {
        
        // Make our person that's going to get tossed around
        Person test = new Person();

        // Make our multicast delegate who, on his own, can't ensure order of operations
        Builder bob = null;
        bob += delegate( Person p ){ p._firstName = "Kevin"; Console.WriteLine( "Set the first name." ); };
        bob += delegate( Person p ){ p._middleName = "Andrew"; Console.WriteLine( "Set the middle name." ); };
        bob += delegate( Person p ){ p._lastName = "Seiter"; Console.WriteLine( "Set the last name." ); };
        
        // Lets make a delgate that can make other delegates to their work in order
        DelegateDriver dd = null;
        dd += delegate( Delegate d ){
            Delegate [] tasks = d.GetInvocationList();
            foreach( Builder task in tasks ) task( test );
        };

        // Run this bad boy
        dd( bob );

    }

}

class Person{

    public string _firstName = null;
    public string _lastName = null;
    public string _middleName = null;

}

I love C#.

I had a conversation with one of my new hires a few weeks ago about the nature of Software Engineering that made itself relevant again today while I was working on a solution to an algorithmic problem I won't detail here. The conversation was brief but encapsulated my opinion on what, I believe, is the over-engineering of software.

Jeff had come to me with a problem he was working for which he had determined a solution and was seeking my feedback on said solution, which I was happy to give. I proposed an alternate solution that he then took to mean as, "No, do it this way, for it is the correct way to solve this problem." When I realized he was taking my suggestion in this way, I explained to him my opinion on the nature of software engineering, which I was alluding to above and was relevant again today.

Software Engineering, in my opinion, is an incorrect name for the job that 99% of us in the Software Development field do every day. Take for example, the opinion of a mechanical engineer when asked to engineer a design for a bridge. His solution is in fact, THE solution. Build it this way, or the bridge falls down. Build it this way or we have Tacoma Narrows part two. Engineers find THE solution to a particular problem. This is not at all alike what Software professionals do today.

For almost any given problem in software, there are hundreds of different solutions, some of which are much more effective than others. Of those thousands of solutions, there are maybe ten that are elegant, simple and accurate. But there are still ten of them, not one. And it is this property of software in particular with respect to other engineering fields that brings me to the point of this post.

Over the last few years we have seen multiple different technologies attempt to ENFORCE design paradigms on developers with the posit that said design is THE solution to a given problem. It is with this trend that I take particular issue. Architectures like Ruby on Rails, which force the developer to follow a set of rules for the implementation of their applications are, in my opinion, playing to the desires of corporations, in that they encourage repeatability; reproducibility; consistency; security from brain-leak. And for many practical purposes, I understand this desire and acknowledge their purpose.

But on the other hand, they also stifle creativity. These architectures tell a Software professional, "don't reinvent the wheel" but in the same breath prevent him from discovering the rail. And so this is my posit; leverage existing technology when you can and when it suits your purposes. Surely I don't rewrite ArrayList every time I create a new application. (Although I might rewrite qSort()) But at the same time, don't fall into the trap of monotony. When you're a hammer, everything looks like a nail. Challenge yourself to implement solutions in different ways. Challenge yourself to not simply find one of the ten thousand solutions but to find one of the ten elegant ones.

And for crying out loud, stop calling yourself an engineer. Start calling yourself an artist.