Android Developer Challenge

As many of you already know, Google has launched the Android Developer Challenge. The challenge will give away $10 million dollars in awards for "great" mobile apps built on Google's Android platform. Being the past founder of a mobile applications company, I could not resist. The ideas started flowing and after several brainstorming sessions with a colleague of mine, we came up with our "great" mobile app.

The colleague of mine is Michael Cook, past founder of CookWare, Inc. At this point, all we have are a few requirements documents, a slide show, and a basic Android "hello world, testapp" application. I never expect much when entering challenges like this, but who knows? Wish us luck!

Chasing a Constantly Changing API

I was once waist deep into a development effort when a partnering development team informed us that they where changing their API again. The component we were developing depended on their components for data and capabilities. We had spent time interfacing with their component. We had been careful enough to isolate the interface to their API by creating a façade. This way, the two components were decoupled as much as possible and our component was somewhat isolated from future changes to the partners API.

Our partner was already changing their interface. Not a problem, right? The façade is the only subcomponent affected by this change. An engineer spends a few days reworking it and we move on. It’s that easy right? Well, no.

When this happens you need to make sure you find out why their interface is changing. Ask your partner why this change has been made and why this change was not thought of originally. If they do not have solid reasons for this, then be assured that their API will soon change again and you will find your team spending another couple of days updating the façade. I have seen this situation play out many times. Each time the partner swears that "this is the final change to the API" only to have it change again a week later.

Yes, the façade acts as a buffer to new changes but changing the façade still requires work. And no façade is completely perfect. Some changes might still bleed into other subcomponents causing many other needed changes. In fact, the more you need to update the façade, the greater the chance that the changes will effect all the subcomponents who utilize the façade.

In many situations you have no control over your partner's development practices. It is important to first identify when you may be dealing with an unstable API. Once you have identified the API as unstable, you have a few options other than using up all your resources chasing it.

1. Hold off on making the changes. Wait a few weeks before updating your façade to their latest API. You might also be able to wait till the end of the development effort to make the update. This way, you will skip a few interim API changes. I do have a word of caution on this. Make sure you’re not ignoring their changes; only skip the updates to your code. You want to make sure their changes do not drastically change or remove the needed data or functionalities you require from them. If you wait till the end of development, it might be too late to address the problem.



2. Send you partner your façade. Many partners will pushback on this. They might see this as more work for them, but it might actually save time for both of you. They have a better understanding of the new API and it will be a quicker change for them to make. They already know what changed in the API and why, thus cutting down on cross team meetings and emails.

Make sure you identify their unstable API as a risk to the project as early as possible. Assess your options; determine if your schedule, budget, or scope for the project is at risk. Chasing a changing API never seems like a big deal to the project until it is too late. If it is not identified and dealt with early then it will put the whole project at risk for failure.

Engineers and Marketing Myopia

For those who are new to SheeleyTech, I am a software engineer at heart but more often I “act” as a project manager, product manager, and systems engineer. Because of this, I tend to find myself in a conflict of interest that, if I’m not careful, results in marketing myopia.


“Heads Down” Versus “Heads Up” Roles

The engineer’s role
Engineers love to learn and apply their newly acquired skills. They enjoy building products by using their knowledge, skills, and past experiences to design and create solutions. A large part of this enjoyment is the challenge of creating the product. Sometimes it is the ability to utilize a technology that the engineer has never used before. As a software engineer I can look back at the software products I enjoyed developing the most. There is the first time I used CORBA, or the first time I used RMI, or learning about and developing web services was a great experience. Keeping up with the latest technologies, gaining new skills, and creating products with new tools requires the engineer to focus on the development of the product. I refer to this as a “heads down” responsibility. The idea being that the engineer’s head is facing down at the computer screen writing code or reading about new technologies.

The product manager’s role
When you are in the role of product manager, systems engineer or even the project manager you need to be focused on the customers’ problems. What needs do your customers truly require? Your job is to make sure you are building a product that solves their problems. You need to be what I call “heads up” – researching competing products, learning about the customer, and gaining feedback from the customers. This process does not stop once the development effort of the project begins. Challenges and issues will come up during development. Decisions will be made halfway or ever later into the development of a product that will have a huge impact on the final product. These challenges will come from the development effort (technical issues) as well as from the customers (market issues). Both of these types of challenges need to be addressed with the interests of the customers first.


The Conflict of Interest

When the same person developing the product is the same person who is responsible for making sure the product will meet the customers’ needs, there is a natural conflict of interest. I speak from experience.

