Keeping track of C++ templates

So I needed to build a complex template. I wanted to build a map which also operated as a cache: as the contents of the map hit a limit on the number of objects in the map, the last referred to objects are automatically erased from the map. (What I’m doing is writing a bit of code to insert itself between a Sqlite database and some accessor code, but the pattern of access would cause a lot of unnecessary ‘select’ statements. Rather than trying to load my database in memory and somehow manage the synchronization from a bunch of places, a database cache seemed to make the most sense for my application.)

I ran into two interesting things which I’m noting here for future reference.

Keep the interior value declarations simple by using the typedef keyword.

At one point I found myself writing the following code:

   std::pair<std::map<Key,std::pair<std::list<Key>::iterator, T> >, bool> ret;

And of course the code didn’t work–which was really irritating, because I was getting all sorts of weird messages that had something to do with whatever it was I was declaring. Arg!

My lesson: break the declarations into class-scoped typedef declarations:

typedef std::list<Key> CacheList;
typedef CacheList::iterator CacheIter;
typedef std::pair<CacheIter,T> MapVal;

typedef std::map<Key,MapVal> Map;
typedef Map::iterator MapIter;

Then the declaration of the return value of a std::map::insert() call becomes easy:

std::pair<MapIter,bool> ret;

Once I did this, I learned my second lesson:

Sometimes you need to declare a type as a typename for some odd reason.

I’m sure there is some C++ template expert out there who will tell me why–and it will be blindingly obvious when I hear the explanation. I’m sure it has something to do with the nature of the declarations and how they are used within a template class declaration. But for now, it seems to me that under some cases you need this ‘typename’ keyword for reasons that aren’t obvious to me–but once they’re there, all is good in the universe.

And for those experts out there, I’m sure you spotted what I screwed up in the above listing right away. For the rest of the class, I needed to insert ‘typename’ for the iterator typedefs:

typedef std::list<Key> CacheList;
typedef typename CacheList::iterator CacheIter;
typedef std::pair<CacheIter,T> MapVal;
		
typedef std::map<Key,MapVal> Map;
typedef typename Map::iterator MapIter;

Without the ‘typename’ declaration, I was getting these mysterious errors:

type std::list<Key, std::allocator<_CharT> >' is not derived from type 'mapcache<Key,T>'

For reference, the class that I put together to do this simple caching scheme is here. Licensed with a BSD-style license in case anyone else finds it useful.

Macintosh Programming

One of the more interesting aspects of Macintosh programming is that you find yourself sweating the details. You find yourself spending a day or two sorting out NSViewAnimation in order to get your inspector window to open and close subsections gracefully. You find yourself worrying if “Lucidia Grande” is properly selected as the default font for a number of controls. You find yourself wandering how to create an anti-aliased box around a group of items in a tree view.

This fits very well into my theory as to the different levels of software development, and why I don’t think I want to work for a dot.com anymore.

At the bottom level are the business analyst programmers. Their job is to take data and write a program to generate a report–and in many ways this is the easiest sort of programming, since you are probably the only person who will ever run your program. The goal is not code elegance, but the report–and if you have to hack your code together in a mix of Visual Basic and SQL and a little Microsoft Excel bit fiddling, it doesn’t matter, since the product is the report.

Next comes back-end “enterprise” software development. Most of Yahoo!’s Panama system consisted of this sort of development. The audience for your software will either be analysts or internal people (such as Yahoo’s advertising editors and sales people); if a feature isn’t elegant or doesn’t quite work right, you just send out a memo warning people not to use the feature until the next version is rolled out. What makes this sort of development a pain in the neck are the number of Architecture Astronaut wannabes floating around who over-engineer aspects of the system because, well, because it doesn’t matter. (One component I worked on was broken into eight separate EJBs with elements using Hibernate–and the fellow who was nominally in charge of this code justified the design because of the “heavy load” the system would take. Nevermind it made the system impossible to debug or add features to–or the fact that at maximum load it may take perhaps 10 transactions a second, which, with a simpler design, could be handled by a modest box running MySQL…)

