Monday, October 16, 2006

Why I Won't Build Your "MySpace Killer"

Often the topic of starting a "great" web business comes up, and in my age and wisdom (being both old to be a freelance web programmer, and one of a minority of women in the field) -- there's two ways to go: thinking "in" the box = come up with new brilliant technology, patent it and hire people to program it better and faster than anyone else can so you can quickly market it. If it climbs to the top before it is cloned you become the next target for people trying to out-do your website. This track is getting VERY old, VERY fast. Mainly you and your absolute best friend need to be programmers to do this (think Microsoft, Google...) because you can't trust anyone with your terrific idea. Also it has to be so ground-breaking that only the best (read: smartest, wise, long-range thinking) of venture capitalists will see the end of the rainbow where the pot of gold sits. If it is easy to get the funding for your idea, someone probably is making it already.

Thinking "out" of the box = coming up with a way to use normal everyday technology to do something that fills -- rather than creates -- a real need or niche. It's cheaper, faster, and if it really IS filling a need, it's going to spread by word-of-mouth, and it won't be "just a fad". This technique aims lower and comes in under the radar -- no billion dollar baby here -- but it's safer, less stressful, and you don't have to be a programmer, generally speaking. The programmer is unlikely to run off with your baby if it doesn't look like a "google killer".

The problem is that great ideas are easy -- the means to really make them work is the harder part (invention = 1% inspiration, 99% perspiration). I'm frustrated with people who want to "share" the rewards of their great web program idea (equity sharing) of up to 50%, but won't be doing any of the actual work to make it hang together and be practical. If someone comes to me with a truly great idea (and I have NDA's if they don't), I can find them a great programming team, but the team will probably want cash on delivery, not equity. More "google killers" die every day than make it. They're not original ideas, and if a site dies before it makes money, there's no equity and it's a huge waste of the programmer's time.

Imagine that someone turned to you and said, "I have a great idea for a newspaper! I'll give you the ideas, you develop the newspaper and run it, staff it, write for it, etc. I'll give you 50%." That approach frustrates me. People don't get it. I can translate it to dozens of other fields -- "I have a great plan for a house, you just have to build it. Then you can live on the top floor, and I'll live downstairs. Ok?"

Somewhere in there people are cheapening the act of programming. After all, it's just bits and bytes, right???

The Internet mimics life in a "survival of the fittest" way. I don't pretend to know what's "cool" or "hot" anymore -- I work with "useful" :) I won't get rich but that wasn't in my personal game plan. I have my own great or good ideas, some might make me money, some won't but will look really good on my resume.

Then there's the flip side of this: If you're not the head of the programming team and you've paid someone to build the google killer -- what if it works? Now you have to program new features, fix bugs, etc. You either need to re-hire the same team, or get a programming staff. You go on Craigslist and choose the person who claims somehow to be able to fulfill your great Internet dream, but if you have this beautiful web baby together, are you really ready for that long-term commitment with a total dweeb with no business sense?

I can't wait to be so busy with people I've looked in the eye and shaken the hands of that I can't afford to even GLANCE at another Craigslist ad. I love my clients dearly, but you don't know how rare it was that the people I dealt with BECAME clients at all. I certainly wouldn't want to become business partners with some guy with the "next killer app" idea and had to actually look on Craigslist for a programmer. So wait -- your only experience is the front end of websites as a user, and you think you can somehow manage a killer web application programming team? That's an incredibly poor business move and you'll get laughed out of the bank. And you want the programmer to work for nothing but equity? That's spec work.

That brings me to another thing: Have you ever had one of those managers who knows absolutely nothing about what you do? It happens in IT all the time, but much less so in other professions. BUT if you've ever heard a nurse bitch that someone "stepped in" as the head of the nursing staff from a business-only background, you might get the idea. In most large corps -- and this is a place where Microsoft does NOT get bad rankings -- the heads of the corporation have NO IDEA how to produce their main products...much less have a clue what their IT department does sitting at their computers all day.

