Pragmatic development for mobile


Dave Mitchell and I collaborated on a talk at MobileCampBoston on March 15. Here are the raw notes I used during the presentation, punctuated with some of Dave's comments.

  • The way we do it at Nellymoser seems to work
  • ~95% success delivering milestones on time
  • >90% success delivering final projects on time
  • Actual, paying customers
  • Actual, paying end users
  • Richard Kasperowski
    • Nellymoser Engineering Manager
    • Mobile since 2003
    • Boston Mobile, etc.
  • Nellymoser
    • Mobile 2.0
    • Rich mobile app's
    • Audio & video on demand
    • Social networking
    • Personalization
Rationale: why we need Agile at Nellymoser
  • Fast projects: 2w to 3 months
  • Make sure we're on course
    • Delivering the right feature set
    • By the right deadline
    • At the right quality level
  • Need cust feedback as we go
  • Need whole project team to understand what's going on and agree on all decisions (or at least hear the decisions)
  • Ultimately: need iteration + communication
  • A way to get hacker culture and biz culture to mix and play well together--how to get hackers to play well with biz folks and meet biz goals
Agile notes
  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
    • 4w per milestone
      • 2w of dev
      • +2w QA
      • interleaved, so deliveries every 2w after M1
    • time block: always done on time
      • Cut content of milestone to make sure we deliver on time
    • After test, deploy on staging server
    • Give customer access
  • Working software is the principal measure of progress
    • so we deliver working handset builds that hit a live server
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication
    • Daily stand-up meetings
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances
  • Dave is curious about the svn tree for our Java and BREW projects--how do we set up the source code trees for BREW ports of Java projects? Dave suggests using JavaGround for Java->BREW porting.
XP values
  • Communication: Yes!
    • Daily stand-ups
      • One of Dave's practices is to publish a weekly stand-up style status report to his customers. Each week, he reports what his team accomplished last week, what the plan to do this week, and a list of issues and announcements.
    • Transparancy
    • Wiki: If it's not in the wiki, it doesn't exist.
    • Jira: If it's not in Jira, it's not an issue.
  • Simplicity: not sure
  • Feedback: Yes!
    • User stories: Yes
      • Examples
        • Alice is a college student and a Foo web user. She wants the Foo experience on her mobile phone.
        • Dan is a Bar content producer. He uses the Nellymoser-supplied content management web site to promote featured content and organize content into categories. He views usage and purchase reports to assist him.
        • Alice is a web site programmer. She has a background in digital design and dynamic web site creation. She is more advanced than a typical DreamWeaver web site designer, but not a hardcore programmer. She understands HTTP GET and POST. XML doesn't scare her because it looks like HTML, and she is willing to learn more about XML document manipulation. SOAP sounds scary to her because she would have to learn in depth programming skills. Alice is building a web site that presents VIP Access (or some other Nellymoser service) to current and prospective end users. Alice's job is to help Bob and Carol. Bob is a VIP Access end user. He visits the VIP Access web site as an alternate and sees a web-specific rendering of the VIP Access mobile service. Bob views artist info, searches for shows, set spref's, etc.
  • Courage: Some
  • Respect: Yes!
