The Freegrade Business Model

Provide free accounts with limits (on the number of things like photos, emails, users, etc. or on storage) with an option to upgrade to a paid monthly subscription account without or relaxed limits and maybe even additional features. Once you upgrade to the paid account, you must either pay to continue or stop using the application.

Works best if you have a product that users get hooked to and will pay to continue using once they have exhausted the limits. Interestingly, the exhausted limits are a good indicator that the user is hooked.

This is different from the Freemium Business Model, in that the differences between the free and paid accounts are in the limits and not necessarily in features alone. It is also different from the Free Trial Period Model that usually has a limit on time, which might result in prompting the user to upgrade to a paid account before they are hooked. I coined this term primarily to differentiate it from these models.

Examples: Wufoo, Flickr, Basecamp

The word freegrade is a portmanteau created by combining the two aspects of the business model: free and upgrade.

Being explicit about "unsafe" function

Update: I've dropped most of the ideas mentioned here.

I'm toying with the idea of prefixing unsafe functions in swx with unsafe_ (example: unsafe_swx_mapper_match). I like how this makes explicit the fact that I'm testing unsafe functions (example: test_unsafe_swx_mapper_match). This is similar to the use of the exclamation (!) suffix in Scheme and Ruby. If this works well, I might do the same in inertia.

Couple of other things you might notice if you haven't done much programming in PHP are the swx in the function names that acts like a namespace for swx and the underscore (_) prefix in some function names (example: _unsafe_swx_mapper_pattern) that marks them as private functions for internal use only.

Continuous Software Maintenance aka Agile Software Development

Its widely accepted that about 40-90% of the total cost of an application is incured after it goes into production, the phase that is traditionally called maintenance.

When I'm doing Agile, not the practice-oriented farce kind, but the values-principles-oriented real kind, I don't build software in phases. I develop software in a continuous flow of activities. When I'm doing this, it feels like I'm continuously maintaining the software instead of only maintaining it after its done, and that makes all the difference.

Procedural Programming is NOT a Bad Thing!

For way too long now, I've heard proponents of object-oriented programming describe badly written programs as "procedural", as if to imply that procedural programming is a Bad Thing.

Good design is possible using any programming paradigm, just as bad design is. Stop using procedural programming as a derogatory term!

I personally prefer multi-paradigm programming, so that I can use the paradigm that feels right for the job at hand.

We Don't Need No Version Number

When your delivering working software in a continuous flow, versioned in a DVCS, do you really need version numbers?

Rules-First Programming

From Just Ship, Baby by Kent Beck:

I’ve sneering dubbed this philosophy “Rules-First Programming.” I hope by naming this demon I’ll have power over him the next time he comes to sit on my shoulder. When doing things right becomes more important than doing things at all, I hope to recognize his peculiar smell, an acrid mixture of frustration, sanctimony, cowardice. “Rules First Programming,” I will say, “you better go sit on some other fool’s shoulder today because today I am going to ship.”

Right on!!