Post Processing: Swift, Kotlin, Team Scaling Fallacy, Levandowski

-

 When I wrote Programming Languages I've Loved and Hated, it came from the heart.  In contrast, the Tiobe Index ranks the languages from the head, and is based on hits from a search query.  As of August 2019, Java reigns at #1, followed by C, and then Python.  The rankings did not surprise me, and at least 2 of my favorite languages made it into the top 3.  C++ came in 4th.

Swift (iOS) and Kotlin (Android), being specialty languages for the mobile space, were further down the list.  Swift came in at #18, but Kotlin disappointed, coming in at #45. Nevertheless, as iOS and Android users grow,  the popularity of Swift and Kotlin will likely follow.

The name Swift is easy to fathom.  The language speeds up iOS development (compared to using Objective C), and it also runs respectably fast.  The Kotlin designation is rather opaque, but being a derivative of Java, Kotlin was named after an island near St. Petersburg under the mistaken assumption that Java was also named after an island, albeit in Indonesia.  Java was actually named after the coffee, not the island.

In my own fevered imagination, and perhaps from spending a little too much time programming for the financial community, note that coffee is a commodity.  Cotton and linen are also commodities.  I'd like to think Java is to coffee as Kotlin is to cotton and linen, which makes for a better origin story.

When I reviewed Frederick Brooks The Mythical Man-Month, I lamented how the advice I treasured was either forgotten or ignored.  I was heartened to hear the book referenced in a recent podcast named Choiceology (jump to time index 28:47).  The podcast generally discusses how we make choices and what we can do to improve the outcomes.  This particular episode explored the management of building the international space station and that of renovating a home.  In both cases, there were cost overruns and the projects were late.   Brooks’ Team Scaling Fallacy came to the fore, where “adding people to a late project makes it later.”

It’s a good bet all software developers have experienced this, where management adds more people to a project expecting it will help meet the deadline, only to have the opposite happen.  And despite experiential data, this decision is sadly repeated, again and again.  The faulty starting assumption is that software development is like an assembly line where adding more people and equipment actually produces more product.  But software development requires some trial and error, customer feedback, and a debugging phase that’s more akin to the sleuthing of Sherlock Holmes, rather than, say, running a spell checker to catch typos.

Anthony Levandowski is back in the news and indicted for stealing trade secrets from his former employer, Google.  I first wrote about him in The Best Selling Tech Book On Amazon Is ... to illustrate how tech hiring is broken.  Too often, competition and desperation drives companies to narrowly look for specific skills, and to broadly over-look character flaws.  This fuels the tech bro culture, a trend that disappoints and saddens me.


Comments

Post a Comment

Popular posts from this blog

Bookshelf: UNIX A History and a Memoir

-
Image
  A man page will give you, in black and white, specific information about UNIX. Brian Kernighan's new book adds color and depth about UNIX you won't find anywhere else. I'm not a gray beard (yet), but I imagine they would plow through the book knowingly, but at the same time, learn a few things. Those new to UNIX -- recent college grads or those experimenting with Raspberry Pi -- would be better off starting with Chapter 8 which describes more relatable events and the descendants of UNIX, including Minux and Linux. It's when they start to ask questions like "Where does UNIX come from?" and "Why is Gamora grep?" that they should start from the beginning: Bell Labs, 1969. Kernighan opens with a birds-eye-view of Murray Hill New Jersey, zooms in on the buildings, the offices, the significance of Center 1127, and offers a brief look at some of the key players there. As I progressed through the book, the two factors that made UNIX not just possible, bu
Read more

Bookshelf Classic: The C Programming Language

-
Image
My first job had me programming in Microsoft BASIC for the IBM PC (DOS).  BASIC worked well enough, but its limitations were clear.  The language was interpreted and therefore slow.  More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement.  Anyone who has read Dijkstra knew  GOTO was a bad thing . Having learned a structured language in college ( PL/I ), using BASIC felt unnatural.  When a C compiler became available for the PC, I saw a chance to improve and modernize our software.  The problem was selling the idea -- a problem made harder because I wasn't fluent in C. "It would be a staffing problem.  Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager. The argument was strong as my knowledge of C was weak.  But I knew that C, by design, was a small language and thus easy to learn.  "It has about 30 keywords," I proffered to another manager. U
Read more

Connections

-
Image
Opening a drawer in my hotel room in Toronto, I found this.  I worship at the altar of tech, but I imagine the reaction between two priests might go like this: Mormon Priest:  "At least we're wireless!" Catholic Priest: "And from the very beginning too!"
Read more