XP practices
  • Fine scale feedback
    • Pair programming: No
      • Not mandated
      • HR needs are sometimes 1 role player per project
      • Hard to change company culture
      • (Best code I've ever written was pair-programmed)
    • Planning game: Yes and No
      • Release planning
        • team members review project requirements up front
        • organize milestone feature set and time block deadlines
        • make commitments for themselves that they know they can keep
          • peer pressure--they made commitments to each other
        • my job: remove impediments to their keeping their commitments
      • Iteration planning: team members organically plan iterations with each other
      • Iteration planning: not a formal part of our dev policy or practice
      • Shared responsibility: eng team organizes work, makes commitments, publish commitments time line on wall (and on wiki) (peer pressure)
      • Planning handset support can be a challenge in general
      • Unpredictable: Planning handset support for unreleased handsets is really hard. Don't know what we don't know about early stage, pre-consumer handsets.
      • Unpredictable: carrier certification
    • Test driven development: No
      • Not practiced in custom projects group. Life span of product limits feasibility
      • Rely on it in platform
      • Even though I write code this way, I don't mandate it for my team, because of the nature of the projects
    • Whole team: Yes
      • Team includes customer
      • Either the actual customer, phoning in on daily stand ups
      • Or PM acting on customer's behalf, communicating decisions with customer as we go
      • Sometimes team includes handset manufacturer, e.g. in Korea. Difficult to do daily calls with that much temporal dislocation.
  • Continuous process
    • Continuous integration: Yes
      • repository: svn
      • automated build: CruiseControl + svn + Maven/ant
      • self testing
        • CruiseControl + junit for server side
        • More challenging on client, especially for continuous testing on handsets
        • j2meunit; custom Canvas.keyPressed(), .keyReleased(); SonyEricsson Mobile JUnit, JMUnit
        • DeviceAnywhere
        • Use less experienced or otherwise inexpensive people?
        • We haven't solved this yet.
      • etc.
      • Continuous builds are great, but testing on the real handsets continuously is impossible without a huge budget for test machines
    • Refactoring/Design Improvement: Yes and No
      • Code refactoring is not a mandated policy
      • Design improvement, especially UI improvement, happens organically
    • Small releases: Yes
      • A new release every 2w, running on a customer accessible server, with handset builds delivered to the customer
  • Shared understanding
    • Coding standards: No
      • None mandated
    • Collective code ownership: Yes
      • It's our project, so it's our code
    • Simple design: Yes
      • Base it our the Nelly platform
      • Avoid features that the platform doesn't make easy
    • System metaphor: ?
      • i.e. naming conventions for interfaces and classes
      • We don't mandate coding standards
  • Programmer welfare
    • Sustainable pace: Yes
      • Occasional crunches, but because we build, test, and get feedback as we go, there are fewer crises.
  • Emergent dev vs contractual requirements
  • Internal cust vs external cust
    • How to get external customer fully integrated into team?
    • Share all your dirty laundry--at the risk of giving evidence for breach of contract?
    • Project manager represents external customer, but isn't a perfect replacement
  • Stand-up meetings with remote team members
    • skype, not conf call
    • pay extra for dedicated IP service with guaranteed minimum bandwidth
  • Stand-up meetings by project vs with whole team
    • Too many projects to have one meeting per project without wasting too much time
    • Whole team: challenging to keep it under 15 minutes when team is big
  • User stories vs precise requirements
    • Precise requirements take too long to produce and are wrong, anyway, because nobody realy knows what they ahead of time
    • User stories aren't concrete enough to sign a contract and get paid on
  • Preload handsets + firmware updates: unpredictable
  • ~95% success delivering milestones on time
  • >90% success delivering final projects on time
Help wanted
  • Mobile software developer: Help us build the client side of these services. You are an experienced software engineer with a background in Java ME or BREW. You love conquering technology problems and making things look just right. You think mobile is the future.
  • QA: Help us ensure that we are delivering the best services we can. You are an experienced quality assurance engineer with a background in web services or mobile. You can do it all, from influencing requirements and leading the team to manual testing. You are excited about mobile.


Practice plan #5 (passing)

This is the same as Practice plan #2 (passing), but with different variations and tips for the 8v8 activity.

Theme: Passing

  1. Warm up & stretch
  2. 1v1+1, 2v2+2
  3. Gates passing: Players in pairs
  4. 5 goal game: 4v4+2; or N+1 goal game, with NvN+N/2, where N is the number of players per side
  5. 4-corners passing game
  6. 8v8: Variations: Must pass to all players before shooting; bonus points for back-pass; bonus points for pass back to GK. Tip: GK, take your time, wait for your players to set up, pass to weak side.


Practice plan #4 (skills)

Theme: Skills

  1. Warm up & stretch
  2. Ball handling: Partner tosses ball to your foot/thigh/chest/hand. You control and pass back on 1 or 2 touches. Form a circle with ball tossers in the center, tossing to players on the outside;
  3. Throw in: Review technique, practice with a partner. Tips: If it's crowded, throw in to teammate's head; step onto the field and look for teammate's pass back to you.
  4. 1v1: Dribbler vs defender to small goal. Defender starts half way between attacker and goal. Tips: defender stays between attacker and goal, defender doesn't overcommit.
  5. Slalom: Set up gates that each player dribbles through. How quickly can you dribble through the gates? Tip: Keep the ball close.
  6. 8v8: Bonus points for consecutive passes. Tip: Strong passes; defenders, listen to your GK calling "keeper" or "away;" GK, take your time restarting after you collect the ball, wait for your teammates to be ready for your pass; never pass across your goal area.


Mrs. Gobbles

A wild turkey visited our little side street in Cambridge today, wandering around a bit before settling in someone's side garden. One neighbor suggested it is a female, noting that its plumage is not as extravagant as a male's. Does this Mrs. Gobbles have any relation to Mr. Gobbles?

Click through for more photos.
Posted by Picasa


Practice plan #3 (steal, shield, transition to midfield)

Themes: Steal, shield, transition to midfield

  1. Warm up & stretch
  2. 1v1, 2v2
  3. Shield-steal
  4. Defend & transition: 8v8. Offense attacks the standard goal, defense attacks 2 goals at either side of midfield. Defense gets 1 point for clearing ball to side line, 3 points for moving the ball through either midfield goal. Tips: clear the ball away from the goal, to the sides, avoid giving up a corner kick, defenders start the attack by moving the ball to midfield.
  5. 8v8


Practice plan #2 (passing)

Theme: Passing

  1. Warm up & stretch
  2. 1v1+1, 2v2+2
  3. Gates passing: Players in pairs
  4. 5 goal game: 4v4+2; or N+1 goal game, with NvN+N/2, where N is the number of players per side
  5. 4-corners passing game
  6. 8v8: Bonus points for consecutive passes, wall passes


Practice plan #1 (shooting)

Theme: Shooting

  1. Warm up & stretch
  2. Triangle goal game: 2 goalkeepers
  3. Dual sided goal: Using a coerver goal or setting up a goal in which the goalie must protect both sides of the goal, play 8 against 8. Both teams can score from either side of the goal. If a goalie makes a save she just punts the ball out. Teams must learn to change the point of attack and must give support to each other and communicate constantly. This will help teach teams to make the field big when on offense and to try to compact the field on defense.
  4. 6 goal width and depth game: With cones, make 6 goals on the field. Two at the sidelines, and one in each corner. Divide into two teams. Teams get 1 point for every time they pass the ball through a set of cones (twice in a row doesn't count), and 3 points for scoring on the real goals.
  5. 8v8


MobileCampBoston notes

I attended MobileCampBoston on March 15. It was a great event, well worth my Saturday. Here are my notes.

Tag all content: mobicampbos

Handset secrets: from OEM to consumer

  • Dave Mitchell, ConnectedBits

  • 5 years in mobile app dev

  • His company builds push-to-talk client, burned into ROM, on handsets for AT&T, etc.

  • Biz decision: avoid walled garden by putting yourself within the wall

  • BREW: aggregator handles the TBT for you, Verizon gets 50%, aggregator gets 50%

  • AT&T: too slow, can take 1 year from start of talks to live to consumers

  • Sprint: easiest, most innovative

  • Mobile web: not as good as rich apps

  • 1 billion mobile phones sold last year, 700 million the year before

  • iPhone: great because all users go through iTunes

  • BREW: good, but hard to get through gatekeepers, and your mother is afraid to press the Shopping Cart button.

  • 5 years ago, Dave didn’t see obvious path to get stuff on the market. Started out contracting for other app producers.

  • AT&T gets $10/month for the push to talk service. All the carrier cares about is monthly fees.

  • Wants consumers to have easy friction free way to obtain and use app’s

  • Like iTunes for the idepedent music artist model: put it out for sale; if it’s good, people will buy it.

  • Windows Mobile costs $2-3 per handset. Very expensive in the view of Asian manufacturers, who want $0 or $0.01, and nothing else

  • Android: no system for discovery of app’s. Not easy enough for your mom.

  • Finding app, getting it on your device, paying for it: too much friction.

  • Terminology

    • Terminal: phone, device, handset

    • OEMs, component vendors: Chipset producers. E.g., TI, Seimens,

    • ODMs: original device manufacturers, produce the terminals, assembled from OEM parts. E.g., HTC.

    • Operator: the phone company, carrier. E.g., AT&T.

  • Process

    • Operator spec’s what they want, issues RFP

    • ODMs bid on it

    • Operator and ODM negotiate on price and features. Maybe 10k handsets/month.

    • ODM produces phone, starting with early prototypes

    • Software developer adds app when handset is stable enough

    • Validation testing

      • 3rd party testing, done by carrier’s contractor

      • Carrier internal testing

      • FCC, UL, battery testing, etc.

      • Bug fixes, retesting

    • Ship

    • Typical time span: 9 months

    • Repeat: bug fixes, 2nd release

  • AT&T 13340: document that specifies requirements for all phones

  • Same process for smart phones and feature phones

  • Carrier has complete control over phone’s feature set

  • Kodiak: push to talk server company

  • 28 week test cycle for server hosted in AT&T’s NOC

  • iPhone changed the game: hook it up, and you instantly get 2 new features and 3 bug fixes

  • Phone company loses money when you call for support. Each call costs $20-$70. They lost money on you that month. Risk avoidance!

  • AT&T is very conservative because of the support costs.

  • Marcus (Yankee Group): interested in the impact of open access, especially given 700 MHz spectrum. Open access lobbied by Gogole. Verizon opposed. FCC required open devices, open applications. Anyone who bids in this spectrum must be open. More oriented around open access for devices to the network, not app’s running on the devices, e.g. any GSM device runs on any GSM network.


  • ObjectiveC

    • Category: like mix-in

    • Sort of looks like Lisp: [steveBalmer eat:@”Bacon-Wrapped Twinkies’ withPerson:”BillGates”]

    • Garbage collected, but not on iPhone

  • Tools

    • XCode, Simulator, Interface Builder (not yet available), Instruments

    • Must develop on a Mac

  • Buy a certificate for $99 to be able to deploy to and test on iPhone. Cert is keyed to your iPhone, not all iPhones.

  • CoreLocation framework: returns lat/long of phone. Doesn’t work in Simulator.

  • Frameworks

    • Foundaton

    • UIKit: buttons, etc.

    • Quartz: graphics, points, lines, rect’s, animation

  • HIG: Human Interface Guidelines

  • Well designed app’s

    • Leave things out

    • Sensible defaults and few pref’s

    • Integrate with the platform. Use the built-in stuff, like contacts and UI. Follow platform’s customs.

  • iPhone specific

    • Simulator screen size vs actual screen size: simulator is larger

    • Fingers, not mice

    • Avoid keyboard input

    • Contrast: readability varies in different light conditions

  • Lots of fan discussion, especially around the keyboard


  • Chatted with Matt Gross of ULocate about LBS (location based services) and ULocate's Where platform.
  • Where is an app available on all carriers. It is a widget framework. Developers build widgets that run within Where.


  • Wilson Kerr

  • POI: points of interest

  • TeleAtlas, NavTeq: the two companies that provides all digital maps for all app’s

  • BrandIcons from TeleAtlas

    • Displays, e.g., Shell logo at location of Shell gas stations on personal nav device display

  • Location based advertising: growing to $19.2 billion by 2011

  • POIs are preloaded on nav device, updated occasionally

  • Not trackable: user views it, but no one can track views

  • Advertising that’s not really advertising, like Google: you already qualified yourself by searching for a particular thing; it’s just a search result.

  • Possible future: Google wins 700 MHz spectrum auction, sets up cell coverage nationwide, gives away phones and phone service. How do people make money? Google would make money through paid ads.

  • Converted incremental sales: better than pay-per-click

  • SkyHook Wireless

  • Google uses TeleAtlas for API, NavTeq for consumer maps

  • Comment: on-deck doesn’t matter because soccer moms have never seen it—they’re just discovering SMS.

Pragmatic development for mobile

  • My talk, with Dave Mitchell. I will publish notes soon.

Mobile advertising for developers

  • My talk. I will publish notes soon.


  • Very few people in the community are doing what we are doing at Nellymoser: Mobile 2.0, partnering with giant carriers and media companies, in-app advertising, preload app


Related Posts with Thumbnails