Adam Kinder of E29 Incorporated put up a blog entry on the internet’s phenomenon of producing fake companies not too long ago (I just recently noticed it, thanks to Twitter). Omega Vortex got an Honorable Mention on his list of companies that get it right:

A runner up that I’m going to give a nod to is Omega Vortex. Jeremy Privett knows what he’s doing when it comes to setting up a good, fluid development shop. The only reason I can’t 100% vouch for their work is that they haven’t released anything yet, and I’ve not worked with their custom shop. Good group to keep an eye on though.

Admittedly, Omega Vortex fell into the “fake” category not too many years ago before I was swept off to Colorado to go work at Completely Unique and Peak8. I filed papers on GU² Services, Inc. before it was acquired and wanted to file papers on Omega Vortex but never really got around to it until after the Peak8 era.

We do have papers, though! They’re currently in the wrong state, but Alabama’s business laws are incredibly annoying compared to Colorado’s so I may try to put off legally moving the company out of Colorado until I move to NY sometime within the next year. Unless there’s some legal reason to do otherwise which I’m not aware of. We don’t currently have any type of office space, as all of our employees work remotely, so our physical address is pretty much non-existent.

We’re working on fixing that unreleased products issue in the coming months and I’ve been working on ramping up our software division for more progress, now that we’re getting to the point where we can look at it again. Since we have some new people on our team, consulting work should no longer completely bog us down so that no work gets done in our software. We’ll have to see how it goes from here.

Even vague ones … and I mean really vague.

Quite a while ago, Omega Vortex adopted a policy that we would refrain from announcing specific release dates. We won’t even narrow it down to a month for you. There’s quite a few reasons that we do this.

We’re a startup that’s bootstrapping from consulting work. At any given time, said consulting work currently takes priority over all other things, because we have to make money in order to pay bills and keep developers paid. That’s all fine and dandy, but while we’re having to focus so much on consulting, software isn’t being written. This is eating us like the plague. We’re presently amazingly profitable, but not in the way that we want to be. No matter how good our scheduling is, it doesn’t make a difference because we’re constantly having to drop everything to invest time in a new consulting project.

On the plus side, we’re about to simultaneously release a new product that hasn’t been announced yet along with updates to two other products that you may already be familiar with. No matter how close we get to that day, we’re not going to tell you when that day will be, in advance. All of our releases are marked by quarters. Any one year is divided up into three month quarters. Q1 is January - March, Q2 is April - June, Q3 is July - September, and Q4 is October - December. That means that when we mark a release as Q3 of 2008, we could potentially release that product at any point within those three months. If we’re expecting to release in September, we’ll actually really say Q4 so that we have three extra months worth of time buffer to use in the even that something goes wrong. If we happen to meet our goal of September, we just managed to release an entire month early.

Three months of buffer is a pretty decent amount of time. Sadly, because of time constraints with our consulting work, we’re still having trouble meeting those release dates. OmegaVerge has suffered considerably because of this and it has allowed competitors to get a jump on us. (Speaking of OmegaVerge, I’d like to give a shoutout to Ben Babcock who actually managed to help me with a SimpleXML issue by letting me help him with a SimpleXML issue. We now have type-safety/inference of IP.Converge methods in OmegaVerge since we solved that issue, instead of having to pass around SimpleXMLElement objects. Thanks, Ben.)

If you’re a software development shop and, like us, you can’t dedicate 100% of your time to software development, don’t announce release dates. Even vague ones. Surprise people. People get incredibly antsy / angry when you don’t meet release dates.

Oh, and if you have a historic trend of lack of ability to execute, don’t try to say things like “this summer” or “next month” … I’m guilty of this too, but this is a practice that really needs to stop. I’ve seen so many projects say “next month” and it take so much longer than that. Two in particular have me facepalming, right now …

Most of your [code] comments are unnecessary.

Don’t ever tell a developer that. Especially, one that is learning. Code commenting is one of biggest components of code maintainability and there are simply not enough developers that do it enough. The thought that someone really would instill the thought that comments are unnecessary really peeves me. I’ve had so many problems over the years that could’ve been solved if the programmer before me had just commented his stuff properly.

Don’t be this idiot.

This is an interesting position for me. Before recently, Omega Vortex has just been a small group of close individuals who all knew each other and have worked together before. Now that we’re expanding and I’m having to actually interview and hire people, I’ve been able to experience what it’s like to be on the opposite side of the process. I’m used to being the interviewee or the person applying and sending in a resume, not the guy interviewing or receiving the resume. I don’t claim to be an expert on interviewing people or sifting resumes, but here’s my list of things that’ll immediately get your resume tossed out of the pile. (more…)

I was reading today and came across something that seemed contradictory to what I’ve learned over the years. At the same time, it just made a lot of sense.

Programmers don’t throw away code enough. When faced with a hunk of code someone else wrote, which doesn’t appear to be quite right, or is misbehaving, the proper action is to figure out what it’s supposed to do, and its interface, and then scrap it and start from scratch. (I’m not talking about rewriting whole programs here, just sections.) Instead, people try to handle the corner cases, or hunt down where the leak is. Just stop, think for a little while, get the structure well posed, then write that.

We were bit by this problem at OV recently. Instead of trashing pieces that were there in order to make them work, and writing them based on the original specification, we attempted to bend them into place in order to “save time”. Needless to say, that didn’t work out so well. Not only did we not save time, we used up too much.

Next time, I think it would be more appropriate to go with my gut feeling. Instead of trying to bend the immalleable, we should strive to replace the pieces. Sometimes code is just so bad that it’s not smart, safe, or sane to leave it in place.

I’m certainly losing my sanity, about now.