It's never a good idea to manage something you don't understand. Ever.

On that note, are you interested in a basic web programming class? :)

Monday, October 9, 2006

Classes in PHP (object oriented programming)

From a post to a user/developer list I'm on. Since I've never seen a great explanation of ANY object oriented programming, I figured I'd give a brief go at it.

Classes are a code structure from the object-oriented-programming side of PHP. A class is beyond a function. The class definition creates an ideal "object" (rather than an actual object, that comes later), and assigns it properties (variables) and methods (functions). Think of "object" in this case as a function on steroids.

Here's the basic class syntax for how I would deal with shoelaces (I'm using comments for a real life physical action that I don't feel like emulating in real code) -- but note that an "object" isn't usually a physical object -- it could be an email, data, graphics, form buttons, or something even more abstract.

class Shoelaces {
var $tied = false;
// maybe we should double-knot them?
var $double = false;

function tie_shoelaces () {
if ($this->tied) { return; }
// instruction to grab shoelaces here
if($this->double) {

function pull_tight() {
// yank whatever is in your hands
// in opposite directions
function overhand_knot() {
// loop item in right hand around item
// in left hand one complete rotation
// hold item in right hand again
function make_loop($side) {
// creates a loop from the left
// or right side of the lace

Here's how you use the class within the program flow (this code would be in the master body of your program -- or in another function
or class):

// create an object instance -- this is a specific local
// copy of the class for this specific instance/call.
$bootlaces = new Shoelaces;
// set the properties
$bootlaces->tied = false;
$bootlaces->double = true;
// tie the shoelaces (call the method i.e. execute the function)

Now you should have a doubleknotted shoelace on your boots. This code can easily be reused for $sneakers also. Or even hacked for tying laces on other objects.

Now, the parts people have the hardest time wrapping their brain around:

  • Calling it "object" "method" "instance" etc. -- It's a prepackaged set of code (class), functions (methods) and one particular time you call the code (instance -- such as $bootlaces or $sneakers). Call them what you want to but remember the standard synonyms so you aren't confused when you read about them.

  • The term "$this" inside the class definition -- $this is "$this object" or a place holder for the namespace INSIDE the object. I guess that once you call an instance, PHP translates $this to $bootlaces or $sneakers -- it's a generic "variable" that points back to the parent object and allows you to keep your scope within the object clear.

  • Translating this idea to actual code since I wimped out for understanding by using a physical not computing activity, so see a practical real-world paradigm for a class below.

There is no place to run code in the object without defining a function/method. It's confusing to call it an object method when obviously you're even using the syntax "function" :P

I didn't use it above, but there's also something called a "constructor method" and in PHP5 there's a destructor method. All this means is "automatically run this function when I create the class instance" or a destructor is something auto-run when you destroy the object instance (not sure how, I don't do PHP5 yet -- maybe unset()?)

Syntax for a constructor in PHP4 is to name the constructor function the same name as the class name -- inside the class definition.

	function Shoelaces() {}

I know this is probably confusing, so feel free to ask questions. Note however that this completely protects the code and variables of the class from colliding with the names of other items in the program. The only name of concern is the class itself. Other people can use your class pretty easily -- it makes a very portable chunk of code. There's more to it, but this is enough to actually get you using this idea if you decide it would make code more efficient.

A real example would be creating an "Email" class where you can set up emails to be sent.

class Email {
var $to = "";
var $from = "";
var $subject = "";
var $body = "";

function Set_Params ($to, $subject, $body, $from=$this->from) {
//assign to class values
$this->to = $to;
//etc. ...

// a couple internal functions not used outside the
function validate_email () {
//validation in here
function make_headers () {
//create headers including From - output to class variable
$this->headers = $headers;

function SendEmail() {
// validate TO & FROM email addresses
// create headers
// send the email (should add custom From header too)
mail($this->to, $this->subject, $this->body, $this->headers);

$email4Larry = new Email;
// set the properties
"", "Hi, Larry", $body);

More some other time if anyone's interested.