Once the development effort starts, the engineer begins to fall in love with his or her product. There has been long hours invested into their development. Thus the engineer has been “heads down” and the focus has been on the product. When technical issues come up, the first reaction is to find the best technical solution to the problem. This is how the engineer wants to solve the problem. Because the product manager and the engineer are the same person, the interest of the customer can get lost. For example, a drill bit engineer (if there is such a thing) will focus on the drill bit. The engineer begins to think that the drill bit is the focus and that the customer needs a really good drill bit. This is wrong. What the customer truly needs is a hole, not a drill bit. Issues need to be addressed by thinking about the need of a hole, not how to make the drill bit better.

If you share roles as an engineer and as a product manager, you need to spend equal time “heads up” as well as “heads down”. If you started your career as an engineer you need to fight your instincts to focus more on the product than the customer. Before dealing with any technical issue, take a step back and think only about the customers’ needs. Review any relative requirements created for the product. Revisit use cases and all the materials you created before you put your head down into the code. Seek out subject matter experts or even contact the customer to get their perspective on the problem. This way, in the end, you will have developed a product the customer needs rather than just a product you enjoyed developing.

Verizon FIOS in the Sky

It’s a quiet Sunday afternoon. I’m reading an operations management textbook on the porch while my wife is off running errands. It’s a typical Sunday afternoon, until I see a plane carrying out a mission overhead. This mission is directed at a small box located approximately 7 feet from where I am sitting. As the plane circles around the route 128 area near my home, I can’t help but think about the battles being fought over my cable box. Only a few months ago I switched from Comcast to RCN. RCN had mailed me a flyer advertising their much lower priced cable TV service. I looked into it and could not see any reason not to switch. $20 a month cheaper, all the same channels, with the addition of DVR. So I switched. RCN won that battle. Now up in the sky is another company jumping into the fight, Verizon.

Verizon FIOS TV aerial advertisement over RT 128

At first I find this all a little odd. Here are large companies all fighting to be the provider of my cable television service. They are spending large sums of money, sending sales people door-to-door letting people know FIOS TV is available in the area, paying for aerial advertisements, setting up FIOS kiosks in the mall, visiting local businesses and giving out FIOS basketballs. I also get flyers in the mail almost daily from Verizon, Comcast, and RCN. Meanwhile, I am just looking out to see who is cheaper.

To me it seems they are all in a market where price is the main differentiator and just over the horizon most content will be available through the internet anyway. I know these companies realize this. So, it really makes me wonder why they are so eager to invest in, and enter into, the cable TV market. Shouldn’t they just be focusing on the internet market? It seems to be a no brainer that in 5 to 6 years from now all broadcasts will be through the internet. Customers will soon only require internet access.

Maybe these companies see cable television as a loss leader for future internet subscriptions. Currently television packages can be bundled with internet service. The fight to be my cable provider might actually be their chance to be my internet provider. When television is available through the internet and consumers realize they no longer need a separate TV service, these companies will not care. We will have become their internet service customers. If I’m right, look for your monthly cable bill to drop and the internet service to increase. This way when you drop your cable service most of your monthly payments will be tied up in your internet service anyway.

As a customer it’s hard to tell what the long-term strategy is for these companies. But enough of this, I need to go checkout the prices for Verizon FIOS TV.

Negotiated Schedules Affect Quality and Deadlines

A while back I was at a meeting with a group of product managers from local software companies. The topic was the process of prioritizing requirements. When the estimated time of development came up, one product manager made the following comment:

“Estimates from engineers are always overestimated. They would want you to think all features would take about three years to develop. You need to negotiate the schedule.” …or something like that.

I could not believe what I was hearing. From my experience, engineers are usually over optimistic with their initial estimates. Only after thoroughly examining each essential step will an engineer increase their approximation to a more reasonable estimate. The fact of the mater is, software development efforts are notorious for delays and schedule overruns. This negotiation process is likely a common cause.

My guess is that this product manager probably feels a sense of accomplishment when the engineering team finally agrees to shorten their schedule. He probably then gets frustrated later when new releases are delayed. Product managers, project managers, program managers, and anyone else who has a say in persuading schedules must realize negotiating a development schedule does not mean the project will finish any earlier. The estimated delivery date is just that, an estimation. The actual delivery date will not be effected by the new estimations. It will not cause engineers to work any faster, it will not reduce the amount of work needed to be completed, and it definitely will not increase the number of hours in the day. The only thing a negotiated schedule will affect is a low quality product or a delayed delivery, and that is not something any manager should feel a sense of accomplishment about.