Plumbee engineering

London Mobile Forum 3.0

| Comments

In February a few Plumbee engineers had the chance to attend the London Mobile Forum organised by Facebook. This conference has been running for three years, and is one of our favourite events in the mobile community.

This year the event took place in the Ace Hotel Shoreditch, in the heart of London’s Silicon Roundabout hub, where many tech companies are placed.

The Mobile London Forum is a one-day event with a morning and afternoon session. In each, five facilitators start with a short presentation on their topic followed by discussions in separate groups, which the attendees are free to join. The facilitators return to stage for a Q&A session in which everyone has the chance to participate.

This year the list of topics was the following:

  • Architecting apps: Can we write better code by planning ahead? UML FTW? - Paul Ardeleanu
  • Paper Prototyping: Can we speed up our product cycle by using old fashioned tools? - David Gonzalez
  • Time Well Spent: Which parts of our apps belong on watches and other wearables? - Joe Hughes
  • Business Logic: Where should you process your data, on the device or in the cloud? - Matt Sullivan
  • Developer X: What can we do to make developer experience more productive and enjoyable? - Chris Jenkins
  • Technical Debt: When is the right time to invest in improving old architectures? - Iordanis Giannakakis
  • Structuring code: How can we structure our projects and dependencies to make it easier to build products? - Olivia Bishop
  • Battery Life: When should we invest in optimizing for battery life? - Chris Anderson
  • Accessibility: How far should we go in supporting accessibility features in our apps? - Sally Shepard
  • Indie Apps: How can an independent developer survive in the App Store? - Lee Armstrong

We attended the four panels with the topics we found most interesting from Plumbee’s point of view. The conversation was very productive, we learned many things from other engineers’ experiences and we hope they found our participation useful. Here’s a brief list of things we learned:

Structuring code dependencies:

  • There are two schools of thought when it comes to managing internal dependencies: use version numbers or work exclusively with the latest version. At Plumbee we prefer the latter.
  • Reconciling and maintaining different version numbers manually is hard, but many organisations feel that they must do this.
  • Working with the latest version (or HEAD version) of a dependency is a common practice in agile environments with frequent release cycles.
  • There were a few options discussed to reduce build time. Among them:
    • Use smaller, more independent modules. This will reduce the compilation frequency of unchanged code, but doesn’t necessarily reduce the build time of the entire system
    • Hardware solution: faster, better connected machines,..
    • Use cache strategies for artifacts.

Architecting mobile apps

  • The main question proposed by the conductor of the session was: ’Should we plan the architecture of our application more in advance?’ There were very different opinions, since the profile of the attendees’ companies wasn’t uniform. For some engineers, early planning is key to ensure the success of the project. In other cases (such as Plumbee), development starts with a small set of requirements, so only a limited amount of architectural decisions can be taken at that stage.
  • There was a discussion about documentation and its maintenance. Very divergent opinions: some companies make a lot of effort to keep documentation up to date. In other situations it just doesn’t provide enough value for the amount of resources dedicated to the task.
  • We also discussed the frequently-revisited topic of javadoc-style comments. Again, opposite points of view: it’s seen as a requirement for some organisations and as a negative code smell in others.

Technical Debt: When is the right time to invest in improving old architectures?

Iordanis introduced the topic by asking the group to come up with a definition of technical debt. We all shared how technical debt affected our day-to-day jobs, and soon realised we all had the same issues: tech debt makes our teams slower.

The four topics we covered were quite interconnected and included technical and non-technical facets:

  • Measuring productivity
  • Explaining technical debt to non-technical stakeholders
  • Prioritising
  • Planning

The main focus was around measuring productivity. Considering just the code doesn’t give you the full picture, moreover there are many factors that may affect people’s productivity apart from tech debt. At the same time metrics are the main selling point to start fighting technical debt, so we identified some potential areas to consider in both the technical and non-technical spheres:

  • amount and frequency of bugs/regressions
  • static analysis
  • team frustration
  • (significantly) wrong estimates

While talking about the importance of metrics we found ourselves touching also on how to explain technical debt to non-technical stakeholders. Specifically, we started talking about mutual trust. Listening to others explain problems they had with this, we were proud to say that our culture at Plumbee is built upon mutual trust between engineers and all other stakeholders. We talked about how professional behavior can be a trust catalyst, and how empowering engineers to choose the right time to work on a certain story makes them more responsible.

Prioritising and planning divided the group into two factions:

  • One group would create a set of refactoring stories, and would prioritise them all together to make the tech debt disappear all at once. However, with this technique the team wouldn’t deliver value to the product during this period, because they would be busy “fixing stuff”.

  • The other group would agree on a plan as well, but they would tackle tech debt as they go. Their rule is: leave your code better than how you found it. The pro and con of this approach is the same point: tech debt is not tackled all at once but over time.

Developer X: What can we do to make developer experience more productive and enjoyable?

In the afternoon panel Chris posed us this question: how can we make devs’ lives better? From the very beginning the major point of frustration appeared to be 3rd party libraries. The main points we raised were:

  • discoverability of libraries
  • documentation and examples
  • aliveness
  • quality vs hype

We all agreed that, independently of the programming language we use, it’s usually very difficult to find good libraries. Many possible sources were mentioned, from maven central to npm repositories, from github to sourceforge, but having such a huge range of different libraries makes it difficult to hunt for a good one. This led to the topic of “What is a good library?, What should we look for? What are the most frustrating points?”

Lack of documentation was identified to be the king of all the issues. Many examples of bad documentation were raised: lack of examples, or examples that don’t even compile, or lack of class diagrams. We shared what we do at Plumbee: we provide “executable documentation” in the form of tests, so if you want to use a library you have usecases that are always up to date.

Aliveness was another frustration generator: you want a library to be constantly updated with bugfixes and latest APIs compliance (in case of a client library for some web APIs for instance). Last but not least you want the maintainers of the library to respond quickly to a pull request.

Another good point of the discussion was around quality versus hype of a library. Whenever a language\stack\framework becomes “cool” a lot of new libraries tend to spawn around it, and many of them as shooting stars that don’t last very long. We all agreed that we need to evaluate all of these other points in order to evaluate how good a library is.

Conclusion

We had the opportunity to discuss common problems with top level engineers working for the top players of many different industries. The average level of discussion was very high and it was interesting to compare our workflows and approaches with those of others, even if there weren’t many companies from the game industry represented.

For Plumbee the London Mobile Forum still represents a big event not to be missed for keeping in touch with the key people of the other key companies on the tech scene.

And just like last year, we’re already looking forward to the next London Mobile Forum.

- Miguel Serrano, Piergiorgio Niero

Comments