Next on the totem pole comes application developers who are releasing boxed software. The audience for this piece of software are end-users–and there could be thousands or millions of them: customers who just plunked down $49 or $199 or $499 or whatever, and they bloody well expect every bit to just work.

And at the top of this totem pole comes embedded developers, whose software could be used by thousands or millions of people and which must be flawless: the end-user doesn’t think he’s buying software, he’s buying a car or a television set or a video camera, and it’s not like you can send him “version 2.0” of his BMW 3-series car to fix a bug in the ignition timing software.

What constrains each level of software development is the audience: as the audience for the software increases, the need to get it right the first time goes up, and the ability to fix bugs “on the fly” goes down. And because the need to get it right the first time goes up, the need to properly manage the project also goes up: you cannot fix managerial mistakes (because you didn’t reign in your 20-year-old architect astronaut wannabe) by just pulling an all-nighter and rolling out a new version of the software. When you’re writing application software or embedded software, you cannot just roll out a new version tomorrow to fix the broken version you rolled out today.

That’s why I don’t want to work for a dot.com anymore. Because most dot.com software development is essentially enterprise development–and because the demand to “just get it right the first time” isn’t really there, you get a lot of mismanaged projects and a lot of screwed up politics which needlessly waste a shitload of time that could be better spent elsewhere.

I’d rather sweat the details today than deal with a “production server push” at 2 in the morning to fix some detail no-one bothered to sort out because, well, it just didn’t matter…

A New Venture

Over the past few years while working for Symantec and Yahoo! I managed to save some money, which gives me the space to try out something new: writing software on my own. We’ll see if it works, or if I starve. 🙂

As I encounter more oddities in Objective C, Java or on the Windows platform, of course, I will post them here.

“And dammit foosball doesn’t play itself.”

Architecture astronauts take over.

Why I really care is that Microsoft is vacuuming up way too many programmers. Between Microsoft, with their shady recruiters making unethical exploding offers to unsuspecting college students, and Google (you’re on my radar) paying untenable salaries to kids with more ultimate frisbee experience than Python, whose main job will be to play foosball in the googleplex and walk around trying to get someone…anyone…to come see the demo code they’ve just written with their “20% time,” doing some kind of, let me guess, cloud-based synchronization… between Microsoft and Google the starting salary for a smart CS grad is inching dangerously close to six figures …

Yep.

And the irony is that for Microsoft and Google, with rich cash flows coming from a grand total of three market monopolies between the two of them (Microsoft Windows, Microsoft Office and Google Search Advertising), is that it is in their best interest as companies to pay ridiculous salaries to kids in order to discourage them from coming up with the next best thing that may undermine Microsoft and Google’s monopolies.

What you do on-line, or why Yahoo! is doomed.

I’ve given this a little thought, and I’ve come up with six different activities people do on-line. These are only broad categories, and there is some overlap. But I think you can sum up what people do into the following six things:

(a) Reading Information. That is, you go on-line to find information: the current news, weather, sports scores, and the like. While this somewhat overlaps the “passive entertainment” category, other things in this category may include reading on-line computer programming manuals or reading mathematics tutorials.

(b) Searching. This somewhat overlaps the “reading information” category, but by “searching” I mean actively going to a search site such as Yahoo! search or Google search, and repeatedly iterating through a few keywords until you find something you are looking for.

(c) Interacting. This covers the entire gamut from reading LiveJournal to checking your e-mail on Yahoo! mail to texting people on Twitter. You’re talking to people or reading their responses. And while this does overlap with “reading information” and with both “passive entertainment” and “active entertainment”, the primary focus of this activity is interacting with other people.

(d) Buying Stuff. Amazon.com is a prime example of this sort of activity: you go on-line to buy a good or service or product which is either downloaded to your system or which is sent to you via mail.

(e) Passive Entertainment. Television is an excellent example of this, as is YouTube: you’re sitting in front of the computer being entertained. The flow of information is one-way, and while this can overlap activities such as “reading information”, “interacting” and “searching”, generally the point is to sit back and enjoy.

