Perhaps some of you have been listening to the saga of Terry Childs, or if not Slashdot can get you up to speed, but long story short this is a true calamity of the worst of what can happen in IT when worst practices are followed, namely:

• The lack of proper oversight by management on this administrator, who was noticing that he had so much power? Was so disgruntled, etc?
• The fact that any one person can do so much in such a large network, surface area security anyone? No one set of username's/passwords should ever be allowed to reach that far...

Ok Terry Childs argument of "nobody else was as competent as me in this" is an interesting defense, granted the network held up very strongly for as long as it has. However, when I've said "code for the next guy" I've never meant it stronger than what this guy here has done. What if he got hit by a bus? Management needed to step in a lot earlier on this guy. Hopefully we've all learned.

Today's interesting article on Slashdot Coding Standards and as usual I shall weigh in with the "why care so much?"

Well ok, some neatness in code is preferred, any tab standard is better than none. However in my readings of code, I've never cared, and sometimes ever even noticed whether or not a programmer is using a certain variable naming convention, tab standard, etc. As long as the code is neat and grouped, with variable names that tell the story, who really should care? I've seen many an organization drive themselves nuts trying to follow the lead programmers coding standard, wasting countless dollars of good coding time in hours, just to clean up and properly tab everything. Drives me insane. As long as the code is readable, just leave it at that already and don't worry more. Jeez...

Ok so I'm a Netflix subscriber and a generally happy one at that. I have 2 Queue's and am debating opening up a third queue for my kid for all her kids stuff.

Of course my ambitions there were almost curtailed by the fact that Netflix was getting ready to ditch multiple queue's per account. Netflix sited the fact that it was difficult to maintain these queue's and admittedly it was a "kludge".

Now being in the IT world, I'm no stranger to kludged code. Where a major design change to an existing site is beaten over the head with a bat until it fits in the same block as the rest of your code. Approaches to kludge have typically ranged from:

• Refactoring the code, re-architecthing the site and build that kludge in properly later.
• (Netflix's first approach) Removing the kludge, making the rest of the code easier to deal with down the line.
• Just living with it for now...

Refactoring carries the joy of fitting in the solution the right way, getting the design to a more perfect state and hopefully approaching a utopia with your code. Oh did I mention this is typically the costliest option?

Removing it carries the joy of getting rid of the kludge while work continues around it, but you lose feature sets. In this case it proved poison for Netflix when the public responded.

Just living with it ensures that while the feature remains that was kludged, the site will continue to get more burdensome to deal with as that kludge is worked around.

Is there an ideal solution to this? In consulting, I've typically advocated a "If it ain't broke don't fix it" approach. However I typically take a look at the cost of refactoring the kludge into a proper design, combined with any other major feature changes that are being thought of at the time, and do a cost-benefit analysis of a refactoring or leaving in place for now. At some point, it becomes more cost effective to refactor.

But to remove a feature in the name of progress? That's like cutting off your arm in hopes of making your running speed faster. Sure it lightens the weight you have to run with but...

Long story short, I hope Netflix learned from this. My personal view when that news came out was that it would have been pointless to continue to have an account with Netflix as (ironically) kludgy it would have been to maintain one queue for three people.

Well yesterday I had my 2nd client meeting with Inobits, went a whole lot better than the first anyways :-) I think it's more or less my self-confidence now here at Inobits and "getting into the groove". The perception that one can do anything is far greater than the reality of the situation in that there's always a lot to learn.

Also once again we learn to "code for the next guy" as I always emphasize, as I had to spend 2 hours hunting and pecking through code to change simple URL's that were hard coded, ugggh if I were manager I would have insisted on soft coded URL's with external variables to change not reequiring a re-compile to do so. *sigh* then again I do have to remember that no code is perfect.

To me, happy birthday to me, happy birthday to meeeeee, happy birthday to me :-)

Not bad, 30 years on this planet and counting...

I use Scottrade for most of my investing cash. While they're not a bad brokerage, cheap and hassle free, every so often they amuse me with some antics. This is one of them.

Earlier I get an email from Scottrade with advertising a new Vorce/Velocity widget designed to make me a better trader in their ScottradeElite product. Plus they'll give me $100,000 in virtual cash to try it out. My thinking here is "cool, at least it's a way to test what I could do with 100 grand in the market with no risk."

So I log in, grab my 100k in virtual cash and begin to have fun. First order I place, by 2000 shares of American Express stock at approximately $40, draining 80k of my cash. Second order I place after gaining 20 cents on that trade is to sell and take my gain. Scottrade comes back, order refused, I don't own 2,000 shares of stock. Huh?

After repeated attempts to sell my virtual stock I give up. I log back in later to find my American Express shares gone and 80k in virtual cash gone as well. HUH?

Ok I understand it's a sim, but I can't help but think, if a sim is this bad with something as simple as a sell order, what's the live system like? Is that a fair question?

Remember one thing your systems you build always need to to is inspire and reassure, if one system is found defective, it may ask people about the whole organization. You can't be bug free, but to assign priority to one system over another in quality assurance is often a mistake. Those resources in QA should be divided equally at all times.

Spent most of the morning helping my boss out troubleshooting Kerberos authentications between Windows Services, got nowhere :-/ anybody good with Kerberos out there? Unfortunately I'm more of a MCSD than MCSE.

On the other side though, I'm getting really good with K2 now. K2 is just a phenomenal tool for rapidly and easily building workflows with zero to minimal code required. Need a workflow? Need a process in your organization updated for the 21st century? Give us a ring.