Tuesday, November 23, 2004

Time, money, people...

For those in development, there is the pervading sense that you have to perform really well to get ahead and to do that requires very little sleep and lots of time in the office. Traditionally, the game industry has been this way, but more and more software development firms are doing this...to their detriment. It is a well-known fact that very few developers last more than 5 years in the game development industry. The single most common cause for a developer to leave a game development firm is that they are spent, worn out, burned out (whichever term you are familiar with).

The problem is NOT tight schedules. The problem is that developers everywhere seem to think they have no control over the schedule. However, some developers have it figured out: Break the schedule into three categories and allow the person who wants the job done to define two of them.

The categories are time, money, and people. Every project is measurable in the amount of time it will take, how much money will be spent (not head count), and how many people will be involved. The smart approach is to let the manager define two categories and you define the third. If a manager says they want a 6 month project done in one week and only spend $200, you get to say you want a team of 1,000,000 employees to do the project. Those are not unreasonable figures. The manager is asking for the impossible and you are making it possible by getting the resources needed to accomplish the task in the required amount of time on the specified budget. A six month project done in three months and spending $10,000 might require a headcount of 20 people to get it done on time. A six month project done in six months and $7,500 might require a headcount of 8 people. Any manager worth his/her salt can see the latter two are much more realistic. Obviously, I am just chucking numbers out there, but the reason developers don't sleep at the end of projects or go home late is because one of the three categories is not balanced properly.

Of course, some developers literally have no choice in the matter because their managers think they know everything and are control freaks. They have high turnover rates and the people higher up see something going on, but would never dream that the manager is the real problem. Very few developers make good managers, but the few that do are really good. They know how development works and act as liason to the "higher-ups" to get extra time or money or people for the team to create that balanced schedule.

Monday, November 22, 2004

Stay on task

A good way to stay on task is to set a task list. For instance, if you are working on two simultaneous projects (generally a bad idea unless one is a brand new project), splitting your day into two parts is the best way to go. The first half of the day (before lunch) is spent on the priority project and the second half of the day is spent on the lower priority project. There is a two-fold reason for this:

1) People are better able to think in the morning regardless if they think they don't. Well, more real work tends to get done in the morning. After lunch, the food settles and drowsiness settles in for the rest of the day. I know people who take a late lunch for this very reason.

2) You want to look professional by doing higher priority items first. It makes you seem like you have it together. Most people really have no clue what they are doing. I tend to do the odds-and-ends tasks that build up to the main high-priority item. When people review my work they wonder where I am going with it. Of course, when it comes together within hours and it gets done, it has a fairly startling effect. At least people are impressed for the moment. Taking this approach makes you look like you only have moments of sheer brilliance and the rest of the time you are putzing around. If you aren't running the business, the approach doesn't make you good "promotional material" and the approach only works if you can squirrel away exactly how the code will look on screen in your head. Most people can't determine how code will look until it actually gets written. I'm one of the oddballs in the world that can get away with writing thousands of lines of code and not compile it once and have it work right the first time.

Anyway, I'm not exactly on task right now, so back to the grindstone...

Tuesday, November 16, 2004

Dishonest business...

You know the "Yellow Pages"? I am sorely tempted to report them to the Better Business Bureau (the BBB) for having dishonest business practices. I just got a call from their obviously Indian outsourced division and got some of the slickest advertising thrown at me. If I had not been paying attention to what I was doing and it had been at 8 a.m. instead of 10 a.m., I would have likely stepped into some very difficult to opt-out of program. As it was, I was deeply in thought about how to optimize cubic bezier curves when the phone rang.

Basically, the conversation went like this:

Me (groggily - I don't do mornings): Hello?
Woman: Hello, I am......and I am verifying your current Yellow Pages listing.
Me: Okay.
Woman: You are..., your business is..., your business location is...
Me: Yes, yes, yes.
Woman: Your free listing in the Yellow Pages has been updated with the latest information and you are getting a free 14 day advertisement on our website. Please wait while I transfer you to my operations manager who will "double-check my work" (not quite what she said, but close).
(Warning bells go off. Why do I need to be transferred to an "operations manager"? What is this free junk they are selling to me?)
Me (unsure sounding): Okay.
Man: Hello Thomas, I am......and I am checking the details of this call for quality assurance.
(Answers my "operations manager" question and I'm impressed he knows my first name. I'm thinking, well, isn't that nice - some companies really do have QA for their sales department - and we know Indian outsourced calls are desperately short of them, so I'll be a kind soul and help out. Warning bell: How does he know my first name in the first second of the conversation when there was only a 2 second delay for the "transfer"?).
Me: Okay.
Man: You are...
Me: Mm, hmm
Man: Was that a yes?
Me: Yes.
(This guy's pretty good at his QA job - I'll stick to "yes" and "no" to make his life easier).
Man: Your business is..., your business location is...
Me: Yes, yes.
Man: You are the authorized bill payer at this phone number?
Me: Huh?
Man (either ignoring me or thought I said "uh huh"): What is your birth month and year?
Me: (Shells out that information like an idiot).
(Impending bells of doom go off everywhere in my head. The thought crosses my mind: Why would they need my birth month and year for a simple listing in the Yellow Pages?)
Man: In a few days you will receive a packet containing information about your 14 day free trial. If you decide to continue after the 14 days, you will be charged $39.95. If you don't, give us a call and your service will be cancelled...

At this point, the light dawns as to what they are doing. They are offering the usual free listing service and suckering people into an opt-out service that they implicitly opt into. I promptly chewed the service rep. out and ordered them to remove me from that 14 day "free" trial immediately. If I see anything come in the mail from them, I will report the Yellow Pages to the BBB for participating in dishonest business practices.

What was really slick about the conversation is that the Man addressed me by first name. As the conversation lingered on (and in 20/20 hindsight), I got the picture of how the operation is pieced together: The man and woman are in the same cube or office space. Their call "transfers" are simply handing the phone off to the other person. That's a pretty slick racket. Most customers will be caught off-guard because most call transfers usually involve repeating your personal information again.

Developers running your own businesses - take heed. You have to be very observant as to how other businesses operate. Outsourced businesses are generally pretty desperate to gain customers, so they will use below-the-belt approaches like this one. Do not ever do this to people. It is a great way to lose existing business and will only get you people who are a couple filaments short of a lightbulb. If you are a small business, you can't afford to lose business.

Saturday, November 13, 2004

Setting a goal

One of the first things to do in software development is to set a goal. Simply saying, "I want to learn C/C++/VB/whatever" is not good enough. You will learn the syntax and the language, sure, but you will feel like you have learned nothing.

Instead, what you want to say is, "I want to advance my skills to build an application that I can use from my computer to blog with without having to go to Blogger to do so." Assuming you have knowledge of how to go about writing such a program, even if you do not fully understand the syntax of the language you use, you will succeed in making the program and learn new things along the way.

Now, however, let us say that you have completed said application and want to sell it. In order to sell the application, you need to simply say more than, "I want to sell this really amazing application." You are likely to enter into what I call "overhype mode" where you overhype the product beyond what it can really do and label it the next best thing since sliced bread. There are very few applications out there that really truly are better than sliced bread. The first step is to make sure you are not overhyping your product. Users pick up on that fact rather quickly and will not download it as a result, which translates to zero sales.

What you need to do with sales is build a plan. Some companies opt for dishonest practices such as locating competitor forums, scooping up e-mail address lists, and spamming people. The honest way is to utilize your signature in posts, visiting consulting firms in your local area, advertise in the newspaper here and there, and keep your product fresh in people's minds. Focused advertisements can do wonders for sales. So, if a target market is education, locate a journal or publication that everyone who is likely to buy it actually reads and advertise there. You can buy 2 to 5 advertisements in highly targetted publications to a wider audience for the same price you would spend on a trade show for a smaller, equivalently targetted audience.

If you have the spare change, feel free to drop $30,000 on a quarter page ad in PC World or PC Magazine (can't remember which one my jaw dropped on). There are better, cheaper ways to get into those print magazines. You will have to buy my book to find out how.

Oh yeah, the book is coming along. Chapter 1 is well underway.

Friday, November 12, 2004

Floating-point

I have traditionally avoided floating point arithmetic because it is a royal pain to work with. Those who have know what I am talking about. What is much more frustrating is if users see floating-point rounding as some sort of fatal error. Take, for instance, 6.934376572E-150. Programmers and people who understand the limitations of floating-point know that a number like that is simply 0. To an accountant or banker or a regular PC user, that number has an E in it, so it must be an error. What could I possibly have done wrong this time?

Making sure your users do not see floating point errors is a huge issue and difficult to solve. One user will want two digits of precision all the time, others won't care if zeroes are chopped off, and still others want to have the option to see the floating-point errors. Given that most users (80/20 rule of thumb) will want zeroes chopped off, a simple bit of code in C/C++ to convert a floating-point number to a truncated floating-point number is easy. Since very few people will need more than 5 to 7 digits of precision, a format string might look like %.5f or for doubles, %.5lf. Then, your zero will be '0.00000'. However, it is necessary to make it look "pretty" by chopping off trailing zeroes in the string after a decimal point. Then, if nothing comes after the decimal point, chop that off too. This gets a nice even '0' to display to the user.

That is a start anyway. Floating-point is pretty evil stuff when you start getting into the nitty-gritty. Many beginning programmers fall into the same pit over and over and over in this regard - especially when trying to equate two values. You have to define a range in which to compare, but that means the entire numerical space to work with is reduced and accuracy is diminished greatly. Of course, if accuracy is an issue, there are a few good arbitrary precision math libraries out there to run calculations through. A few scripting languages have them built in as well.

Thursday, November 11, 2004

Optimizations

On one of the mass mailing lists that I moderate (people subscribe to them - not SPAM), I constantly see people asking about whether something like memset() is faster than assigning variables the values directly. These are trivial optimizations and usually someone says so.

Given that today's computers are averaging around 2GHz in the user realm, does is not seem odd that such discussions are still going on? What is typically happening is that the person read somewhere that optimizations for performance are really important. The person ends up trying to optimize code that simply doesn't need optimization or they are trying to optimize the code because they used the wrong algorithm for the given situation. The only traditional bottleneck where optimizing code to extremes was where the algorithm was the correct one to use and just happened to be performance intensive. This happened particularly when developing games. Of course, if you were developing games, you were in a whole other league of programming anyway doing all sorts of cutting-edge stuff. Even then, most optimizations were restricted to graphics display routines done in assembler.

For the rest of the population of programmers, we have what is called code maintenance. Code maintenance accounts for 60% of any given project's cost. You should be far more concerned with writing maintainable code than code that pulls cute tricks to do some optimization. If someone is going to come through the code later and wonder what in the world you did, don't write it. That person will re-write what you did and do a better job of it. If you care about job security, write maintainable code. That sounds ironic to some people because it seems that it would make you less valuable, but instead it makes you a better part of the team. If everyone on the team does the same thing, you can edit each other's code if you have to, but you won't have to because smart bosses know about the joys of code ownership. Your boss, if he/she is smart will let you "own" your code by letting you be the one to make, edit, and maintain it. So, you want to also make your own code maintainable so that you enjoy maintaining it.

Now, that does not mean you will never write super-crazily-optimized code. It just means that when the time comes to optimize code, you will be able to write optimized code in a maintainable fashion.

Wednesday, November 10, 2004

Changing the way...

...I do things. I am not going to offer the $250 service any more. Instead, I plan on writing a really good book that every software developer should own. And it will be a lot cheaper.

Enough said.

Tuesday, November 09, 2004

Hmm...

The latest StrongBad e-mail (#117) references #173.

Feel free to click here:

http://www.homestarrunner.com/sbemail173.html

To get them to come up with one of those nifty pages like this:

http://www.homestarrunner.com/sbemail100.html

Hmm...fresh blueberry pancakes sound good right now. No syrup or butter. Just the pancake and a good tall glass of milk.

Look mom! I can be a terrorist!

Probably the most disturbing tiny bit of SPAM to hit my in-box that I have seen consists of some spammer advertising weapons in e-mail. Hmm...let's see...I've got a few spare bucks or so and I have nothing better to do with my life than go become a professional terrorist.

(Hopefully you caught the oxymoron in that last sentence).

Really. These people have to be dead to themselves to realize that blowing themselves and a bunch of other people up is a complete waste of everyone's time and not an artform. We could all be writing programs that benefit society or something like that instead. I mean, I have a task list of at least 500 things that would keep every terrorist occupied for the next couple centuries. They would not have time to do anything else but write computer code. Besides, coding is fun. Programmers know this to be true. There are very few thrills on earth that get the adrenaline going than a late-night debugging session (roller coasters come close). Nothing else that causes one to find a brick wall when they figure out that the bug was caused by mis-spelling one letter...after 8 hours of debugging.

Yessiree! I could keep them busy and highly entertained for the next century or two.

I just got done with the longest debugging session in eons. CubicleSoft has this really nifty set of routines that generally manage crash bugs, memory leaks, etc. but this particular bug was causing me to run around everywhere chasing wild geese off in perfectly fine code. It took approximately 12 hours to find and squash the bug. Most of that time was spent upgrading those core routines so that I will never have a debugging session like that again. CubicleSoft rarely has crash bugs in production code and these routines are the reason why. Search for GlowCode on Google sometime. It is an "okay" piece of software, but nowhere near the pure genius of these routines. These routines blow GlowCode clean out of the water.

Now that I have got your curiousity whet, I think I will leave you hanging. GlowCode may be a profiling tool, but the tools CubicleSoft uses are fairly proprietary to the company. So, what the company uses has a fair chance of being incompatible with whatever your code base is. Just note that with the tools CubicleSoft uses, the time spent on debugging is basically nil...because the tools find the bugs automatically (at least the serious ones - they can't catch functionality bugs).

So, if terrorists want something to do and want to be professionals at something, they should either try "Operation: Blow up the Ocean":

http://www.homestarrunner.com/cheatcommando.html

Or coding.

Rock, rock on!

Friday, November 05, 2004

Brain Jam...

The person Google just hired is not a real programmer and they missed the one who was. Oops.

http://www.google.com/codejam/

Why do I say this? Programmers who code really fast generally lose track of what they are doing. When CubicleSoft writes code, the code has already been written...in our heads with ideas on paper that fire off the memories of the code. Real programmers can visualize code coming together as someone rattles off requirements. Not just big generalized blocks of code but the entire thing line-by-line. They wake up at crazy hours of the morning with the realization that they forgot one important line of code and can't sleep until they fix it.

When a company gets their hands on a real programmer, everyone knows it. Real programmers can determine exactly how long something will take to develop to the hour and then produce it on time generally with only a couple bugs that are worked out in the QA process. Product managers love these type of people. Or they should anyway. If you are a company who has recently obtained a real programmer, make sure they get pampered really well. And send them home at 5 p.m. with everyone else.

That said, the person who won first shouldn't even be considered for hiring. I certainly would not hire them. I would look, instead, for those who spent a majority of the time mulling over just one problem and still came up with a good solution. Those people are the thinking type and need time to think, but the resulting code is far better than those cranking it out like crazy. Mastering competitions like ACM is a great way to become a hack...someone who just hacks out code without thinking about consequences like application security, potential crash bugs, usability issues, maintainability, etc. Speed competitions are a great way to build the worst skill set anyone can have and will result in more bugs in the long run.

Wednesday, November 03, 2004

Hmm...I wonder...

I just found out that the republicans now have a majority in both the house and senate and governor races. This is particularly unusual and actually is a HUGE plus for software developers. In fact, this is the best possible scenario that could have ever been created.

A decidedly complete republican majority has, more or less, meant better economics in the short term. Now, while the President has no effect on the economy, the government can play a small role in improving it for a short time (a couple years). Here is what I mean by this:

Microsoft Windows has a window of opportunity for Longhorn that they can't afford to pass up. Even if it means releasing it early in late 2005.

I have consistently predicted that Linux could take on Longhorn and take out Microsoft if the developers bothered to work on a little thing called usability testing. However, my predictions depend on an early 2006 official release and mid-2005 beta for Windows developers. Assuming pretty decent stability, an early 2006 release would squash Linux into a corner for an additional 4 to 6 years.

Of course, this means that not only Microsoft has this nifty window of opportunity, but also any developer out there who has an idea for a product. You just have to get it out there within the next 6-8 months to take advantage of this unique opportunity that comes around maybe once every 30 years.

Tuesday, November 02, 2004

Finally works...

Took forever, but just for the curious, my new DLL stuff finally works. Pretty cool actually, but since it is proprietary, I can't share exactly how it works. Just know this - it involves lots of macros and plenty of pre-compiler abuse and works great under both Borland C++ Builder and MSVC++ .NET 2003. I'm so proud I want to hug myself.

But I won't because that would look weird.

Monday, November 01, 2004

"DLL Hell"

Today I experienced what every Windows programmer experiences when interacting with DLLs - only on a much grander scale. What I am talking about is "DLL Hell." The results of these efforts caused me to have 23 programs open along with 50 unique files.

Over the past week I have been working on huge modifications to some core library code. This code is fairly proprietary, but basically what I was striving for is perhaps the most unique approach to interacting with DLLs. As many people know, I already live and thrive in macro hell. For instance, my most evil macro to date is basically unreadable and 335 characters long...and on one line. Anyway, as I said, I have come up with a really creative and unique way to load in a DLL. The way this works is to simulate delay-loading with the option of not running into the issue of crashing if it fails to load for whatever reason. This feature is actually useful where plug-ins are concerned. The other issue is that I needed application portability between platforms for various reasons only known to my twisted mind.

Anywho, I digress. Basically, I chugging along happily and working out the kinks until I ran into the most bizarre issue of all time. The __stdcall calling convention is how each function is called that I wanted to __declspec(dllexport). However, there was one function that was not exporting properly and was decorated with a leading underscore.

I searched Google high and low and high and low again and kept coming up empty-handed. It did not help me out much that only 20 results were coming back. Basically, I was scraping the bottom of the barrel only turning up with coffee sludge. I guess that happens when you start managing over a half-million lines of code every day.

After about 6 hours, I finally hit upon some keywords that got me the hint that I needed. The calling convention was being changed by the compiler. Why? The one function I was working with has variable arguments (...) and __stdcall doesn't support that, but __cdecl. You would think those brilliant compiler developers would think to notify me that they were changing an explicitly declared calling convention to tell me they weren't compatible. Good job guys. Way to go Borland/Inprise/whatever your name is today.

Well, I was not actually 100% certain about the whole conversion thing at first. Seemed kind of hokey. After about 8 hours, I finally hit upon the right order and keyword selection that gave me a pointer to a website I knew had articles on this sort of topic. (Yay me for losing my mind). It turns out that my guess as to what was going on seemed to be correct. The next step is what really boggles the mind. I had to create a ".def" file just for this one function and map the export with another name. The result was that both the decorated and undecorated functions show up in the DLL. (I only need one of them Borland people - the one I say to export in the first place).

My goal of a DLL with completely undecorated names that works beautifully across compilers works like a charm. The last step was to verify that everything still worked with a sample interface.

It didn't. Go figure.