Support is generally the greatest cost for software. You always have to look at your product through your customers eyes to make it as simple and intuitive as possible. Years ago, the tax season I worked for Intuit in Tucson (and the best Christmas party I've ever experienced working for any company; I was too late for the years when they used to roll kegs of beer through the support department about the time Microsoft wanted to buy them and the Justice department said no) they talked about turning support into a profit center, but never quite got there (at least that year.) While I was answering the phones to answer questions about Quickbooks it always amused me that the owner or their accountant wanted to know things like 'what' rather than 'how' to set up their chart of accounts for example. I was being paid to tell them how. Their accountant was suppose to be telling them what.
Then I worked for about a decade writing software for a mom and pop outfit. When they moved their company from California to Washington state they lost most of their programmers in the move, but I went (on the promise of a huge raise they reneged on after I made the move.) They used to call my code bulletproof. But even then we had a lot of support issues regarding a desire for new features all the time. I'd sometimes talk to customers when the support people were at capacity. In talking with customers, I'd almost always come up with new features that the salespeople would then use as a lead in getting more sales. You learn a lot from talking with customers and being a customer yourself. Experience counts.
During those years I was very productive because my tools were of a professional level. They faded into the background. I didn't have to concentrate on the tools, just on the job I was doing with them. Which made my productivity very high. Statistics from our source control software indicated I was doing more work than four other programmers we had one year.
I also helped friends literally become millionaires in their software businesses and this poor boy would like to do some of that for himself. So I need tools. Surely they've improved in the last decade right? Here's how one compiler describes itself:
- Huge set of internal commands (1100+)
- No external DLLs, runtime interpreter or anything else required when creating executables
- Procedure support for structured programming with local and global variables
- Access to full OS API for advanced programmers
- Optimal use of the available hardware by using highly optimized (assembly) commands
- Source code is portable: Windows, MacOS X and Linux
- Dedicated editor and development environment
- Powerful integrated debugger and profiler to easily trace and analyze code
For some reason they don't include weird and buggy. Probably just an oversight. A compiler doesn't need 1100+ commands if they choose the right ones. This is not a plus in my mind. I don't know about their structured programming claim. I expect they didn't get scope rules right given what I've discovered about other products. If you have access to memory (and how could you not?) you have access to assembly language, but I choose a language so I won't be coding in assembly. A profiler is nice, but I hardly ever use one because coding you should be able to tell when you've screwed up optimization. Visual Basic had a great debugger, but it's another thing I could live without.
Weird is a form designer that writes code for you but doesn't let you change it in any way. You have to copy the code into your own file to modify it. Buggy is having the thing crash when you scroll too fast down a list. But I don't care about any of that if I can end up with the results I want and it appears I will be able to. So I'm going to buy the damned compiler next month. From two guys in Europe that could be hit by a truck any given time. My first software boss in NYC used to always gleefully ask me, "but what if you get hit by a truck." I kind of miss that pain in the ass, Hank. I wonder if he's still alive?
The result I want is an executable with no dependencies. I'm going to release my first client software for Linux. This is likely to have much greater support issues than windows but for a much smaller customer base. I'm giving it away for free so that should help some. My income will come from an option of buying virtual money in the game. Yes, it's a game and a fairly simple one at that. My goal is several thousand players per server. Hosting on a server is dirt cheap. I can do testing on a shared server for as little as $5 a month. Then move up to a dedicated server for about $150 per month. Even in my worst scenario (80% to 90% choosing to always play for free) I should make more than I currently do. Gotta take a shot, right?
I know it will be fun to play since I've already put something out similar to it as a test that people seem to like. I've already written some code that allows a non artist like myself to have fun building components that are part of the game. I have 36 parts of the game to write and then I will be done. I should be able to finish that in less than a year. I've got nothing but time. It's not my only plan.
Update: One down, 35 to go. Everything else requires SQL which I'm thinking $60 a year to include support doesn't sound like a bad deal to me. Gotta start getting serious about finding a host.
Can you believe there's no provision for modal forms in the compiler I'm buying? I guess I'll just have to make do. I told ya, weird. My job is to use this weird tool and produce a product that isn't weird. If it was easy, everybody would be doing it.
