Renamed Swx to Bombay

Apparently people are using the word Swx to refer to the SWX format (an open-source subset of the SWF format) which has an associated application called SWX PHP that might lead to confusion if I continue calling my project Swx.

Coming up with an alternative name for Swx, for some reason, brought back memories of the time Bombay (the city I live in and a name I loved) was renamed to Mumbai. I was toying around with the idea of calling my project Bombay and liked it a lot, so I went with it.

Routing in Bombay (WIP)

Default routes

Here are some examples that illustrate the default routes I came up with:

Example Request        handler function
---------------------------------------
GET /                  _home()
GET /foo               _show()
GET /foo?baz=qux       _query()
PUT /bar               _save()
DELETE /bar            _delete()
POST /                 _post()
POST /login            _login()
GET /users/            users_home()
GET /users/1           users_show()
GET /users/1?baz=qux   users_query()
PUT /users/2           users_save()
DELETE /users/2        users_delete()
POST /users/           users_post()
POST /users/poke       users_poke()

I chose *_save because it captures both the CREATE and UPDATE semantics of PUT. The other option was *_write() requiring me to use *_read instead of *_show for symmetry but that didn't feel right.

*_query was chosen over *_search and *_filter because its asking semantics is generic enough to be used in many different situation than the locating and removing semantics of the alternatives.

Catchalls

If none of the above handler functions are found, mapper.lib will fall back on the catchall handler functions.

Request        fall-back-1        fall-back-2   
---------------------------------------------
* /users/1     users_catchall()   _catchall()
* /foo         _catchall()

Update July 27, 2009: Renamed Swx to Bombay

Make your time framework, index.php are belong to me!

I've stopped active development on Inertia primarily because developing web applications in it did not feel very PHPish. It felt as if the web application was subservient to the framework instead of it being the other way round.

Inertia was an experiment in how a Resource-Oriented Programming (ROP) Platform would look like and it was an awesome learning experience, but its time to move on.

Describing Writting your web application using Bombay (take 2)

Scratch that! Screw describing the web application. Just decide for me and tell me what I need to do.

index.php

<?php

    require '/path/to/bombay.php';
    requires ('mojo');

    function _home()
    {
        echo "Hello World";
    }

?>

Trade-off flexibility for minimal cognitive strain and busy work.

Update July 27, 2009: Renamed Swx to Bombay

The problem with ugly, large and slow code

Bjarne Stroustrup in Masterminds of Programming:

"Ugly" leaves places for bugs to hide, "large" ensures incomplete testing, and "slow" encourages the use of shortcuts and dirty tricks...

Describing your web application using Swx (take 1)

Update July 05, 2009: Dropped the idea of describing web applications in favour of minimizing cognitive strain and busy work.
Update June 28, 2009: Added the 4th pattern with default params.

index.php

<?php

    require '/path/to/swx.php';
    requires ('handlers');

    responds_to_requests_like
    (
        'POST /{handler}',
        '/{handler}/[{id}]',
        'GET {handler}.example.com:8080 /foobar',
        '/.* handler=default,id=1'
    );

?>

Galla Thick Mango Magic: A refreshing drink with refreshing packaging

Loved the copy on the Galla Thick Mango Magic bottle:

3 Stages (WIP)

Craftsmanship:

1. Apprentice


2. Journeyman


3. Master

Friedrich Nietzsche:

1. Camel


2. Lion


3. Child

Osho:

1. Dependent


2. Independent


3. Interdependent

Japanese martial arts:

1. Shu


2. Ha


3. Ri

Code Is Just Code:

1. code is just code


2. code is patterns


3. code is just code again

Regular Collector, Occasional Reader

I'm a regular collector but occasional reader of books.

Currently reading Conceptual Blockbusting: A Guide to Better Ideas by James L. Adams (4th Edition), a book I bought about 8-9 years ago :)

SourceForge.net comeback?

Just when I thought SourceForge.net had become irrelevant, I find myself pleasantly surprised at what they've been upto.

Here are a few reasons I think they are headed in the right direction:

* A new uncluttered homepage with a cool infographic:



* They've kept up with the DVCS trend and now support GIT along with Mercurial and Bazaar.

* They deprecated some of their crufty, less-capable built-in applications and replaced them with some great open-source applications on their Hosted Apps service so that they could focus their development time on providing great service.