(f) Active Entertainment. By “active” I mean game playing, as opposed to watching YouTube: you’re online to play a game. And while this can overlap with “interacting”, active entertainment involves both a structured environment (an on-line game) and established goals. (I’d categorize Second Life as “interacting” rather than “game play”, as there is no structured goals within Second Life.)

Now companies like Yahoo! and Google and even on-line publishers make their money through advertising. And there are literally a ton of social web sites cropping up which are based on the idea that once you drive eyeballs to your site, you can somehow monetize those eyeballs through advertising. After all, that’s how Google made it’s money: by driving eyeballs to Google search, they’re making money hand over fist by running ads on Google search.

But…

But let’s think about on-line advertising in terms of the six activities above.

Interacting. When you’re interacting with friends, you’re focused on interacting with friends. Advertising–outside of a recommendation made to you by your friend, which could be a viral ad–simply won’t work. And it won’t work for a simple reason: the advertisement is orthogonal to–and distracting from–what you’re doing. Basically, to convert that eyeball to a sale that person has to stop interacting with his friends: a change of context from one activity to another.

Active Entertainment. Like interacting with friends, active entertainment involves actively participating in a particular activity–and unless what you’re trying to sell directly relates to that activity, such as advertising a sequel to the game, you’re essentially forcing the person to change what they’re doing from one activity to another. And while there is a lot of experimentation in in-game advertising, I suspect the return on investment will suck, because in-game advertising has the disadvantage of being like billboard advertising: we’re programmed to ignore it–but add that to the fact that it’s a path we’ll probably only go down a few times and then never travel again, after we’ve completed the game.

Reading Information. Web sites like CNN and Weather.com are attempting to make money through related advertising–something that Yahoo calls “context match”, where the ad is matched to the content of the web site. But if you’re on a site looking for information, chances are you either are engaged in “passive entertainment”–that is, you’re just reading for the heck of it–or you’re reading information. While I’ll cover “passive entertainment” later, the problem with reading information is that unless there is an ad which is directly related to what you’re reading about (such as a calculus textbook advertised on a web site covering calculus), the chances of converting the person’s information seeking activities into a sale strike me as slim to none.

Passive Entertainment. The advantage of advertising to someone who is engaged in passive entertainment is that if they’re just flipping through a bunch of pages, chances are they may click on your page if it looks interesting enough. So the click-through rate for advertising to someone engaged in passive entertainment may be fairly high. But the ROI will undoubtedly suck, as people engaged in passive entertainment are at best window-shopping–and it’s fairly unlikely they’ll bookmark your page to return on a later date, since your page is just one of hundreds being flipped through by someone who is just “browsing.”

Buying Stuff. Someone who is on your web site looking to buy something could possibly be upsold–so it may be a good idea to make the product your selling easy to categorize so they can easily discover additional products that they may want to buy. But unless you’re running a large web site like Amazon, you may not have a lot of stuff to upsell to begin with.

On the other hand, one problem I’ve experienced with Amazon is that related products are poorly categorized: when searching for a computer game for my Macintosh I may find myself on a page with the Windows version–yet no link to take me to the Mac version. And Amazon’s current algorithm for matching related products sucks, as it seems to simply weigh by what people buy rather than by what is related. (Meaning if I’m looking for a computer game, don’t try to sell me a DVD as well.) In this way I think companies doing on-line sales are leaving money on the table: Amazon, for example, is excellent at allowing me to find something I know I want, but lousy at showing me related things that I may want to buy.

Searching. Here is the cash cow of the Internet: if I’m looking for something, and a ‘sponsored link’ gives the result of what I want, and I’m looking for something to buy–well, chances are you’ll have an excellent ROI since I’m there looking to spend money.

I think Google and Yahoo’s Overture found the cash cow of the Internet: search. Search advertising is a cash cow, and it’s being milked quite nicely–but it’s a cash cow because advertising plays directly into the activity the user is already engaged in. Passive entertainment advertising may currently be a cash cow–but at some point advertisers may start realizing that the return on investment is just not there, since the real goal of most advertisers is not to gain eyeballs–but to sell stuff. And the conversion on passive advertising is really not all that high.

