The Dropbox journey to static type checking with Python

Type Annotation is a feature that allows Python to maintain it’s dynamic typing and enable option static typing in the same code base. With the arrival of Python 3.5, the language implemented PEP 484, that describes a syntax to annotate code with type hints. Dropbox took a journey to leverage this option on 4 million lines of code for better quality. Here are their experiences.

Combined count of type annotated lines of code.
Type annotation

Dropbox is a big user of Python. It’s our most widely used language both for backend services and the desktop client app (we are also heavy users of Go, TypeScript, and Rust).

Source: Our journey to type checking 4 million lines of Python | Dropbox Tech Blog

`Keep Talkin’ Larry’: Amazon Is Close to Tossing Oracle Software – Bloomberg

It’s a huge effort considering the scale of the project and the relevance of customer data for Amazon. Given their cloud business and it’s maturity – AWS is more than 10 years old by now and leading the pack – this move seems overdue. Inc. has taken another step toward eliminating software from Oracle Corp. that has long helped the e-commerce giant run its retail business.

Source: `Keep Talkin’ Larry’: Amazon Is Close to Tossing Oracle Software – Bloomberg

eMail. Still.

Year 2015. Still eMail is the predominant means of communication. Everybody hates it, most companies make an effort to ban it. Atos wanted to go email free, Telekom shuts off their servers, Daimler even deletes email for people on vacation. Even I receive emails, saying “I need this, but I cannot answer”, quoting the “email free day policy”. Despite all effort, nobody succeeds.

Why? Unclear. While I think email should be banned myself, I have difficulties offering a better option. But I develop a feeling for why this is happening. This morning somebody mentioned he’ll be posting into a channel. That company claims to simplify communication, make teamwork less painful and busy, all searchable. As if nobody else tried that. And even if does a good job in what they aim for, they are just another solution.

In my personal, active use are, Pocket, Salesforce chatter. While my company introduces a community, colleagues swear on private Facebook groups or WhatsApp for simplified communication. Not to mention the tools customers and businesspartners are using. Popular among these are Jive, Atlassian Jira, SAP Jam, but not limited, I’ve seen self hosted communities, bug trackers and ticketing tools.

It’s difficult to keep track of all these tools. But they all send notifications through email.

Which tool do you use to communicate?

When a Project dies

When is a project dead?

One question that somebody asked me a few days back keeps me thinking for a while now. Mostly, because it should not have a clear answer. Have you ever had to ask yourself, what to do when your heart-project is at risk to coHantelnme to an end? A project that just dies, has had some serious problems.  A dead-end, that leaves no next steps, along a final decision. In a way that no project goal materialized and no other milestone is reachable? If that is looming to happen, one should consider to check the project plan and answer a couple of questions about the failure. How did all the tasks and work packages depend on each other, that they made an entire project fail? Were some assumptions to optimistic? Was budget too tight? Was the project to ambitious?

The show must go on

KabelDepending on size, no project is barely ever dead. Typically, a project consists of multiple components. Milestones, Tasks, Work-Packages, are just common terms for break downs structures of a project. Such fragments, re-used or re-arranged, can help achieving a modified goal. There are reasons, one or another milestone had difficulties. There are hard facts, like budgets, technical dependencies or necessities, required skills, availability of material or combinations of anything. And there are soft facts, like project team engagement, stakeholder opinion, even hubris may result in milestones not being reached.


A roadblock, identified early enough, allows to realign a project plan, to cope with any trouble, endangering tasks and milestones. In an iterative project approach, the project lead can change a goal, aligning with changing requirements. This way, the project may not reach it’s initially intended goal, but it will not fail in its totality. When a project dies, it will leave bad feelings with the budget owner, with stakeholder and the team. A goal that the team reached, maybe through a more creative approach, will still be a goal reached.

Project Initiation Phase: Business Continuity Plan

  • Secure commitment of departmental leaders who’ll be responsible for implementing the BCP.
  • Pursuade senior management of the importance of having a BCP.
  • Outline a timeline for developing a comprehensive continuity plan.
  • Determine which possible disasters should be covered in the BCP.

Lessons Learneds – Flight Projects Directorate Code 400

Raum- und Mondmissionen sind berühmt für hervorragendes Projektmanagement und so finden sich bei der NASA auch schöne Dokumente zu dem Thema. Besonders schön zu lesen sind die 128. von Jerry Madden, Retired Associate Director (400), niedergeschriebenen Erfahrungen (Lessons Learned) zu lesen. Bezüglich Meetings hat er eine ganze Reihe von Ratschlägen. Einer hat meine ganz besondere Aufmerksamkeit gefunden.

115. Reviews, meetings, and reality have little in common.

Continue reading “Lessons Learneds – Flight Projects Directorate Code 400”

IEEE TMC Workshop on Integrated Project and Quality Management 21.06.2013 Munich

Das Technology Management Council der deutschen Sektion des IEEE veranstaltet am 21. Juni einen Workshop zum Thema “Integrieres Projekt und Qualitätsmanagement“. Ziel des Workshop ist den Zustand der gängigen Methoden zu bestimmen und praktische Beispiele zu liefern, wie Qualitätsmanagement eine schnelle und zuverlässige Daten-Quelle zur Entscheidungsfindung sein kann.

Veranstaltungsort ist die TU München, Arcisstr. 21, München, Raum 0999, Nähe Audimax.

Zeit: 21. Juni 2013, 13:00-18:00

Program als PDF.

Anmeldung über Aminado: IEEE TMC Workshop on Integrated Project and Quality Management 21.06.2013 Munich.