* Provide direct support via freenode IRC.

* And most importantly, all of the above seem to be a result of the conversations they are having with their users (blog, twitter).

Conversational Applications

One of the principles of Owe.to was that it had to be conversational. This means that instead of the traditional filling-up-a-form experience of web applications, it should feel like you are talking to Owe.to. I first came across this when I saw the Huffduffer sign up page:



This is what I came up with for Owe.to:



Forms that are conversational come with a unique set of issues that you need to deal with to make them usable for the user. For one, they don't have labels, and the user has to figure out what he needs to fill in based on the context. I came up with a way to provide additional context using a sort of dynamic label that I call Callout Labels that appear when the form field receives focus (think this evolved from a tooltip suggestion by Jinesh):



How about help text? The traditional way of displaying help text around the form field was not feasible, so I had to display greyed out help text inside the form field itself that disappears when it receives focus (look at the previous two images). Although this technique is wide spread (for example, in search forms) it hit home in the context of Owe.to when I came across Twitpay:



Another interesting issue is figuring out how to display validation errors. I'm not there yet with Owe.to, but I like how Huffduffer does this:

Owe.to Design Principles

Principles that help guide Owe.to's personality and the experience it provides:

• Indirect: To overcome the awkwardness of asking friends to pay you back, you should not have to address the friend directly.


• Conversational: Instead of the experience of filling up a form, you should feel like you are talking to Owe.to.


• Peace of mind: Telling Owe.to about a friend, should mean that you can forget about it because Owe.to will remember, and repeatedly remind the friend till a resolution is reached.


• Quick and easy: Collect the least possible information from you to reduce the investment required by you to try-out/use the service.


• Terse: Reduce the amount of information you need to process.


• Incremental: Like real people, the personality of Owe.to and the experience it provides, will keep developing (changing/growing/evolving) over time.

Owe.to's story began when I saw a friend of mine asking another friend of ours, to help him collect money from the people he had paid for the previous night clubbing. At that moment, I realized just how awkward it is for some people to ask friends to pay them back. That incident compelled me to start development on Owe.to, a service to remind friends to pay you back, without the awkwardness!

Why I prefer Prioritylog over Backlog

Backlog has negative connotations for me; of not keeping up (falling behind), of making slow progress, etc.

I prefer Prioritylog instead, because it emphasizes the fact that the list should be prioritized (so that it can be pulled from).

Limited Paying Customers

If your building a niche product and using either the Freemium or the Freegrade business model, this might be an interesting strategy to quickly convert your non-paying users into paying customers and charge a premium while your at it.

The idea is to limit the number of paying customers you will accept for your niche product. For example, if your targeting a very small niche, you could limit the number of paying customers to something like 99.

That way:

• The non-paying users feel a sense of urgency to convert into paying customers, and
• making it exclusive means that you might be able to charge a premium and maybe in return also customize the software for the paying customers.

If your familiar with the psychology of persuasion, then you'll recognize this as an applications of the principle of scarcity .

I came up with this a few days ago and haven't come across anyone doing this yet, but I have a feeling it will work because:

• I think you can make more money by doing less, and
• doing less per product, frees you up to build more niche product to improve your odds of success.

Think it'll work?


Some References:

• Available for a Limited Time Only:
  
  

  The Long Tail world is built on scarcity. If you have valuable niche information, charge more for it and offer it to only a certain number of buyers. When you hit the number you set, pull it off the market. You might just find you made more money than if you had offered the same product to all takers for a cheaper price.

• Overcoming Bias: Scarcity
• In short supply: 5 ways to use scarcity and exclusivity to fuel sales and boost your bottom line
• Book: Maximum Influence By Kurt W. Mortensen
• Book: Influence: The Psychology of Persuasion by Robert B. Cialdini

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!!

You Get What You Ask For (YGWYAF)!

From Lean Software Development: An Agile Toolkit by Mary Poppendieck, Tom Poppendieck:

People respond to the expectations of their management. Software development leaders will not flourish in an organization that values process, documentation, and conformance to plan above all else. An organization will get what it values, ...

Software Craftsmanships

From Lean Software Development: An Agile Toolkit by Mary Poppendieck, Tom Poppendieck:

New programmers start as apprentices to master craftsmen. As they become skilled, they teach other apprentices and eventually journey to work with other master craftsmen. Journeymen disseminate ideas and develop broad skills, eventually becoming master craftsmen themselves.

Intrinsic Motivation

From Lean Software Development: An Agile Toolkit by Mary Poppendieck, Tom Poppendieck:

Intrinsic motivation requires a feeling of belonging, a feeling of safety, a sense of competence, and sense of progress.

Failure is Inevitable

Failure is inevitable if you are part of something that you believe will not work.
Failure is inevitable if you are made to believe that you are not capable of doing a good job.

Don't Expect Perfection

There is a difference between setting high standards vs. requiring perfection down to the smallest detail (zero tolerance for mistakes). The former pushes people to do better. The latter kills initiative.

Encourage, don't nitpick.

Moving on...

cd my-free-software-projects
rm -fr .svn
rm -fr CVS
git init
git add .
git commit
git remote add github http://github.com/sandeepshetty
git push github master

The difficulties of visualizing software

Since software is not spatial, it is inherently difficult to represent in a way that is easy for the mind to visualize.

From No Silver Bullet (PDF) by Fred Brooks:

As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These graphs are usually not even planar, much less hierarchical.

...

In spite of progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, and thus do not permit the mind to use some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it severely hinders communication among minds.

Stories

This post by Joel made me smile and got me thinking about an interesting way to highlight the differences between the various ways we software developers perceive what it is we do. I haven't gotten around to describing the perceived benefit/reason of the As a user, I want user story template yet, but here goes:


As an engineer,
I want to build software
so that ...

As a coder,
I want make software
so that ...

As an author,
I want to write software
so that ...

As a craftsman,
I want to create software
so that ...

As a developer,
I want to evolve/grow software
so that ...

Estimating in Ideal Time might not be ideal

Ideal Time estimates are almost inevitably perceived as estimates of duration leading some (especially managers) to compare the Ideal Time estimates with actual Elapsed Time. Velocity then becomes a measure of efficiency, used to determine how close they are to removing the impediments that the developers encounter everyday. This might make sense, except that Ideal Time is not really about time and the good intentions might actually be detrimental if the developers find themselves explaining why they only got x Ideal Time of work done in x+y Elapsed Time.

The root of the problem is the assumption that the x in the x+y Elapsed Time is the same as the Ideal Time x.

Relative Measures of Size

Story Points
NUTs (Nebulous Unit Of Time)
Gummi bears
T-shirt Sizes

Velocity, and deriving an estimate of duration

By measuring the team's rate of progress (velocity) in terms of the number of size units of work [1] done in an iteration [2], you can arrive at an estimate of duration in terms of the number of iterations required to complete the remaining tasks: remaining size units of work divided by the teams velocity.

Instead of having to think about and account for the inevitable overheads that occur everyday, velocity gives us a way to map ideal time into elapsed time based on historic data.

1. ideal time or a relative measures of size
2. fixed length, comprised of working hours of working days

Ideal Time, an estimate of size

Ideal time (or ideal development time of effort) is the amount of time it will take you to finish a task if you had no interruptions or impediments. It is an estimate of size or effort and has little to do with time, since you rarely ever get contiguous blocks of productive time.

Estimating in ideal time is affected by various factors like the developers own cognitive biases, their skill and experience levels, complexity of the problem, the design of the software, and available tools, to name just a few.

Ideal time can be used to derive an estimate of duration.

See also:
Estimating in Ideal Time might not be ideal

Elapsed Time, an estimate of duration

Traditionally, software developers are expected to give estimates of duration in elapsed time. Elapsed time is the actual time (working hours of working days) it takes to complete a task. This includes time spent on things (inevitable everyday overheads) other than the task at hand.

Estimating in elapsed time is inherently difficult because, apart from the various factors that affect the estimation of effort for a given task, you also need to worry about: distractions and interruptions [1], unexpected events or obstructions [2], and just about anything else.

1. meetings, emails, interviewing candidates, phone calls, reviews, task switching, training, bug fixes, etc.
2. other projects, absences, developer turnover, non-cooperative team members, sabotage, etc.

Accurate Estimates

Accurate estimate is an oxymoron. You might get estimates that are better, never accurate.

Deliver When Done

