SMS Meggies go viral in Trinidad

My friend at Teleios told me about a new application his company had launched Friday called “Meggie Wars”, a system where you could send different “meggies” to friends via SMS.
What was interesting is that in the first half hour of launch my friend indicated they had already experienced 300 unique cell number signatures in use on the service.
When I met with friends later at least 10 of us spent a good 20 minutes playing with the service. Together my small band of friends probably generated over 500 messages on the system. To get started all you had to do was send “help” to 3643 from any BMobile mobile phone. It would then give you back a list of instructions on how to use the service which were quite easy to follow.

For now the service is free, but imagine such a system with similar volume and viral adoption and growth and which could have been generating revenue between 10c to $1.00 per message, either through caller costs or through text advertisements included with each message sent.

Now that they have started this fad and introduced a noticeable cross section of the local mobile community to the concept of SMS Application services, I would love to see if my friends at Teleios can take the concept mainstream and “Cross The Chasm” between early adopters and the mainstream users to take this from a “nice to have” to a “need to have” segment of the mobile market.

This, to me, is key to defining the great companies of the future from the good ones.

Trinidad life -Almost losing my dad because of crime…

My father was held up and gunpoint yesterday in our family business, and if not for the chance occurrence of the shell/cartridge falling out of the shotgun held by one of the robbers while he struggled with them, my father would have been murdered yesterday.
My dad still didn’t come through totally unscatched. In the course of struggling with the robbers he fell and broke his ankle, and now has to walk with crutches for the next several weeks.
This is a man who I love so much that I can never express in words how much sorrow it would have caused me to have lost him.
I hope my little brother doesn’t read this before we speak of this to him, because this is definitely not how I want him finding out about it. Lord knows he already has enough struggles having to excel in his U.S. Naval AcademyNaval Hospital Corps. School exams while being so far away from all he knew.

This isn’t the first time one of my family has been held up at our business.
This time though it came closer that it ever has before to being the last time for my father.
And for what?
Human life is now so insignificant to some that the chance of acquiring a few hundred dollars is all the motivation some need to take one.
Is life really that hopeless for these people?
Or is this because they realise more and more daily that there are no consequences for those actions, not in Trinidad anyway. Trinidad life over the last few years has consistently reinforced my thinking that we just have the facade of a civilised country.

Criminals could have stolen from me one of the few precious gems I keep in my life. Our family business still runs, it needs to so that we all can eat tomorrow, so what happened yesterday could (knock on wood) happen again today, or tomorrow, or anytime again, with worse consequences. Criminals continue to have more motiviation to commit crimes and less disincentives to find honest means of livings. This is the reality of living in Trinidad today for me.
And I find that so disgusting.

Notes on Unit Testing

Walking a coworker through the concept of test driven development and unit testing I designed some notes on it. So I thought I’d copy them online for future reference.

TDD steps:
A. Choose a test or suite of tests. Design it/them.
Design mode involves asking the following questions:

1. What do I assume exists? (the Setup phase)
2. What do I test for? (the Assertion(s) phase)
3. What do I reset after? (the Teardown phase)

Designing tests well will save you much headache later down the road. Take my word for it. If not, go through the rest of the steps, hit the headaches and pitfalls then read back the “I told you so” statement I have waiting here for you :)

B. Write the code for the unit test(s) according to the above plan.

The Setup and Teardown phases may be best written first because you are changing then restoring the state of the software system within the setup and teardown phases. This will happen when you need test data present that should not be persisted beyond the scope of the test. You would always want to leave the system clean, i.e. in the exact state it was in before you ran the test.
This is done by ensuring the Teardown phase removes any system changes made in the Setup phase and both are ideal to be written together before the core unit tests in the suite are written.
O, and make sure once you write your Setup, Teardown and test methods that the project actually does compile.
This would almost certainly require you to create “stubs” (i.e. empty or unimplemented) classes for those new objects you intend to be testing in addition to referencing already tested classes and their methods.
Don’t worry that you’re referencing unimplemented classes in your tests just yet, that’s why you’re writing the tests, so that when you get to writing them you know exactly your progress in coding them.

C. Run NUnit (or test suite of choice) and ensure all tests fail.

At this point you may choose to call a coding checkpoint with your team lead/peers to ensure that you have truly written a useful and complete suite of tests, and to fill the gap in ensuring there are no critical tests you may have overlooked that should have been designed and coded in this cycle.

D. Write the code that enables the tests to pass.
This is the meat of things. You know what you’re testing for, so you now implement the logic to make this happen. All those nicely stubbed objects now get substance in your quest to empower them with the logic needed to pass the tests.
Once all your red lights (fails) turn green (pass), you’ve just made a significant step towards completing this development cycle.

E. Refactor your code to make it more efficient.
This is important. Getting all tests to pass is good, but we don’t always do things the right way the first time. Look back at the code that passes each of the test.
Could it be optimised in some way?
Did you take any shortcuts in a moment of weakness/time crunch to make the test pass that you need to correct now to make the code more robust?
Will this code be chewed up by your peers for its lack of pattern usage, adherence to coding standards, complete documentation etc at a code review or revered as a masterpiece in coding and a job well done?

F. Code Review.
This is the often missed/sacrificed step, but it is as important as all others. You’ve gone through the previous steps and done the best job (hopefully) you could getting your code optimised.
You are now ready to have it validated by your peers. Don’t avoid it because you fear getting criticisms, this is good, since it shows you where you have to grow in building better code later down the line for other tests.
And it will obviously lead to better code delivered to the client.
Of course if you’re the one asked to participate in the review, remember the five C’s when giving feedback in these reviews that will make it a good one, i.e. be Caring, Consistent, Clear, Current and Concise with your feedback.

G. Integrate review feedback and be done.
Once you have aggregated your peer feedback, ensure that you have integrated it into your current code set.
Once you have done a proper job checkpointing with your lead during the development process your peer feedback should only be minor tweaks in code. It should not lead to a major rewrite of code, and any time it leads to this you either are not comprehending the feedback given or really did do a half-assed job in the first place moving through the previous steps.
Checkpoint with your lead if you are unsure how integration should occur, or if you find it is taking more time than a minor rewrite should to ensure you are understanding the feedback given properly.

H. Call it done. Move on.
There you go. Once these steps are complete, you’re done, you can move on to developing a new set of tests for another feature set and repeat the cycle.