Web sites like Yahoo! Mail and MySpace and LiveJournal–advertising there is going to suck big time, as unless you’re doing “feel good” brand awareness ads, chances are, you’ll never get a conversion. And for web sites like Wikipedia, the only way advertising will work is if it is specific and specialized: a wiki link on statistics won’t sell a lot of windows games, but it may sell a lot of scientific calculators and statistics books.

Unfortunately, however, most Internet companies are still thinking of their users as undifferentiated eyeballs–and are operating under the delusion that those eyeballs can convert at the same rate. Which is why companies like Yahoo! are doomed: unless Yahoo! can figure out a better way to bolster its search advertising by driving more users to on-line Yahoo! search, they’ll never be able to monetize the eyeballs to the degree they think.

The Big Three of C++ Classes

I ran into an interesting problem while working on some code, and I thought it would probably be a good idea to, well, document the problem so I can remember it in the future.

The problem was this: I have a C++ class which is the key index in a std::map class. This C++ class wraps a Mac CFUUID object and provides a unique index based on UUID. And it was mysteriously crashing.

The root of the problems I had with my class were this:

(1) I wasn’t declaring the big three entry points for a C++ class to be used as an object within a C++ container class, like a std::map class. For the handful of people out there who don’t know, these entry points are the copy constructor, the copy operator, and the destructor. In my case, I was missing the following:

class CStdUuid {
    public:
        CStdUuid(const CStdUuid &);
        ~CStdUuid();
        CStdUuid &operator = (const CStdUuid &);

(2) In order to be used properly for comparing keys within a map, I also needed to properly declare the following compare operators:

