How to integrate CloudKit into your App Today


Overview

Welcome to the second of a three-part series on iOS 8, where we will dive into the exciting world of CloudKit, after introducing you to HealthKit in our previous article.

CloudKit is Apple’s attempt at providing an answer to Dropbox, Parse, and the other cloud-based solutions, decoupling the developer’s attention from having to deal with server-side application loginc, and instead focus on what they do best, client-side development.

Exposing the standard cloud interfaces, of Authenticationpublic databases and asset storage, and most importantly, it’s free, with supposedly generous bandwidth and storagel imits. How much storage you ask? 10TB of database storage and 1PB of asset storage.

Benefits of product/service to developer, customer

Whilst there is no shortage of third-party options out there, and whilst Apple had come to the party quite late, Apple brings to the table a really strong and secure solution package, that distinguishes between public and private data, with the latter not visible to anyone besids the client.

If you only plan on releasing an iOS-only app, Apple’s CloudKit is certainly worth looking at, and even if you do decide on moving on to hosting your own server-side solution, having an initial Minimum Viable Product through CloudKit is a viable proposition.

Another benefit of opting for CloudKit lies in it’s simplistic barrier-to-use, and by simply registering in the iOS Developer Program you can get started with CloudKit. You don’t need to install any third-party frameworks, and trust on the consistency and clout Apple has in maintaining it’s data servers.

Users who are logged in on their devices to iCloud area already logged in to CloudKit, so you don’t even have to bother with fancy login and registration screens, providing quite a seamless experience.

To read my full article, go to http://www.programmableweb.com/news/how-to-integrate-cloudkit-your-app-today/how-to/2014/10/29

What I Learned Negotiating With Steve Jobs