When I was first introduced to Unit Testing, I didn't like it because it was doing things to my code that I didn't like. Over time I realized that it was my code that was the problem and not the tests. I seem to be in that same place again with wanting to continuously delivery working software without the artificial boundaries of iterations and releases. Where you make very thin slices of your tasks and deliver a slice when its done. Where every commit is also a deploy.

Note to self: Look up incremental development-and-delivery model

Estimation and Targets

For some, estimates serve as targets. Targets set the pace at which work gets done. They change one's relationship with time (you get a lot more work done on the day before going on vacation than on a regular day).

From Fundamentals of Software Engineering (Second Edition) by Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli:

A surprising finding was that, in a controlled experiment, the subjects who had no schedule at all finished their project first, beating out both the group that had an aggresive schedule and the one that had a relaxed schedule. Experiments have shown that engineers, in general, are good at achieving the one tangible goal that they have been given: If the primary goal is to finish according to a given time schedule, they usually will-but at the cost of other goals such as clarity of documentation and structure.

From Software estimation considered harmful by Peter Seibel:

Sometimes we set targets in order to convince others, or ourselves, that something can be done. We may set targets to inspire ourselves to do more, though it’s not clear that’s a winning move, and even less so when managers set a target to “inspire” the folks who work for them. (See DeMarco and Lister’s Peopleware, chapter 3 and the discussion of Spanish Theory managers.) We may also set targets to give ourselves a feeling of control over the future, illusory though that feeling may be. After the fact, a target hit or missed can tell us whether or not we did what we set out to do. However if we missed a target, we can’t know whether that’s because the target was unrealistic or because we didn’t perform as well as we should have. Setting and hitting targets does make it look like we know what we’re doing but we need to keep in mind that targets rarely encompass all the things we care about — it’s much easier to set a target date for delivering software than a target for how much users will love it.

If the goal is simply to develop as much software as we can per unit time, estimates (and thus targets), may be a bad idea. In chapter 4 of Peopleware, DeMarco and Lister discuss a study done in 1985 by researchers at the University of New South Wales. According to Peopleware the study analyzed 103 actual industrial programming projects and assigned each project a value on a “weighted metric of productivity”. They then compared the average productivity scores of projects grouped by how the projects’ estimates were arrived at. They found that, as folks had long suspected, that programmers are more productive when working against their own estimates as opposed to estimates created by their boss or even estimates created jointly with their boss, averaging 8.0 on the productivity metric for programmer-estimated projects vs 6.6 and 7.8 for boss-estimated and jointly-estimated. The study also found that on projects where estimates were made by third-party system analysts the average productivity was even higher, 9.5. This last result was a bit of a surprise, ruling out the theory that programmers are more productive when trying to meet their own own estimates because they have more vested in them. But the real surprise was that the highest average productivity, with a score of 12.0, was on those projects that didn’t estimate at all.

Estimation and Closure

A lot of us are uncomfortable with doubt and uncertainty. Estimation is a way for us to put a fence of certainty around the inherent uncertainty of software development. However, coming up with a date for when a task will be done, does not remove the uncertainty, it just hides it.


From Fundamentals of Software Engineering (Second Edition) by Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli:

Estimation is always accompanied by the risk of being wrong.

Silver Bullet?

Is minimizing repetition the single most important adaptive design (Probe-Sense-Respond vs. Sense-Analyze-Respond) technique?

From Lean Development & the Predictability Paradox by Mary Poppendieck

A key technique for absorbing changes easily is to avoiding repetition like the plague. If you have to say the same thing in more than one place – either in design documents or code – then refactor the design to consolidate the capability into one place. One of the most effective ways to facilitate change is to localize every potential change in only one place.

From Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck, Cynthia Andres:

If small steps are how to design, the next question is where in the system to improve the design. The simple heuristic I have found helpful is to eliminate duplication. If I have the same logic in two places, I work with the design to understand how I can have only one copy. Designs without duplication tend to be easy to change. You don't find yourself in the situation where you have to change the code in several places to add one feature.

IMO, if you couple minimizing repetition with writing code that is communicative, you should be in a fairly good place.

@StarWars

http://twitter.com/yoda
http://twitter.com/r2d2
http://twitter.com/C3PO
http://twitter.com/stormtrooper
http://twitter.com/darthvader

ROFL :))

Estimation vs. Guessing

Without information and experience you are not estimating, merely guessing.