From Motorist to Commuter: 3 Conditions to Convert Me to Use Public Transportation

MMDA recently proposed a new car coding scheme that would increase the car ban from once to twice a week. No wonder Dan Brown saw Manila as the gate to hell, despite its being purportedly Catholic (but that's another story). As expected, motorists protested this and cursed MMDA.

I actually like to take public transit. But in Manila, I hate taking the bus and train. Buses stop everywhere and it takes forever for me to get to Point B. Taking the train is also hell, especially at rush hour in MRT. Some stations have no proper ventilation and there are no schedules that would help me plan my commute. I am sure this is why motorists would rather pay high fuel prices, risk the hypertensive-inducing stress of driving, and incur expensive maintenance fees for owning cars, than take the bus or train.

I think that people like me would be willing to cooperate with MMDA, so long as commuting becomes painless in Manila. And for that, we need these systems-based solutions to be in place.

First, improve the bus transit system. Rid the streets of illegal buses. Revoke licenses of  notorious violators (including those who do not give monthly salaries to drivers and conductors). Enforce schedules and routes. Implement a bus rapid transit (BRT) system which would include making the stations comfortable and able to big enough to accommodate the volume of passengers.

Second, improve the light rail system. Decommission the small carriages of MRT and replace them with large cars that could take on the volume of passengers at EDSA. Connect MRT to the LRT line. Implement the single ticketing system among the three lines and also with buses.

Third, improve the security in the mass transit systems. Self explanatory.

Sort these things out and you will convert me and others like me. I enjoy commuting actually. Trains and bus schedules are the first thing I study when I am in a new city. I am easy to convert. So MMDA, instead of looking only at the symptoms, for once, deal with the root causes of why we favor motoring over commuting.

Why "Online Libel" Misses the Point

'Freedom is not worth having if it does not connote freedom to err. It passes my comprehension how human beings, be they ever so experienced and able, can delight in depriving other human beings of that precious right.' -- Mahatma Gandhi, 1931

There's something wrong about the concept of 'online libel'. A story published in traditional media goes through a gauntlet of revising, editing and printing/broadcasting. When it gets printed, it's permanent. It also takes a large amount of effort and money for the aggrieved to refute what gets printed/broadcast/published. 

Hence libel in a way seeks to rectify the permanence by forcing the media establishment to admit it did wrong and to retract its statement in the same venue, at their own expense. It is a way to enforce fairness. 

Individually produced blogs, Twitter accounts and FB pages do not have the same mode of production. Content in online media is ephemeral and can easily be retracted/revised. You could easily set up your own blog, FB page and Twitter account to make counter-claims to defend yourself. 

Lastly, traditional libel cases almost always involve the publisher too, which gives the author the resources needed for defense. This is almost always not going to happen in 'online libel'. Are they going to sue Facebook, Google, Twitter, and YouTube too because they 'published' the offending articles? Most likely not. In that case, the author is left to fend for herself.

Maybe the online libel provision will force online content producers to be more prudent and to check facts before they post something potentially damaging. But it will harm freedom of speech more by scaring ordinary people into subservience.

The Legislature couldn't grasp the concept that online media is a conversation between equals, rather than a one-way communication from the powerful media owners to the powerless consumers. Online media self-correct far more easily and quickly than traditional media. 

Passing this law and other similar ones -- like for example the criminalization of "camcording," which used to be a neutral term -- shows how detached our lawmakers are from the real world. In the age of social media, they are still struggling with outdated, outmoded concepts of media production and consumption. 

I'm very disappointed at how our lawmakers behaved in this debate. Sen. Sotto acted with impunity, using his position of power to get back at his critics. Sen. Cayetano washed her hands, saying she read her portion of the bill and left the rest for the others. PNoy said he read it thoroughly and found nothing wrong with it. 

These events just show that our current batch of politicians do not understand the age of social media. The first set of politicians who grasp the issues and make the right stand will win over the netizen voters. After all, we are a young population and the internet is occupied by us.

* * * 

Other opinions: 

• Electronic Frontier Foundation's take. "In the Philippines, where the Internet is free from censorship, President Benigno Aquino III recently signed into law the Cybercrime Prevention Act of 2012, a troubling development for free expression."
• Forbes Magazine opinion. "Now, as someone who has been the target of many a vicious attack from commenters or forum posters, I can understand frustration with the nature of online anonymous criticism. But to actually try to make such a thing illegal? You wade into dangerous waters that anything resembling freedom of speech will likely drown in. " 

* * * 

Wrote this previously in a Facebook status -- because I couldn't see where my link to Notes went after FB's overhaul. Posting it here, with some amplifications after the initial comments and questions from friends.

Remembering Tang Ben

I'm interrupting the normal IT stuff in this blog to remember my father, Tang Ben, who unexpectedly passed away last September. I'm doing this because some of his grandkids never got to meet and know how kind, funny, and inventive Lolo Ben was.

Tang Ben knew how to cook. He had several killer dishes in his repertoire, but my favorite (my wife's too), was his asadong manuk. Asadong manuk was reserved for special days -- fiestas and birthdays. He would marinate the chicken in toyo and kalamunding for a day. Then, the chicken would go through an elaborate process of sauteeing and braising and frying. 

Whenever he served it, the dish never lasted long on the table. So he would set aside a half-chicken or more for me and Data. 

Tang Ben said he learned to cook when he worked in his aunts' carenderia. I think what really distinguished his cooking style was his inventiveness. He would experiment a lot -- sometimes with undesirable results. We'd be honest with him when this happened, and he always took it in stride. His strength was learning from his experiments and doing better every time.

We used to have long lunches and dinner, with the elders lingering at the table, telling all sorts of stories. "Peace time" stories were a hodge-podge of prewar and, confusingly, war stories. One of the favorite recurring stories then was about the old toilets, which were elevated outhouses with a hole on the floor and a long stick. The stick's purpose was to push away the pig who would wait downstairs for your number 2 (gross!).  

When Tang Ben was going to school at Calulut as a kid, so he told, whenever it would rain, he had no other place to seek shelter so he would crawl into one of the open niches in the cemetery along the way.  Tang Ben used this story to explain why he was sensitive to spirits (and he had firsthand ghost stories to tell!).

All lunches and dinners would always have a round of jokes or real-life funny stories. But those are for future blog entries.

One of my earliest memories as a child were of him using a trick to make me go to bed. He would lift a small part of the kulambo, making it look like a tent, and would tell me, "Camping! Camping! Quick!" And I would rush to bed, crawling inside the hole.

Project Delta: web-based but standalone app

The vision for Project Delta (mentioned in this previous blog entry) is that it will be used by physicians who are also digital nomads (ie, sometimes they're working online, sometimes they're not). This means:

• Delta needs to act as a standalone app when the doctor is disconnected from the network.
• When there is a network connection, Delta acts as a web application that syncs its data over the network.

It's also important to state here that we decided this app would be built on RoR (Ruby on Rails). We want to benefit from the RoR's strength for supporting rapid and flexible development. But RoR brings one disadvantage -- it's still a pain to install on Windows (and some of our intended users may be Windows users).

Mulling these over, I formed early ideas about the technical solution. But I am aware that others are much better and more experienced than me on this one, so I asked my panel of technical advisors about this.

Here's the summary, which is good enough to go on:

• For a quick installer for Windows, try RailsFTW by Brian Bibat. 
• Stack Overflow discussion thread about distributing RoR apps as standalone apps.
• Essential tools for Mac Ruby developers is self-explanatory. Some of the tools are not that important in my opinion, but it's a good list to start.

If you know a good solution for our technical issues and requirements, do send me a comment. Will highly appreciate it. 

5 Important benefits of Scrum and Agile

I have been helping a small-sized government agency (let's call it Agency Pi) to improve its IT services. Management wanted the IT section to be more responsive to the information needs of the agency, which feeds into policy formulation which in turn helps create more intelligent decisions. That of course is the vision.

The IT section was not built for that new vision, so I was tapped to help make the transition. I decided to introduce Scrum and Agile software development methodologies to the organization. Note that we did not just introduce Scrum to the IT section, but to the whole organization. The way we introduced Scrum is a separate story in itself, so I'll leave this for another blog entry.

For this blog entry, I want to write about the benefits Agency Pi gained from this change effort. We could sum them up to the following:

1. More customer-centered development. 

Scrum puts the customer (represented by the Product Owner) in the center of development. Programmers often snubs customers, treating them as clueless clients. The important change here was to convince everyone that the Product Owner (PO) should have more involvement and a strong voice in defining the product, the development timeline and the team priorities. 

This is contradictory to traditional project management principles, where it's mostly the PM who decides on the schedule and priorities (in "consultation" with the customer).

2. Improved customer involvement in product development. 

The IT section catered to internal customers, usually heads of departments in Agency Pi who were dissatisfied at the inflexibility of the IT staff in responding to change requests. In my observations of the organization, it became obvious that Pi had what I call managementitis.

Managementitis assumes that software developers can easily predict what the customers want and could build a solution with minimal customer collaboration. Managementitis is a flavor of delegation by abdication. That is, after giving instructions, customers can forget about the project and come back at deadline time to see the magical software that the team developed without customer involvement.

To change this mindset, we enforce the requirement that customers should assign a "full-time" product owner (PO) in the project. This PO will make important decisions that contribute to the design of the software. We also require the customers to attend the regular product reviews (we made some mistakes here, but that's for another blog) so there are no surprises.

3. Team mindset that embraces change. 

A more difficult challenge was convincing the programmers to welcome changes requested by customers. The developers are used to the waterfall approach -- hammer out all the details in the design phase, get signoff, and build the software. 

In my experience, this way of building software is inflexible, resulting to programmers who stop listening to customer change requests, and high customer dissatisfaction. I still see this tendency in the programmers, but when I see it resurfacing, I just repeat the message that "Let's accept the reality that our customers will always want to change a feature especially because what we're creating here is new to most of us."

4. More balanced leverage for negotiation between customers and developers. 

The old mindset at Agency Pi promoted an adversarial relationship between customer and developer. For example, customers tended to demand unrealistic deadlines and then wanted programmers to commit and be accountable for the results. Sample dialogue: 

Manager/customer: "I want this very important database system to support our Program Such-and-Such. I don't know what its features are yet, but I need it next week. You need to bear in mind that since we don't know its features, you should be prepared for changing requirements. But I still need it next week." 

Programmer: "Uhm, okay. (Scratching head and wanting to jump out of window.)

You could see where the dialogue above would be headed (hint: "Hell."). And this often happened at Agency Pi. Using Scrum, we started advocating for more customer involvement. More customer involvement through the PO meant giving the PO more insight into the complexity of development. We made the customers see that development was about managing time, effort, cost and quality. Managing time is of course an illusion -- so we simply adjust cost, effort and quality based on the time we have. This is a key paradigm shift that customers and even developers need to understand in Scrum.

To do this, we repeated key messages like "We are now more open to change requests, but please recognize that these changes impact on time and effort" and "We will respond to that request, by adding it to the next sprint -- we assume that you want this prioritized?" or variations of these messages. Many developers hate to repeat themselves. But when you're dealing with deeply embedded organizational behavior, repetition helps.

Moreover, the Scrum approach gives the power of making product decisions back to the customer/PO. This often produces amazing results. Customers are more conscientious in making change requests and are more willing to bargain one feature for a more important change request.   

5. Improved customer satisfaction.

Of course, doing all of the above have resulted to better relationships with the customers, and a better grasp of the internal development processes that are happening on the side of the programmers and on the side of customers. 

There is now also more dialog happening in the development team, which by the way now includes the customer as part of its members. The programmers feel more empowered because it is clear to them that their participation in decisions is only up to the technical aspect. Issues on prioritization and scheduling are left for the PO to decide.

7 things I like about School for Startups (Book Review)

As an entrepreneur and a teacher about entrepreneurship and business, I've read many books about  starting a business. School for Startups stands out among the rest of them. What I like about the book:

1. It emphasizes taking action immediately on your business ideas.
2. The authors promote the contrarian beliefs that (a) you don't need to take big risks to be an entrepreneur, (b) you don't need lots of money to start a business, (c) you don't need a big or cool or original idea to start a successful business. Based on my experience, I agree on all of these.
3. The book contains many real-life examples of people who started their own businesses with very little capital and using simple, even copied, business ideas. 
4. These examples inspire the reader to take action, as in, now.
5. The book eschews business plans and instead recommends to use your time more effectively by just trying to sell something and letting the market decide whether you've got a good business.
6. The authors have real startup experience.
7. What's more, they have taught classes that helped students to start new businesses. (In one class, they set up a business importing chairs from Pakistan and made a health profit out of that one-time business.)

The underlying themes of School for Startups is to take action, start small and start simply, persist and learn as you move along. If you've been mulling over starting your own business, this is the book I would recommend you read.

Highly Recommended:
School for Startups is by Jim Beach, Chris Hanks and David Beasley. Check it out at Amazon.

Two health information systems: Mu and Delta

I am excited to report that my team and I are slowly building a portfolio of health information systems. Our first major project in this growing sector was Project Mu (a codename, of course). Technically, Mu is a clinic information system -- it helps manage a chain of clinics with branches spread all over the Philippines. 

Mu contains software modules to record patient demographics and health records, including diagnoses and treatment histories. It also has a module to generate price quotations and record payments (stopping short of generating receipts -- the client recognized that we weren't building a POS or point of sale system). Mu's application and database are web-based and accessible through a private cloud. Mu was delivered and deployed last year and we are now in the process of enhancing it, based on customer requests. 

Our team is proud of Mu because our clients are happy with the product (in fact, they've been giving us repeat business). We also celebrate the fact that we completed this app despite overwhelming obstacles attached to the client's circumstances (details of which I could not reveal here -- suffice it to say we overcame great odds and still came out with a good product).

And now we have two more forays into health information systems. Of the two, I'd like to write here about Project Delta. The Delta system is now in its inception stage. Like Mu, Delta will contain modules for storing and retrieving patient data, recording doctor's notes, and generating treatment plans and recommendations for patients. I am not yet at liberty to reveal details, but I promise to blog about it as soon as I get clearance from my clients, who are doctor-specialists.

What is exciting about Delta is that it will support physician-specialists who are relatively mobile -- that is, doctors who run their practice in various clinics and hospitals in different locations. Imagine Dr. M. who brings a laptop to the clinic. When she sees a patient, Dr. M. records her findings in Delta running in her laptop. If there's an internet connection, the app will update the patient information stored in a cloud database server. There may also be an app for iPad or an Android tablet that would allow a doctor to view patient records and record some notes using that mobile device. 

Of course, this is the product vision for Delta. We won't necessarily deliver all of these at the start. Our cooperative customers understand the importance of iterative development and starting with simple features (a rarity in the IT industry). So our first sprint will be just about the basic patient data and the important data entry forms.

By the way, the second exciting feature of Delta is that we are developing this entirely from a scrum approach. Even more exciting is that we are using online tools to improve our virtual collaboration, not just for the development team, but also with our clients who, as I've mentioned, are mobile physicians. I'll be blogging more about the approaches and tools we're using to start up Project Delta.