An interesting article I stumbled upon that provides a bit of an insight into negotiations.  Enjoy Heidi Roizen’s piece in her dealings with Steve, below; (source: http://heidiroizen.tumblr.com/post/80368150370/what-i-learned-negotiating-with-steve-jobs)

Fresh out of Stanford Business School, I started a software company, T/Maker, with my brother Peter. He was the software architect and I was, well, everything else. Our little company was among the first to ship software for the Macintosh, and we developed a positive reputation among the members of the nascent developer community, which led us to expanding our business by publishing software for other independent developers. Two of our developers, Randy Adams and William Parkhurst, went to work for Steve Jobs at his new company, NeXT, and that’s how I ended up head to head with Steve Jobs. 

Turns out, Steve had a problem and Randy and William thought I could be the solution. Steve had done an “acquihire” of the developers who had written the Mac word processor MacAuthor. In order to make the deal economics work, Steve had promised to publish MacAuthor and pay royalties to the developers. But now, with the world’s attention on his new startup, how would it look to have NeXT’s first product be a word processor for the Mac?  Randy and William suggested to Steve that if I were to be the publisher, the problem would be solved.  Steve liked the idea, and invited me in to talk about it.

My first meeting with Steve lasted well over an hour. He grilled me about packaging, channels, distribution, product positioning and the like. I must have passed the test, as he invited me back to negotiate a publishing deal. I spent the next three weeks preparing detailed timelines, package mockups and drafting a very specific contract based on our experience with the other developers we had already published.

On the appointed day, after waiting in the lobby for 45 minutes (this, I would come to learn, was par for the course for meetings with Steve), I was called up to Steve’s cubicle. I remember to this day how completely nervous I felt. But I had my contract in hand and I knew my numbers cold.

Shortly into my pitch, Steve took the contract from me and scanned down to the key term, the royalty rate. I had pitched 15%, our standard. Steve pointed at it and said,

“15%? That is ridiculous. I want 50%.”

I was stunned. There was no way I could run my business giving him 50% of my product revenues. I started to defend myself, stammering about the economics of my side of the business. He tore up the contract and handed me the pieces. “Come back at 50%, or don’t come back,” he said.

I slogged down to my car feeling like I had just blown the biggest deal of my life.  Lucky for me, someone had followed me out.

Dan’l Lewin, one of the NeXT co-founders, had a cubicle within earshot of Steve (actually, at that time, every employee was within earshot of Steve.) Dan’l had been working with me in background over the last few weeks and we’d developed a good relationship. If this deal did not get done, it was going to end up being his job to find someone else, so he really wanted me to get the business. Dan’l put his arm around my shoulder, and said one sentence, which I will never forget.

“Make it look like fifty percent,” he said.  

“But I can’t afford to pay fifty percent!” I complained.

“I get that you can’t afford to pay fifty percent of gross,” said Dan’l, “but Steve wants to see 50% on that contract. So figure out a way to make a contract that you can live with that also says 50% at the bottom.”

That’s when the light bulb came on.

For Steve, this contract wasn’t that important to the future of NeXT. While we would go on to pay Next about $5 million in royalties over the life of the contract, and were their first source of revenue, we were not central to his mission (Steve later teased me that he made more money collecting interest on his bank account than he made from me.). However, he had promised the developers 50%, he had said the number within earshot of everyone, and he wanted to be able to tell everyone he got what he wanted.

I had to make the business make sense financially. I just needed to make my 15% look like his 50%.

To do so, I reduced the nut to split by first deducting the cost of packaging, of technical support, the salaries for some developers on my side of the business to implement fixes, and when I still couldn’t get the math to pencil out, I added a $6 per unit ‘handling fee’ thanks to some inspiration from an infomercial on the Home Shopping Network.   My new “Hollywood net” number read 50%, but fully-loaded it was pretty close to the 15% of gross I needed to make the deal work.  Magic!

Steve was happy with his 50% contract and the deal got inked.   T/Maker became the publisher of the renamed WriteNow word processor, which went on to decent success, garnering 25% of the Mac word processing market during its multi-year run and making many millions of dollars for both NeXT and T/Maker.  And, I went on to work with Steve for many years – but that is a different story! 

Here is what I learned:

Know your numbers:  I knew my numbers, what I could make money on, and what I could not.  I understood which dials I could turn to make the deal work for me and for the other side.

Don’t let the bright lights blind you:  I did not do a bad deal just because I was dealing with a high-profile person, no matter how tempting the glory was at the time.   In my current life as a VC I can’t tell you how many times the entrepreneur wants to do a deal simply because it would be a great press release. Don’t do it!

Have allies inside the other organization:  During my preparation process I had gotten to know Dan’l Lewin quite well, and he likewise got to know me as a proactive, thoughtful, ethical person that he wanted to do business with.  Without him working the background this deal never would have gotten done.  For every deal, it is important to cultivate other relationships inside the firm who can help you with perspective and work behind the scenes to move you into the yes position.

Understand the needs of the other person:  In business school, I learned that negotiation is “the process of finding the maximal intersection of mutual need.” At first I did not understand Steve’s needs, but when I reflected on it after being banished from his cubicle, I came to realize that this deal was not important to NeXT in terms of dollars or future, but important for Steve to get the 50% he promised his developers.  Once I got that, it was relatively easy to come up with a contract that met his needs but also met mine.  People are not often as clear as Steve was — it sometimes takes extra work and lots of iterative communications to find out what the other person truly wants, but the process creates better, more sustainable deals.

Estimating Team Project Velocity in an Agile Project, based on 3 factors


A daunting task of project management, during the project release planning stage, is estimating how long a project would take to complete, which heavily depends on how long it will take developers and testers to complete story points. Working out the iteration capacity is what is called team project velocity

Velocity is a capacity planning tool… the act of measuring said velocity. The velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project.

— Wikipedia (http://en.wikipedia.org/wiki/Velocity_(software_development))

There are three ways in which you can estimate team project velocity,  with historical data, through continuous iteration adjustment, and forward estimation.  

Historical Data

Whether you are able to pre-determine velocity or not depends on how well you know your team. If you have historical data, and granted, you will need to have all variables consistent from previous projects when you go into this one, such as the same team composition, technology and nature of project, and whether the method of how the units of work were estimated previously remains the same.  Regardless of which factor you choose, it’s best to estimate velocity in terms of range rather than an absolute value.

Continuous Iteration Adjustment

When you don’t have any historical information to lean on (and even if you do, sometimes it’s better to start with new and more accurate data), you can plan your project so that the first one or two iterations, prior to providing the project stakeholders with a firmer project duration estimate. You can put in a few stories into initial two iterations, observe how the team progresses, which will not give you the benefit of understanding the team velocity, but also hone in on your story-board complex value estimation.

If you are able to hold off on giving an estimate and allow the project to commence it’s first two iterations, it will yield long-term benefits for your project fore-casting later on.

In true agile spirit, you can continuously evaluate the team velocity per-iteration and adjust accordingly. Remember, it’s best to estimate in a range as opposed to absolute value, so you can see from iteration one a certain range is associated for the velocity, and if the team maintains a continuous effort and result, you gain some consistency in your estimation. If the team struggles to maintain it’s initial value, you may have over-estimated the velocity range, and so forth.

Forward Estimation

The final factor in project velocity estimation is Forward Estimation, where we don’t have historical data, nor the afforded ability to run a few iterations to calibrate our velocity range estimation. This is the riskiest proposition of the three, according to Mike Cohn in Agile Planning and Estimating

Estimating the number of hours worked involves working precisely how many hours of the day the resource can be devoted to this project.  This is expressed as a percentage (i.e 70% of the work day).

You then multiply the the number of hours available each day(like 8 hours) by the number of people on the team. You then multiply that by the number of days in the iteration, and you will get your final number of hours available for the 10-day (two week) iteration.


Screenshot 2014-11-04 14.23.02.pngScreenshot 2014-11-04 14.23.02.png

1. Estimate the number of hours that each person will be available to work on the project each day.

2. Determine the total number of hours that will be spent on the project dur- ing the iteration.

3. Arbitrarily and somewhat randomly select stories, and expand them into their constituent tasks. Repeat until you have identified enough tasks to fill the number of hours in the iteration.

4. Convert the velocity determined in the preceding step into a range.

— Mike Cohn – Agile Planning and Estimating

You then expand the story points, fitting as many as you can whilst ensuring it doesn’t exceed the total number of hours you just worked out for the 10-day iteration, breaking down stories into tasks and filling out the iteration assignment. As Cohn then suggestions, you add up the story points and then you can work out what the probably velocity of the team is. So, let’s say we worked out 240 hours within the 10-day period as our capacity, we worked out story points that would fit in 221-hours, we work out the complex value of each point, we would get a value, let’s say of 25.