        bool operator == (const CStdUuid &) const;
        bool operator < (const CStdUuid &) const;

Now I’m not quite sure off the top of my head if I only need to declare these two operators to be used as a key in a std::map class, or if this just happens to be true for my particular implementation of the standard C++ template library. I’m sure a quick search with Google will yield an answer.

But why my particular implementation was crashing was simple: my implementation of the CStdUuid::operator < operator was screwed up. Because my class was returning true if the items were equal, and not when my class was less than the provided class, the std::map class became confused, and was crashing mysteriously.

Which is today’s lesson of the day: if std::map is crashing mysteriously, check your compare operators, since the tree structure inside std::map may be getting munged by an incorrectly declared compare operation.

Blogging My Successes And Failures

As I move from employee to self-employed software developer and attempt to build a company around my ideas, one central point sticks in my mind that I read from Paul Graham: if one is to succeed one has to make failure more costly. Not just in terms of wasted time or in terms of lost money–no, one has to make failure personal.

Making failure personal is actually rather easy: first, make what you’re doing part of your identity. When we introduce ourselves we often introduce ourselves with our status or our position: “Hi, I’m Joe, and I’m a sophomore student at cool college.” “Hi, Joe; I’m Jeff and I’m a senior developer at awesome corporation.”

So, in two weeks, I’d like to introduce myself as Bill Woody, sole proprietor and principal software developer of Chaos In Motion, a startup corporation specializing in business communications and management software. It’s now part of my identity–it is now part of who I am. Which means this must be a single-focused part of my identity: I cannot be “a part-time student and chief programmer” because if the chief programmer fails, well, hell–I was always just a part-time student anyway. Who cares about the fact that my company fails.

But if I’m not anything else, well, who wants to go through life being a personal failure?

The second step is equally easy: announce it to the world. Announce it to your friends, to your family, to your wife and kids–make your personal success or failure as public as possible. Join social groups or alumni luncheons and make it part of your identity. It is who you are. It is what you are all about.

And as soon as everyone else around you has bought into your own identity, and as soon as you have bought into your own identity–well, now you have no choice but to succeed regardless of what hell you must put yourself through.

Because it’s either that or acknowledging the most hateful thing we can possibly do: that we haven’t just failed to start up something–but that we are in fact a failure. We’ve failed our friends, our families, the people in our social circles. We’ve failed ourselves.

So you’ll excuse me if I make blogging about my own startup a core element of this blog. Because it’s my intention to be about as public as humanly possible, in order to make the price of my failure as expensive as humanly possible.

A theory as to why many startups are done by college kids.

It’s rather simple, really.

College age kids are not better programmers: age and practice generally makes you better, not worse. One doesn’t lose one’s ability to write code at 40 if one keeps on writing code from the age of 20: 20 years of practice is for any skill better than 2 years of practice, assuming one keeps on trying at the same level at 40 that one used at 20.

College age kids are not better business people for pretty much the same reason.

No; college age kids have two advantages over most software developers. One, they’re young and unattached: they don’t have kids and a mortgage and the trials and tribulations of life to distract them from being single-focused on a task. Sure, it may take even a really good hot-shot college age programmer four times as long to solve the same problem as someone with experience. But they have the time and the lack of distractions.

Second, and on a related note, they’re cheap: Paul Graham’s Y-Combinator is able to provide the initial funding for two college-age students to start a startup company for $20,000. For someone who has an established career and some modicum of success, $20k represents maybe two months pay–or even less if one has a good stock sharing program with a tech company on the way up. But for two college-age kids, $20,000 is enough seed funding to start running a startup.

With so little to risk, relatively speaking, it makes sense that someone who doesn’t have much to loose and who can live on so little can then run a startup.

But it has nothing to do with age per se: the guys who founded Adobe were in their 40’s.

Well, it’s time for me to put this idea to the test. After the past 6 years of working at Symantec and Yahoo! (and you can tell I work at Yahoo! because I remember the exclamation in the company name), I’ve managed to save enough to keep me going for a while without drawing a salary. So it’s time to quit my job, start my software project, and build something for myself.

We’ll see how quickly I can come up to speed doing Objective C++ on a day by day basis, though my idea involves data both on the desktop and “in the cloud”–which implies that I’m also going to be doing some web programming in Java. And we’ll see if after a year I either run out of cash without a single thing to show for it, or if I can make my savings stretch long enough to achieve some degree of success.

Because the reality is, in the tech world, you don’t get promoted without changing jobs, and you don’t reach upper management without running a startup.

The Calculus of Risk

The other day a nice gentleman who had a hold of my business card contacted me with an idea for a web site that he wanted me to help develop and run. He thought it could be the next Craig’s list or the like: and while the idea was an interesting one, I told him that I wasn’t interested in working on a web site.

I’m sick of web site development. If my time at Yahoo! has taught me anything, it’s that web site development sucks. Or rather, the “constant iteration” that Yahoo! practices and that I’ve read elsewhere about how web sites “should” be developed sucks, as “constant iteration” really translates (at least at Yahoo!) to “management can’t get its shit together and plan things in a reasonable way, so you’re expected to constantly be on call because no-one can plan more than 15 minutes in advance.” I don’t mind “plans are subject to change without notice because of new information that came in during execution.” I do mind “we changed our minds because we have no clue what we’re doing.” Especially when events were easily foreseen.

But I digress.

Part of what I tried to convey to this person is my own take on how I would evaluate the risk/reward of my getting involved in a new project–and that, mathematically speaking, for me to get involved in a project like his would be expensive. And I mean “oh, shit, you’re kidding!” sorts of expensive.

So let me break down my own thinking about money–and let’s put some numbers to this, shall we?

I’m a software developer with 20 years of professional experience, and I think I’m one of the best programmers out there. (Do I have an ego? Probably. But it doesn’t change the numbers.)

Let’s assume my salary is around $150,000/year. Probably not far off for someone with 20 years of professional experience in Los Angeles, when you factor in bonuses and stock options and the like.

Okay, now say I’m going freelance. Well, when you add in corporate social security matching (which is really just a hidden tax), insurance, unemployment and the like–you need to add another 25% to that number. So this brings the amount to $200,000/year. That is what I would have to bring in as a freelancer in order to match my salary.

Now lets assume I’m freelancing. (And I used to freelance, so I can attest to the following numbers.) If I’m doing real well, I should expect only about 60% of my time to be billable time. Why? Well, I’ll want to spend some time on vacation–four weeks a year cuts the number of billable hours by almost 10%. And the rest of my time will be spent searching for more freelance work–since, really, the reward of a job well done is being patted on the back and shown the door.

This translates into a base hourly rate of $200k/1200hrs or $160/hr.

Suppose I want to put together a web site for someone as an investment. Say it will take six months to assemble the web site. Well, the amount I would charge to do this as a consultant is easy: $160 * 24 weeks * 40 hours/week = $153,600.

Now this is where things get interesting. Suppose, for example, that you want me to build this web site for you, but you want me to do it at a discount in exchange for a share of the resulting internet company. So suppose you want me to build the web site for (say) $50,000. This means that I have, in effect, invested $103,600 to your project. Now suppose it takes 3 years for the company to develop, and after my initial investment in time I have no involvement at all in the company–and after 3 years, there is a 1 in 20 chance that the company will become “successful”–that is, you’ll convince Yahoo! to buy you out.

What should my return on this be?

Well, that’s simple. Currently T-Bills are getting about 5%/year. So if I were to have taken my $103,600 and instead put it into T-Bills, that would have grown to about $120,000. (The reason why I’m using T-Bills is because there is zero risk to that investment. In other words, I’m not interested in what I may be able to get for that $103,600–I’m interested in what I would get if I had taken no risk. Because any return above that amount would involve some risk–and any return below that amount means either my risk didn’t pan out or I’m an idiot.)

Using Bayesian math I can say that if my risk is 1/20 that I will get a payout and 19/20 that I won’t, then the potential reward that I would have to receive for taking a risk that 19 out of 20 times your web site will not return anything would be $120,000 * 20 or $2.4 million.

In other words, if I don’t see an upside of $2.4 million on my six months of work if there is only a 1 in 20 chance of success, I’m better off on the average keeping my day job. And, more importantly, this is the “break even” point for a web site that only has a 1 in 20 chance of success–in order to motivate me, I should receive more. In other words, we can work this math backwards–and when we do so, every $100,000 in potential reward 3 years from now is only worth around $4300 today. So if you entice me with a potential $3 million reward in 3 years–and remember, this is assuming that I am not involved at all for the 2 and a half years between completing my work and the ultimate payout; if I’m involved, this number can go up dramatically–that would be the same as if I swapped jobs and got a 15% pay raise.

Why such a large number? Because there is risk involved. And for every success story we heard about in Silicon Valley, there are dozens who found themselves screwed one way or another. It’s easy to concentrate on the successes, but we ignore the failures–after all, we think we won’t fail; we’re smarter than everyone else. In mathematical terms, we think the chances of success is like 1 in 2 or 1 in 3–not 1 in 20. Thus, we misestimate the potential for downside. We also fail to properly estimate what we are worth–that is, how much we could make if we took no risks–which is why in many cases I’ve seen people walking away having negotiated a present-value contract that earns them less than minimum wage: out of their ignorance they put themselves in a worse position than if they’d went to flip hamburgers part-time at McDonald’s.

Now me, I will factor in my abilities–and I know that I can reduce the probability of failure simply because for many companies, they fail simply because they fail to release a product. Millions in invested money later and all they have to show for it is a roughly written demo and the PowerPoint they gave the venture capitalists. So I may internally tweak the numbers: for me, it may be 1 in 15 chance of success. And of course there are more outcomes than “jackpot!” and “failure”, and sometimes even failure gets us where we want to go. After all, very few businessmen succeeded the first time out.

But ultimately this is the mathematical analysis I will apply if someone asks me to quit my day job to put together their web site. Of course the salary numbers are just numbers I pulled out of my ass–and I may factor in other intangibles, such as the potential upside in the event of failure. But don’t be surprised if I don’t quit my day job at Yahoo! simply because you think you have the next great idea and want to cut me in for 10% of your ten million-dollar idea.

(Note: The numbers above have been changed to protect the innocent. No numbers were harmed in the writing of this essay. Your mileage may vary.)

Cool.

One of the things that makes me happy about my alma matter is that they do not award honorary degrees. The highest award given is the “Distinguished Alumni” award, which, naturally enough, only go to alumni.

At some point I’ve realized that the best professional social circles revolve around one’s alma matter–and given that they’re just down the street from me, there is no reason for me not to get involved.