If you are going to fail, fail fast.

On my return flight from SFO earlier this month I read the “The Lean Startup” book. Its advice on short feedback loop, validated learning and pivot resonated with me. As I thought more about the topic I realized how a lot of teams that practice Scrum/Agile, follow it only for delivering the specified requirements.

What is not included in many teams Scrum/Agile loop are requirements. What if a product was delivered on time, with specified features and its quality was superb-and it was a failure. It doesn’t matter whether Scrum or Agile was used to deliver a product that didn’t have the features the market wanted.

We need to accept that Product Managers are fallible like everyone else.  Even with all the market research, competitive analysis, domain knowledge,  and out of the box thinking too many products fail. We need PMs to be challenged and assume that the specified requirements are wrong-until they are validated by Mr. Market.
In software testing we know the value of failing fast. Fail fast should also be applied to other aspects to business. With fail fast all requirements would be validated by Product Managers before they are actually built and delivered.

The challenge is how we get Mr. Market to validate requirements that won’t be released in another few years. That is a topic for another day-while I mull over it.

Five Security Enhancements to Android

Five Security Enhancements to Android.

Kudos to the Android security team for Bouncer.  Hopefully the below features are on your radar and will be delivered soon.

1. Many android app request permissions upon install. Here are a few permissions: being able to read your contact list, send sms or send text messages on your behalf, to reading network state . Often when I read the permissions an app requests , I question if it really needs a given permission. Often, I am tempted to grant the app only some of the permissions and deny other permissions. Alas, Android does not allow selective permission grants.  My only choice is to either not install the app or grant the app all the permissions it requested and suffer.

2. Stop malware infected apps from getting into the marketplace and run all the necessary security checks (white/blacklisting/heuristics) when an app is downloaded to a user's device. The android marketplace needs to further improve developer validation and further limit nefarious apps from getting into the marketplace. Stronger checks, audit and continual checks of the both the app and the developers will help. 

3. Simplify permissions: The model security model replies on Java security model and sandboxing. This model is not suitable for the problem at hand. The permissions encode the resource being protected and the action along with the permission name. The security permissions are runtime permissions are consequently developers don't write defensive code to deal with the scenario where the permissions are not granted to the app. They simply rely on the default runtime failure. With defensive programming, developers will gracefully code for the cases when the functionality is not available because of denied permissions. 

4. Make permissions grant one time and allow permission grants to expire. Often app request permissions that I am hesitant to grant. However I might be ok to grant that permission for the next 1/2 hour or just this once. Just like in real life, I should be able to grant permission just this once, and expire them.

5. App notifications: Many apps send notifications on updates. The app specific settings often include controls for these notifications. I have seen some apps where the control for app specific notification is either missing or inadequately offered in the app specific applications.  A feature to control all notifications, available as the top level android settings would be very useful.

  

While #5 isn't a security feature, I couldn't resist listing it here since it has been my bete noire of late.

There are clouds

When you look at the sky do you see a cloud? I bet more often than not you see clouds. And this precisely is the problem with many of the cloud providers. They exist in isolation, and often do not help companies deploying to multiple clouds solve many problems (especially in the security area) effectively.

Let’s take an example of a hypothetical XYZ Corporation. XYZ decides to leverage a few SaaS providers for its need in the area of Human Capital Management (HCM), Finance & Payroll, and Customer Relationship Management (CRM)-XYZ signs up with three different cloud based providers.

While all looks good on the surface, there are problems.

Let's walk down the triad of AAA (Authentication, Authorization, and Audit) issues with the above setup.

1. Authentication: Where is the source of Identity hosted? Is it hosted at XYZ or is it hosted at a Cloud Provider?
2. How does the cloud provider trust an external source of Identity
3. How does XYX securely provide its users/employees/contractor to the hosted cloud provider and continue to keep its users in sync with the cloud provider.

3. Since we are talking multiple SaaS providers, what if a user John Doe is represented in various ways in the SaaS provider’s identity store. Representation from jdoe, john.doe, and jodoe has all been in corporate LDAP for years. Now imagine trying to reconcile John Doe across SaaS providers.

Typically SaaS (Cloud) providers are not aware of other cloud providers and they can’t offer services that leverage other providers.

For example if there was a business need to ensure the principle of “separation of duties” continued to be enforced when the John Doe is a user in HCM and Finance & Payroll offered by different vendors. How does one ensure that the HCM and Payroll system do not allow John Doe to both change his pay grade (an HCM function) and release payment (a Finance and Payroll feature ) on his expenses.

The separation of clouds causes problems in Authorization and Audit too. For example how does one audit that John Doe did not access HCM function when a given CRM function was accessed.

There are a few ways to solve this problem:

1. If it hurts, don't it – don’t sign up with multiple cloud providers - just kidding.
2. Put a level of indirection, a service like apigee may help
3. Standardize – Cloud Interoperability standard under development and JavaEE 7 will help, but a lot more is needed.
4. Cloud vendors to externalize some of their data to allow third party reconciliation, audit, authorization checks etc.

This is a hard problem, none of the solutions are easy, without side effects, or will work for everyone.

Do you face this problem? What are other ways to address this issue? Is there any effort to address this issue?

Why Facebook's hacker way will change

http://www.msnbc.msn.com/id/46263927/ns/technology_and_science-tech_and_gadgets/t/facebook-hacker-way-way-life/

My take on this:

Hacking and moving fast is to facebook's advantage right now-no doubt. Hacking is ok, when there is little legacy code. Most interaction with FB services today is by humans, who are smart enough to deal with changes when the web interface changes.

As more machines(programs/automation) interact with FB and as it matures, FB will face the same inevitable slow down that other once fast growing companies have faced.

Comments, thoughts welcome.