The global SARS-CoV-2 pandemic of 2020 has pushed many firms around the world to embrace remote work both sooner and more rapidly than they might have intended. With state-mandated restrictions on movement, and the PR and liability risk of inadvertently hosting a spreading event, companies have scrambled to support their employees working from home while maintaining as much productivity as possible.

Without the need to commute into an office, often in a dense urban center, many employees have also relocated, opting for the comforts of family or simply quieter, less congested places to live. And this geographical distribution of their reports has placed new demands on managers to both support and supervise their teams in remote-first fashion.

Classical management philosophy is preoccupied with productivity, not just output, as a means of ensuring that the constituent parts of a process or organization are coordinated to maximize efficient yield. This tends to manifest in knowledge workplaces as micromanagement: supervisors who want to know how many minutes extra a report took on a lunch break, how slow they were in dispensing with a customer support call, metrics, metrics, metrics. And these proxy measurements are comparatively easy to obtain when the supervised is directly under the watchful eye of the supervisor, but when employees are working from their own homes, in offset time zones, it gets more complicated.

Now, ideally, an approach based on Objectives and Key Results (OKRs) and check-ins should provide a sufficiently granular approximation of productivity metrics without necessitating surveillance-grade stalking, but… well, that requires trust. And trust is not a significant feature of corporatocracy, particularly the American variety. Instead, in an environment of distrust and suspicion, firms and managers are eager to use the same information and computer technology that enables remote work to spy on their workers—and vendors are lining up to sell such tooling to them.

More than being built over the top of existing productivity tools, this surveillance is now being built into tools themselves. In October of 2020, Microsoft unveiled "Productivity Score" within Office 365, giving managers a view into, for example, the number of days an employee has been sending emails, using the chat, using 'mentions' in emails, and more, all to the individual level by default.

It is not clear that all this productivity monitoring improves firms' performance, and it is clear that it adversely affects employee mental health. A 2015 article from the Society of Human Resource Management observes that monitoring "can […] sow seeds of distrust and fear among workers who aren’t so keen on having their every move tracked." It notes that potential downsides of monitoring include increased turnover, stress, and inhibiting work.

It turns out that the workplace panopticon is counter-productive.

Instead, what work needs—and remote work in particular—is trust. Trust that properly trained, motivated, and compensated employees will find the discipline to get their jobs done, on time and to quality expectations. Trust that a clear discussion and agreement on their objectives and key results will give them the ability to manage their own productivity and deliver for the team, and that they can come to their managers with questions and clarifications that help them perform better and give their supervisors insight into their areas for development and recognition.

Trust sounds lofty and aspirational, but it is actually quite tactical, and is not at all at odds with metrics. The crucial shift is in moving from measuring "productivity" back to measuring output, and in designing processes and organizations themselves to maximize this. If we think of the production of any finished piece of work within an organization as being like an assembly line, then we can evaluate the quality of that line by assessing its ouput: how thorough the financial report is, how polished the video sizzle reel, how stable or buggy the website or mobile app.

Each of those assembly lines producing finished pieces of work are made up of stages, not unlike the stations on a factory assembly line, one stamping the sheet metal, the next welding it to the chassis. As parts of the work are pulled together, we can assess the quality of each stage by evaluating its output against a standard. And since each stage may in fact be a mini-assembly line of its own, we can apply these output checks recursively, creating a network of well-defined stages which receive quality input from their predecessors, add value through work, and pass their output on to their successors.

In moving from measuring productivity to measuring output, we accept that the workers at each individual stage may do things in different ways. They may take less time and thus appear to be idle, or write fewer emails and make fewer calls, but as long as their output is meeting our quality expectations for volume, timeliness, and correctness, we leave them to self-manage. We trust that they know how to get their work done.

The preoccupation with productivity is not irrational: it seeks to avoid situations in which sub-par output from a given stage stops the entire assembly line, but it attempts to do so by micromanaging the stages and their individual contributors. Trust is making clear to the contributors what the output quality expectations are, and holding them accountable for it. Trust is giving them the agency to maintain their quality for themselves, even where it presents a hypothetical risk of whole-line stoppage, because an assembly line of contributors who are properly motivated and empowered to deliver quality output is effectively self-coordinating, and will see continuous improvements at every stage without management intervention.

The irony is that trust is an old principle, one that was lauded in the mid-20th century for the ways it helped organizations deliver incredible results, and spread as an aspirational management philosophy. It just happened to go by the name Kaizen instead. It is impossible to effect the continuous improvement it espouses, from all levels of the organization, without trusting every worker to understand the scope of their process stage and its inputs and outputs, and valuing their perspective on how to make it better. Kaizen was extremely popular in physical manufacturing, often inspired by The Toyota Way, one of its most successful applications. In knowledge work, however, the work product is typically intangible, which can make it much harder to spot defects even one step further along the assembly line. Where a misshapen block is immediately recognizable as not an automobile's aluminum alloy space frame, a few wrong numbers in a table, a swapped column, a buggy algorithm…

So trust, but verify. Great process design is as much about defining distinct stages with clear inputs and outputs that produce the thing intended, as it is about devising checks and tests for each stage's outputs to ensure that they meet quality and correctness expectations. Trust is giving contributors the latitude to decide how they meet those expectations, and also welcoming their feedback in refining and improving those expectations.

We are only at the beginning of the broader remote work revolution, and there will be many experiments to try and fail, and lessons to learn and unlearn. We can not get started, however, if the management culture does not embrace and enthusiastically support the potential for outsize returns by accepting the teething risks that come with them, and this means placing trust in reports and having faith that trust will be repaid with outstanding results.

Many thanks to friends who proof read and gave feedback, including Jeremy W. Sherman, Onyeka Onyekpe, and Jutta Stöttinger.

I firmly believe that creating software is a craft discipline. Like other craft disciplines—painting, carpentry, masonry, garmentmaking in all its forms, etc—it draws on scientific and engineering knowledge, but reaches its greatest heights when it marries the empirical with the intuitive and subjective, with details about human ergonomics, or aesthetic flourishes intended purely to delight.

Also like other craft disciplines, it can suffer when productized and pushed to scale: delightful details can be sacrificed on the altar of efficiency, revenue, or profits; individual style can be whittled down for "standardization," making it easier for teams—or assembly lines of workers—to produce large volumes of consistent product. Portions of or even the entire production can be mechanized and automated, which can lead to output that it somehow colder, more distant. Less human.

It doesn't have to, though. Technology and process can accelerate creation, can reduce or eliminate drudgery and rote repetition, and free human creativity to emphasize those unique elements, wonderful digressions, and happy accidents that spark joy in the things we make. This is as much the thesis of Lightbox as it is my approach to the creation of Lightbox itself.

Freed from financial imperative as the raison d'être for Lightbox, I have made software-as-craft a part of my goal: to write this application in the most elegant, most expressive, most performant ways I know how. This establishes a number of competing constraints, and requires some hard-won experiential compromises to resolve:

• pursuing the absolute best way to build a piece of software can lead to constant rewrites of internal components with nothing public to show;
• discovering the absolute best way to build a component can lead to long, digressive journeys learning entirely new things—oh, hey, I finally focused on mastering fragment shaders—with no forward progress on the overall project;
• the environment in which the software is being written, and the platforms for which it is published, are themselves moving targets, meaning that "best" can be upended at any time: since first conceiving of Lightbox, I have migrated to a new programming language (Swift) and, recently, a new primary interface toolkit (SwiftUI; more on that in a bit).

The compromise is to look at the release process itself as iterative, and an important means of collecting feedback. Steve Jobs (apocryphally) said, "Real artists ship." [For non-software folks, we speak of "shipping" software to mean releasing it to the next consumer in its value chain, whether that is another developer on your team, another software/hardware development firm, or an end user.]

I have therefore made a set of choices—chosen a set of tools to work with, here and now—and established targets for release to the public, to validate my hypotheses and solicit feedback. Pertinently, during my last job search I had a couple of interviews that concluded with the assessment that my actual coding was the weakest part of my skillset. This was a bit of a shock, but my father pointed out that my desire to no longer code for a living had probably led to an ambivalence about the latest techniques, patterns and idioms in the tools I was using at the time. Now that I'm coding for myself alone, I want to sharpen every facet of my approach—without killing my timelines!

Lightbox, then, is a vehicle for many things, not least a "rebirth" of the software developer side of myself—the software craftsman particular about tools, techniques, and technologies, but sensitive to the nature of software as a conversation between its creators and its users.

What follows is more technically specific—nerdier, if you will. It is more germane to a narrow audience of software engineers, and particularly those working on Apple's platforms. Feel free to bail out if your eyes start to glaze over!

When Lightbox was first, truly "born," I was primarily a C++ programmer. I spent some time contributing to the Pencil2d open source animation editor, written in C++ and Qt, focusing on the Mac build. Around this time I had written an MPEG-1 encoder using types from what is now libav, intending to embed it in Pencil2d instead of spawning ffmpeg as a child process, which was incredibly brittle and error-prone. Trying to understand more about native Mac processes, frameworks, and user interface controls (Qt redraws every element itself, or at least did back then, such that the default UI looked several years out of date), I began dabbling in Objective-C, which would lead to an opportunity to become an iOS developer circa 2010.

Somewhere along the way, I decided it was better to focus the initial version of Lightbox on a single platform, obviously selecting the one I used daily, and to use the native platform tools and APIs as much as possible. Thus was Lightbox recast as an application written in Objective-C.

Everything I wanted—and want—to do with Lightbox is achievable in Objective-C, but Apple announced Swift at WWDC 2014, and, after some early disinterest, I felt it started to become an interesting and powerful language around late 2016. We began migrating to Swift at my job at the time, and given where I was with Lightbox I felt it made enough sense to rewrite what I had so far.

While there is a huge volume of Objective-C in production, not least within Apple itself, and the language is not disappearing any time soon, my nous for Apple's corporate behavior said that Swift would get all the cool new toys first moving forward, and that I'd want to have access to that in building my application. That has proven to be a prescient choice, as Swift has become a really powerful and even enjoyable language to work in, three years later… and the toys sure have come!

I should mention that Lightbox migrated from being a Mac-first application at this time to mobile-first, specifically for the iPad, thanks to the launch of the iPad Pro and Pencil. On the Mac I had relied on tablet digitizers like those from Wacom for high-precision pointer input—position, tilt, rotation, pressure. Third party styluses existed for the iPad before the Pencil, but they either just simulated our fat-meatstick fingers through a capacitive nib (e.g. the Cosmonaut by Studio Neat), delivering a drawing experience not unlike using a dry-erase marker; tried to at least get the fat nib out of the way, visually, like the Adonit Jot and Jot Pro; or required a Bluetooth connection and the integration of vendor-specific software, subject to additional licensing terms, like the Pencil by fiftythree or Wacom's Intuos Creative Stylus—both now discontinued. The Pencil was a revelation, with native platform support, and now it's available on even the cheapest iPad mini.

I had tried to cobble together mobile drawing solutions before, with a laptop and small Wacom Intuos tablet, but the cabling and power requirements and awkward ergonomics (not to mention weight) made it unsatisfactory. Manufacturers like Wacom themselves tried to address this market with devices like the Cintiq Companion, but the choice of a fundamentally desktop-oriented operating system in Windows made it awkward to use in many ways, just like the Microsoft Surface tablets. With the iPad Pro + Pencil, Apple offered an ergonomic, elegant, portable drawing solution for the digital artist—and the boom in applications like Procreate, Paper by fiftythree, Tayasui Sketch, Linea and more appear to support that thesis.

[Yes, I am aware of Android tablets, but which ones are in significant use beyond the Samsung Galaxy Tab? The consumption-oriented Amazon Kindle Fires don't count, for the purposes of market research for a professional-grade drawing app. Ditto the Galaxy Note; that's waaaay down on the priority list, after Linux.]

Speaking of Linux, a few years ago I toyed with the idea of writing the core application logic in a more "portable" language, with only the UI layer being specific to the platform and employing native APIs. The idea was to make the application easier to port to additional platforms post-launch. I was enamored with Rust at the time (still am, really; hope to use it on a future web component), so… While I eventually abandoned that in favor of focusing on a single platform to validate my hypotheses, it did result in my tiny contribution to cocoa-rs (now deprecated) and my bug report for rust-bindgen.

I mentioned SwiftUI earlier. Apple previously had a set of similar, yet subtly different platform APIs for user interface development across the Mac, iOS, and Watch (if you care about that)—AppKit, UIKit, and WatchKit, respectively. (TV uses a variant of UIKit, now; it used to publish a horrifying subset of HTML!) While I have settled on the iPad as my initial development and launch platform, I absolutely still intend to bring Lightbox to the Mac—and someday Windows and Linux, but that requires another discussion about constraints and portability. Announced just this past summer, SwiftUI is both a unified set of APIs for all of Apple's platforms, and a significant shift from an imperative to a declarative approach. Importantly, it significantly updates Apple's developer tooling, giving us live preview right in the IDE, and ending the long-fractious "marriage" of Interface Builder and Xcode proper.

[Historical aside: Interface Builder used to be its own application, before being merged into Xcode with version 4.0. Xcode itself was the successor to Project Builder; back then, Apple had one application in which to design and "compile" your visual interface assets, producing .nib files—NextStep Interface Builder—and another in which you wrote code that, when compiled, would load and deserialize those NIBs at runtime. As you can imagine, this created a lot of crash opportunities.

There were interim improvements, such as the adoption of an XML-based description of interface objects, saved as .xib files, to replace the serialized binary state of .nibs; and a further enhancement to make the XML generation stable, such that merely looking at a .xib in the integrated Interface Builder view didn't rewrite it and generate spurious diffs. These were welcome, but really patches on an approach that had been outgrown. And yes, I have hand-edited .xib files many times. Never again!

Suffice to say that the idea of a tight code evaluation loop with immediate visual feedback, and the ability to visually edit your interface and see the generated code, while eliminating the runtime crash possibilities, made a lot of developers excited! Who cared if Microsoft had shipped that to its devs in 2007—and since scrapped it.

Sorry, the ex-Windows dev in me can't resist digging at now-fellow Apple devs who think our tooling is state-of-the-art!]

SwiftUI makes a functional reactive style of user interface development natively feasible on Apple's platforms, far better than RxSwift or ReactiveCocoa ever could, and more comprehensively than Facebook's React Native. Coupled with the newly-announced diffable data sources and compositional layout APIs for table and collection views (still in need of native SwiftUI versions), representing application state as a tree where each nested/sub-state node is transformed by a function returning a new sub-state and rendered in SwiftUI with zero side effects becomes increasingly feasible. The craft side of me ambitiously wants to try for that!

The good thing about choosing to adopt SwiftUI is that I hadn't written too much of the user interface yet, and that SwiftUI can embed and fully interoperate with UIKit controls—also necessary, since many essential facilities are not yet available in SwiftUI (Collection Views, Metal Layers/MetalKit, PencilKit). As with Swift itself, I can tell that SwiftUI is the future of Apple user interface development, and will receive future enhancements much more readily than UIKit.

One of the areas where I am torn, from a craft perspective, is on graphical rendering. The SwiftUI WWDC videos recommend adopting Metal (Apple's high-performance, hardware-accelerated graphics and parallel computing library) for your custom graphics; I'm extremely good with Core Graphics, Core Image, and Core Animation, so this would be a transition for me. I am coming to terms with shipping an initial version built with Core Graphics—or even punting on that and using Apple's PencilKit—and a Metal implementation in a future update. Craft vs compromise.

The process of arriving at the set of choices that define the project has been involved, serendipitous, but also whimsical. Free of imposed deadline, but constrained by the desire to bring something real into the world. In a sense, I probably could have written earlier, lesser versions of Lightbox several times over in the time I have spent "finding its way," but that is the paradox of the passion project: I don't just want to put "something" out there; I want to put something great out there.

A certain measure of rewriting is inevitable, but that is true of all software. Post-launch, new platform features and constraints, new APIs and user expectations mean extending, modifying, exhuming, and often discarding substantial bits of code. The challenge for me as a developer is how to minimize those disruptions while maximizing my output. The challenge for me as an indie businessman is how to minimize time-to-market while maximizing customer satisfaction. The challenge for me as a human being is how to balance all this against my commitment to my family, my responsibility to my day job, and my availability to my friends and loved ones.

It's a glorious puzzle, itself a meta-layer of craft. And I love it!

On Friday, October 4th, 2019, the general manager of the National Basketball Association's Houston Rockets, Daryl Morey, sent out a tweet in support of pro-democracy protests in China. This spawned reactions from the Chinese state and (state-backed) enterprises, with athletic footwear manufacturer Li Ning withdrawing its sponsorship of the team, and Chinese state television and Tencent, a leading internet and cable provider, announcing that they would remove Rockets games from their respective schedules. The Rockets owner and the NBA issued hurried statements that tried to walk back Morey's tweet, or at least distance themselves from it, which incurred backlash stateside as politicians, cultural commentators, and Twitter users alike took the NBA to task for capitulating to Chinese authoritarianism.

One tweet I saw called the NBA hypocritical because it was so "performatively woke" on domestic social justice issues, while another echoed the idea that the NBA had a responsibility to stand up to China and stand up for human rights. It's not so much that I think that they're wrong, but I think they misunderstand the network of incentives at play.

Domestically, the NBA is viewed as perhaps the most progressive sports league. That is because its players are highly visible and have accrued significant social power, which they use to create leverage toward the issues they care about. Their physical visibility, unencumbered by helmets or hats, and their gravity-defying athletic feats made them incredible pitchmen for sneakers and endorsers of lifestyle products, for which they have been handsomely rewarded. This weakened the leverage that their nominal employers had over them, which they also used to band together and negotiate one of the better collective bargaining agreements in US professional sports through their union, the National Basketball Players Association. They now even extend their social capital to the interests of collegiate athletes.

The NBA audience has also largely aligned with those players and their issues, so the League has smartly fallen in line. The contrast to, say, the National Football League, is that the NFL's most powerful and visible players—overwhelmingly white quarterbacks—are either silent on or opposed to "progressive"/"woke" social positions. The core of the NFL audience consequently does not sufficiently support such stances, and thus the NFL also falls in line. This is why Colin Kaepernick doesn't have a job.

But the NBA wasn't always progressively positioned. 20 years ago it shunned and silenced Mahmoud Abdur-Rauf, who refused to stand for the national anthem and was vocally critical of the United States' long history of tyranny. It is widely believed that Abdur-Rauf was blackballed in his prime—"Kaepernick" before Kaepernick—by the powers that be of this same, "progressive" NBA.

Ultimately, the NBA is a government-sanctioned cartel of business interests, and corporate incentives have always and will always drive its politics. In each distinct geography, it is at the mercy of the social power its players have accrued—considerably less in China than in the US, for instance—and the consequent sociopolitical sensibilities of its audience. This is then modulated by regional market realities, where China's centralized authority can render the NBA invisible and inaccessible to its highly lucrative Chinese fans. It is inevitable that the NBA would accede to Chinese national interests.

There are larger threads worth pulling at here. Many consumers in the West expect their domestic corporations to respect their purchasing power and thus acquiesce to their politics, but in a global marketplace where Chinese profits and their future potential dwarf those from any other individual territory, firms will increasingly be driven to acquience to the Chinese central state authority. And Western consumers are complicit in this, in their capacity as shareholders in Western firms. Because share price and executive longevity are functions of profits and growth, divorced from values, corporations adapt accordingly, adopting the language of progressivism where it makes "business sense," but also just as quickly dropping it where it doesn't.

Like China.

Update: NBA Commissioner Adam Silver issued a (second, "clarifying") public statement on the Association's position regarding Morey, and China's desire to see him punished in a way that would serve as a deterrent to other NBA personnel. Said Silver, "the NBA will not put itself in a position of regulating what players, employees and team owners say or will not say on these issues.  We simply could not operate that way."

This is actually a relatively principled and public position for a corporation's leader to take on this issue, and I applaud Silver's courage and long-term perspective. Not everyone is quite so charitable, and eight members of the US House of Representatives have signed on to a letter criticizing Silver's response and asking the NBA to suspend activities in China.

LOL.

In a world where Apple removes apps that run afoul of state censors from the Chinese edition of its App Store, it's extremely rich to insist that the one firm already taking a financial bath for not completely capitulating "do more." It is on-brand for many of these representatives, but it is a toothless bit of politicking that ignores the (dystopian?) capitalist reality we now live in. It also ignores the complete lack of leadership on this issue from the White House, with no public statement of support for the NBA or "American values," leaving a corporation to go up against a country at a time when that country increasingly perceives itself to have leverage over our own.

God Bless America!

There has never been a better time to start a software business. At the same time, for certain types of software, there has never been a worse time to start a software business. The same forces that have made it easier than ever to distribute software to users around the world and collect payments from them, have made those users reluctant to pay, and driven the up-front price they are willing to pay to effectively zero.

This piece is targeted at business-minded software indies, potential future investors in my Lightbox enterprise, and anyone else deeply curious about business models in software, especially productivity application software. It gets wonky in parts, so be warned!

Software applications can be organized in a variety of ways, depending on the functionality that they provide and the interface the user engages with. Most applications can be structured as “web apps,” where the user engages with an interface hosted in the web browser—which can now be quite robust, visually sophisticated, and interactive—and transfers data to and from a remote host. Not only social networking and streaming media, but productivity applications from document creation (and collaborative editing) like Google Sheets and Slides, to “groupware” like shared calendars and project timelines, to visual design like Figma and Canva.

That last category is most relevant to Lightbox, and serves as a useful lens for examining its structuring, delivery, pricing, and the overall business model. It used to be that graphically intensive applications needed to run entirely locally, only synchronizing their (large) files to remote storage, because the web was “too slow and laggy.” Improvements in network speeds, and browser technologies such as Local Storage, the HTML <canvas> element for drawing, and much more sophisticated JavaScript engines for dynamic interactivity, have combined to render that truism false. There are even web-based video editing and markup applications, from SyncSketch to ClipChamp to Adobe Spark. So why isn’t Lightbox being designed as a web application?

The fundamental constraint is input. Computing devices universally offer pointer input, either in the form of the mouse/trackpad on desktop and laptop personal computers, or as capacitive multi-touch on our mobile devices. It is possible to create a drawing app using only these relatively crude inputs, and even to infer more sophisticated intent by clever application of velocity and more, but digital artists expect a high-precision, pressure-sensitive stylus that gives software the ability to more faithfully mimic traditional materials (pen and paper), or interpret their multifaceted inputs in fresh and new ways. For personal computers, this has been via tablet digitizers such as those from Wacom, Huion, or XP-Pen; for mobile devices, the Pencil remains unequaled at this moment. For now, then, Lightbox needs to be a native iOS application because the Pencil only reports its full data to the native system API.

(There is a Working Draft W3C specification for Touch Events, but it has certain lowest common denominator characteristics. For instance, with the native iOS APIs and because of the way it is connected to the iPad, the Pencil reports estimated values for some of its input properties. It then gives you an estimationUpdateIndex which lets you receive more accurate measurements of the properties once available. None of this is represented in the TouchEvents Web API.)

Web applications have certain advantages, such as every user being updated to the latest version whenever you want, but also come with certain expectations such as user-created data being stored remotely and needing to be exported/downloaded to a local device. This expectation allows web app publishers a measure of leverage, in that they can charge a fee to grant users access to the data they create using the app. Canva, for instance, allows you to download your data freely, but charges for access to use its templates, stickers and other elements in your designs. Their ideal user profile is designing a poster or flyer, or other kind of purpose-specific communication and appreciates the access to a library (store) of elements they can incorporate to achieve their goal faster.

Say that user is now tasked with developing a comprehensive brand identity, and applying it to communications across print, web, video (television, film, streaming), packaging… That user also wants the production process to be fast, and is not prepared to wait for the web application to transfer large file assets “to the cloud” or vice versa. The demand for performance at scale drives them to something they can install locally, and use local file assets against, simply periodically syncing to remote (“cloud”) storage. This is the Adobe Creative Cloud model, charging for continued access to the programs—and any data the user has created, locked up in often proprietary formats—and while Adobe has been quite financially successful with it, there was a nontrivial backlash to it when first introduced, so much so that there were multiple Change.org petitions to have Adobe revert the change, or at least make subscription-based access to Creative Cloud an option rather than the only way.

These petitions were unsuccessful, but I firmly believe that the response to this change by Adobe spawned dozens of new design and creative applications, almost all of which opted for the “traditional” pay to purchase/license in perpetuity model: Pixelmator, Procreate, Affinity Photo, Affinity Designer, Sketch, LumaFusion, etc. (Sketch has since modified its perpetual license, with feature updates and non-critical bug fixes gated on yearly renewals.)

Overlapping all of this were changes in user expectations around the price of downloaded and installed application software, driven primarily by Apple’s App Store. While early apps had price points comparable to desktop software of the early and mid-2000s, the competition for audience and the willingness of publishers of substitutes to undercut each other on pricing created a “race to zero,” such that today the average app’s price is barely $1.

One dollar.

And that “sale price” is for a perpetual license, supported by user expectations of regular bug fixes and software updates. From a business perspective, the customer lifetime value (CLV) of an App Store user, based solely on app purchase revenue, is negative. This is why it seems almost every iOS game is now "free to play" with heavy in-app purchases and/or ads. This is also why the majority of productivity applications either want subscription revenue, or require an external service account (which is then tied to subscription or ad revenue).

With Lightbox, my intent is to offer the application core for a flat rate, granting a perpetual usage license that entitles the buyer to receive bug fixes and security updates. I haven't decided on price point yet, but I intend on a discount introductory rate that will ramp up with each release, until I hit the intended long-term price. By doing so, I will be rewarding those users who took an early chance on an unproven, possibly buggier, less feature-complete version of the app by delivering additional value (feature updates) at a lower net price.

Note that I said that was the application core. I intend to offer modular, versioned add-ons priced individually. Not all add-ons will be relevant to all users, so the CLV from doing this will depend on the attach rate—the number and price of add-ons that the average customer purchases. But that is not the real revenue driver. There is an entire second phase of the Lightbox project which is where I believe the business will either prove sustainable long-term, or falter. I'm excited to talk about that, but I don't want to get ahead of myself.

The entire first phase of Lightbox is about delivering value to users, satisfying something of a lifelong passion of mine, and seeing enough financial return to make scaling the business through Phase 2 an attractive, and potentially venture-backable proposition. I'll talk about that in my next update.

Lightbox is a passion project, though, and that significantly distorts my personal calculus. While I am hopeful that my venture hypotheses are proven correct and I can build a sustainable business from it, I am going to build this application regardless, because it is the culmination of an almost life-long preoccupation with making images move and giving that power to artists—myself included.

There's a funny story about my penultimate Cornell Tech "startup studio" pitch eschewing fantastical competitive landscapes with one's own firm conspicuously placed in the upper-right quadrant, and hockey-stick valuation graphs that shoot steeply upward, because I realized that I had to do this regardless of financial return.

This is part of why I ultimately chose not to pursue venture capital at this stage of the journey. Part of why I took a day job, and the specific day job I took, and why I'm working on this as a side project.

I need Lightbox to exist, to come into being the way I imagined it, first, without an investor or advisor suggesting/pressuring me to "pivot" toward some ostensibly more lucrative audience. I need to excise this fixation, and once it is in the world I believe I'll be more objectively able to assess its prospects and grow it accordingly.

Or let it go.

Inspired and challenged in no small part by my friend Chris Krycho's announcement and progress log on his rewrite project, I have decided to finally, publicly announce my own long-term project: Lightbox.

The Lede: Lightbox is a mobile-first, full-featured, traditional (hand-drawn) animation production application/suite.

I discovered, during the past year, that there is another animation project called Lightbox! Full credit to them for releasing something usable first; I started my project many years ago, so I won't be renaming it at this time, but who knows what will happen before release.

That's it. That's the news. But if you care to read about motivations, history, and goals, then keep reading.

I have written a modest amount on animation, and it is the first of the subjects that this site's tagline proclaims to devote essays to. It is one of my foremost passions, and the thing I would most love to be able to do with all my time. Years ago I seriously considered pursuing illustration and animation as professional directions. I hedged, however, on the fact that the odds of significant financial success were low (and I like nice, expensive things), and opted for the much more immediately remunerative path of professional software development.

Passions tend not to let you rest, and a little idea I had experimented with during college kept gnawing at me. Paper and materials for physically animating drawings were expensive, bulky, and space-consuming, but the digital tools of the time left something to be desired. [RIP Plastic Animation Paper.] I was a software developer. I was an artist. Surely I could build a compelling animation package?

To increase my chances of success, I first sought out and joined an open source project, but when a completely separate project's dispute over licensing terms revealed the issues around, say, moving the application to Apple's iOS and then-nascent iPad, I realized that I needed to control every facet of my application's structure, so I resigned the open source project and struck out on my own. I made some early progress, particularly around a lightweight, fast, drawing engine:

And then Apple announced the iPad Pro, with the Pencil.

This product was a game changer. On the desktop I had to connect an external tablet digitizer like my Wacom Intuos, or a tablet display like the Wacom Cintiq (and its litany of challengers/pretenders). I had spent thousands of dollars on auxiliary equipment over the years, not counting the cost of my computers themselves. With the iPad Pro, I had computer, display, and digitizer, all in one. Apps like Pixelmator, Procreate and Affinity Photo showcased the levels of professional productivity capable on a mobile device. Could I build a professional-grade animation solution for the iPad, but one that was accessible to novices and hobbyists like myself?

The Plot Thickens

Okay, so mobile-first. I had created an LLC as a vehicle for these software ambitions. I started [re]building the app for iOS, redesigning its idioms and examining its performance implications. How fortunate for me that my day job was as an iOS developer for media organizations. Looking to better prepare myself to run this as a business, and to transition out of active software development in order to conserve my "coding juices" for my own project, I enrolled in the Cornell Tech MBA. So much amazing happened for me during that year, but one of the most relevant pieces is that I had time to really get to grips with machine learning, and to see some applications of it to animation. So there's an additional dimension to the product and business model that I'm super excited about.

The Cornell Tech studio model has every student participate in entrepreneurial programs in their final semester, and I used Lightbox as my lens, iterating on different strategies to build something I think is sustainable. My intent is to bootstrap the initial phases, and only consider venture when there is a need for rapid, though controlled, growth.

There is plenty more to come. I will be writing about my ambitions for Lightbox as a product, as a passion project, and as a business, and my observations and challenges relating to each of those. I am incredibly excited, and look forward to sharing this adventure with the world.

Last week, the fact that a Google engineer now identified as James Damore published a memo critical of the company's approaches to diversity and what he called its "ideological echo chamber" to an internal discussion group came to light. A version of the memo was leaked by Gizmodo, but some claimed it left out critical citations and charts, and a fuller, ostensibly more representative version has been uploaded here.

Discussion of this memo and the various reactions to it has, predictably, been intense and fairly polarized. One of the rebuttal arguments I have heard repeatedly is that the claims are being mischaracterized, so I thought it might be valuable (but ultimately, likely, a complete waste of time) to examine as much of the document as I can, following its references and separating reasonable claims from unsubstantiated inferences.

The memo begins with about a page and a half of generally unobjectionable prose, as Mr. Damore states his commitment to the ultimate goal of diversity and some self-serious admonishment about the risk of careless statistical extrapolation. I pick up on page 3, under "Possible non bias causes of the gender gap in tech."

On average, men and women biologically differ in many ways. These differences aren’t just socially constructed…

We begin with an indication that what will follow will be biological in nature, hopefully controlling for variance in geographic, social, economic and cultural environment.

Personality differences

But we immediately pivot to personality, which is not biological in nature. Worse, the very first reference, hyperlinked under "Women, on average, have more" actually states:

Gender differences in personality traits are largest in prosperous, healthy, and egalitarian cultures in which women have more opportunities that are equal to those of men. Differences in the magnitude of sex differences between more or less developed world regions were due to differences between men, not women, in these respective regions. That is, men in highly developed world regions were less neurotic, extroverted, conscientious and agreeable compared to men in less developed world regions. Women, on the other hand tended not to differ in personality traits across regions. Researchers have speculated that resource poor environments (that is, countries with low levels of development) may inhibit the development of gender differences, whereas resource rich environments facilitate them. This may be because males require more resources than females in order to reach their full developmental potential.

(Emphases mine.)

Not a good start.

He continues:

Women generally also have a stronger interest in people rather than things, relative to men…

This abstract reads:

Results show that gender differences in Big Five personality traits are ‘small’ to ‘moderate,’ with the largest differences occurring for agreeableness and neuroticism (respective ds = 0.40 and 0.34; women higher than men). In contrast, gender differences on the people–things dimension of interests are ‘very large’ (d = 1.18), with women more people-oriented and less thing-oriented than men. Gender differences in personality tend to be larger in gender-egalitarian societies than in gender-inegalitarian societies, a finding that contradicts social role theory but is consistent with evolutionary, attributional, and social comparison theories. In contrast, gender differences in interests appear to be consistent across cultures and over time, a finding that suggests possible biologic influences.

This says that the agreeable/neuroticism differences between men and women are moderate at best, though the people/things split is large (and only maybe bioligically influenced).

(I will merely note that the Empathizing/Systemizing wikipedia summary he links to has a fascinating criticism section. I wouldn't have incorporated it into a good faith discussion, but that's just me.)

"Extraversion expressed as gregariousness rather than assertiveness" is a whole uncited claim. Ditto "higher agreeableness."

He then repeats "neuroticism," here just linking to a Wikipedia definition of the trait, even though the actual scholarly research he cited earlier indicated that the difference between men and women is, at best, modest.

This is the first page of textual claims, ignoring the charts.

We go back to the Big Five personality differences, here hyperlinked under "research suggests" (PDF), which abstract reads:

Previous research suggested that sex differences in personality traits are larger in prosperous, healthy, and egalitarian cultures in which women have more opportunities equal with those of men. In this article, the authors report cross-cultural findings in which this unintuitive result was replicated across samples from 55 nations (N = 17,637). On responses to the Big Five Inventory, women reported higher levels of neuroticism, extraversion, agreeableness, and conscientiousness than did men across most nations. These findings converge with previous studies in which different Big Five measures and more limited samples of nations were used. Overall, higher levels of human development—including long and healthy life, equal access to knowledge and education, and economic wealth—were the main nation-level predictors of larger sex differences in personality. Changes in men’s personality traits appeared to be the primary cause of sex difference variation across cultures. It is proposed that heightened levels of sexual dimorphism result from personality traits of men and women being less constrained and more able to naturally diverge in developed nations. In less fortunate social and economic conditions, innate personality differences between men and women may be attenuated.

While this does appear to corroborate the position that women are different from men—consistently across cultures in 55 nations!—it undermines the argument that it is inherently biological, given that men's traits changed in response to economic development. In simpler terms, this does not validate the claim that these personality traits are biological in nature; rather, it suggests that they are socio-economic. (It also raises the interesting question of whether socioeconomic development primarily benefits men, thus leading to a lessening of their neuroses, and if this isn't evidence of broad-based socioeconomic discrimination against women. But I digress.)

I'm barely half-way through and even the claims section isn't holding up. Let's skip ahead, but anyone else is free to examine the claims and the citations linked against them.

• Women on average show a higher interest in people and men in things

• • We can make software engineering more people-oriented with pair programming and more collaboration. Unfortunately, there may be limits to how people-oriented certain roles at Google can be and we shouldn't deceive ourselves or students into thinking otherwise (some of our programs to get female students into coding might be doing this).

Superficially, this is a perfectly fine bit of observation and proposed remedy, however it completely fails to show correlation, much less causation, between interest in people or things and software engineering performance. It implies that interest in people is limiting—"there may be limits to how people-oriented certain roles at Google can be"—but there is zero evidentiary basis for this notion.

• Women on average are more cooperative

• • Allow those exhibiting cooperative behavior to thrive. Recent updates to Perf may be doing this to an extent, but maybe there's more we can do.
• • This doesn't mean that we should remove all competitiveness from Google. Competitiveness and self reliance can be valuable traits and we shouldn't necessarily disadvantage those that have them, like what's been done in education.

Again, an implication that competitiveness is a good and cooperation is either an outright negative or a limiting trait, with no evidence for this claim.

But wait! There's a hyperlink! "…what's been done in education" carries an HREF to… this Atlantic article? Hmm, not exactly scholarly, but fine.

The research commonly cited to support claims of male privilege and male sinfulness is riddled with errors. Almost none of it has been published in peer-reviewed professional journals. Some of the data turn out to be mysteriously missing.

(Irony.)

A review of the facts shows boys, not girls, on the weak side of an education gender gap. The typical boy is a year and a half behind the typical girl in reading and writing; he is less committed to school and less likely to go to college. In 1997 college full-time enrollments were 45 percent male and 55 percent female. The Department of Education predicts that the proportion of boys in college classes will continue to shrink.

B-b-but I thought women were less competitive and more neurotic and less wired to succeed?!

Data from the U.S. Department of Education and from several recent university studies show that far from being shy and demoralized, today's girls outshine boys. They get better grades. They have higher educational aspirations. They follow more-rigorous academic programs and participate in advanced-placement classes at higher rates. According to the National Center for Education Statistics, slightly more girls than boys enroll in high-level math and science courses. Girls, allegedly timorous and lacking in confidence, now outnumber boys in student government, in honor societies, on school newspapers, and in debating clubs. Only in sports are boys ahead, and women's groups are targeting the sports gap with a vengeance. Girls read more books. They outperform boys on tests for artistic and musical ability. More girls than boys study abroad. More join the Peace Corps.

Uh oh.

Suppose we were to turn our attention away from the highly motivated, self-selected two fifths of high school students who take the SAT and consider instead a truly representative sample of American schoolchildren. How would girls and boys then compare? Well, we have the answer. The National Assessment of Educational Progress, started in 1969 and mandated by Congress, offers the best and most comprehensive measure of achievement among students at all levels of ability. Under the NAEP program 70,000 to 100,000 students, drawn from forty-four states, are tested in reading, writing, math, and science at ages nine, thirteen, and seventeen. In 1996, seventeen-year-old boys outperformed seventeen-year-old girls by five points in math and eight points in science, whereas the girls outperformed the boys by fourteen points in reading and seventeen points in writing. In the past few years girls have been catching up in math and science while boys have continued to lag far behind in reading and writing.

(I found this particularly interesting because so many of Damore's defendants on Twitter have been citing girls' lower SAT MATH—only math—scores as evidence of their lower suitability for STEM and specifically software engineering.)

I'm going to throw in a few citations of my own, because I think they're important. Colleges have been lowering admission standards for males, particularly at the post-graduate level, to preserve some semblance of "balance."

Where Are The Men? Widening gender imbalance has colleges courting males.

Teenage girls typically have better grades than their male counterparts, but college admissions officers say they can't stand idly by and watch the schools become mostly female bastions. So colleges are taking steps to reverse the trend by reaching out to high school boys through direct marketing and phone calls from recruiters and male professors.

Some universities are going even further. A few years ago, Wake Forest University in North Carolina began admitting more men to correct the gender imbalance, even though fewer males had applied. Among state universities, the University of Delaware says it sometimes lowers its expectations for promising boys who faltered in the 9th and 10th grades. And in a yet-to-be-released study, liberal arts colleges acknowledge admitting less-qualified boys to balance enrollment.

…

At the University of Delaware, where women constitute 58 percent of the student body, administrators say they haven't lowered standards for male applicants outright, but they may be more lenient with high school boys.

"We see ups and downs in their academic records," said Louis Hirsh, director of admissions for the University of Delaware. "We try to be more forgiving of their transcripts in 9th and 10th grades, when males are more likely to have problems."

Why getting into elite colleges is harder for women

…one of academia’s little-known secrets is that private college admissions are exempt from Title IX’s ban on sex discrimination—a shameful loophole that allows some of the most supposedly progressive campuses in the nation to discriminate against female applicants.

…

Colleges won’t say it, but this is happening because elite schools field applications from many more qualified women than men and thus are trying to hold the line against a 60:40 ratio of women to men. Were Brown to accept women and men at the same rate, its undergraduate population would be almost 60 percent women instead of 52 percent—three women for every two men.

Affirmative Action for Men: After op-ed by Keyon dean underscores how college admissions officers favor male applicants, many ask: Is this legal? Is it right?

(Spoiler: it's legal—or at least it was in 2006. Title IX exempts private institutions re undergraduate admissions.)

When admissions officers gather to create a freshman class, there is a large elephant in the room, wrote Jennifer Delahunty Britz, in The New York Times last week: the desire to minimize gender imbalance in their classes. Britz, the admissions dean at Kenyon College, wrote that her institution gets far more applications from women than from men and that, as a result, men are "more valued applicants." Britz discussed a female candidate who was considered borderline by the Kenyon team but who -- had she been a he -- would have been admitted without hesitation.

Why is it important to favor male applicants? "Beyond the availability of dance partners for the winter formal, gender balance matters in ways both large and small on a residential college campus. Once you become decidedly female in enrollment, fewer males and, as it turns out, fewer females find your campus attractive," Britz wrote.

The gender gap in undergraduate enrollments is, of course, no secret in academe. Women are solidly in the majority (about 57 percent nationally) and their percentages are only expected to increase in the years ahead. The gender gap first started to show up -- more than a decade ago -- at liberal arts colleges, with educators guessing that men preferred larger institutions or the engineering and business programs more prevalent at universities. But recently, the gap has started to show up at flagship public universities, too: Some board members at the University of North Carolina at Chapel Hill were so stunned in May to learn that this year's freshman class would be 58 percent female that they asked if it was time to institute affirmative action for men.

I don't know how to tell you this, dudes, but you're already diversity admissions. (And note that these references are from 2005 and 2006; the trend has only gotten more pronounced since.)

This is getting long, and I'm tired and have code to write, and you're probably getting bored so I'll cut to the chase: James Damore's citations do not support the conclusions he is drawing from them. This makes his findings and proposals for remedies worthless. He has some good ideas, such as expanding the mentoring and coaching opportunities to everyone, regardless of gender identity or racial background, but his presentation among so many simply wrong claims means they won't be valued as they should.

I began this essay with the purpose of examining the verifiability of claims, and having determined (to my own satisfaction; publish your dissent on your own blog) that they are poor, I will stop here.

Yesterday Apple announced, via a handful of tech reporters it trusts, that it is completely redesigning the Mac Pro. This is unusual for Apple, which typically "announces" products by releasing them, but that isn't my concern here. In its round-table with the reporters, Apple admitted that it had designed itself into a corner, constrained by the thermal envelope of the Darth Trashcan.

How did this happen?

Apple has been making desktop computers for almost 40 years, and professional workstations in particular for over 25 (Quadra, PowerMac, Mac Pro). I remember the launch materials for the PowerMac G5 detailing the case's distinct thermal zones and passive airflow to allow for quiet, cool performance. How did they miss the boat on the evolution of thermal requirements in professional workstations so badly in just a four-year window? What's worse, this was not some unexpected development. If anything, Apple's bet on a shift toward highly parallel GPU workloads, able to scale across multiple GPUs, was the real gamble: it required developers do custom work for OpenGL programs, or use OpenCL, neither particularly likely in a world of performance applications dominated by Windows and Nvidia (and thus CUDA).

As confounding as the significantly constrained thermal headroom was the lack of extendability and expansion, with no additional storage and no PCI slots for custom components. Instead it called for the use of large amounts of external cabling via Thunderbolt. Thunderbolt can boast some impressive transfer speeds, but they didn't necessarily beat ISA lanes to PCI slots or SATA, and came at a huge cost premium.

Given the range of constraints that define professional workstations, the Late 2013 Mac Pro is what you might arrive at if you first determine that your must-have is compact form factor.

I have a theory.

I've been sitting on it for a while, teasing it here and there, but hesitant to publish it (until now) because, frankly, I've been unprepared to deal with the backlash.

It's a good theory, though, and it explains so many puzzling design features in Apple hardware across its product lines over the past 5 years, from the scalloped battery in the original 12-inch MacBook…

…to the extremely hand-unfriendly (IMO) edges on the iPhone 5…

…to the focus on thinness behind the panel on the iMac, necessitating its unsightly bulge.

My theory is that Jony Ive's design aesthetic is fundamentally sculptural, not ergonomic: that he makes objects to be beheld, not to be held. And that following the passing of Steve Jobs in 2011, there really wasn't anyone at the company to rein him back in favor of other considerations.

Let me back up. Ive's sculptural bent is not new, and has been a powerful asset for Apple over the years. Ive's first assignment at Apple was the original iMac, which radically changed the way personal computers were packaged, presented and marketed.

This machine was an immediate sensation, and in the eyes of many observers helped turn Apple's fortunes around. It also came with this mouse:

Right from the start, the object designed to be placed and beheld receives a disproportionate amount of design attention. The object designed to be held and manipulated is designed not for its purpose, but for presentation and observation.

Before this USB Mouse, better known as the "Hockey Puck," Apple had pretty decent mice. Every Apple mouse since this one has been terrible, disregarding the shape and geometry of the human hand—but they're all undeniably beautiful, museum pieces even. Fortunately, the Magic Trackpad is a superior input device in nearly every way, so the fact that Apple hasn't made a single decent mouse in 25 years can be ignored.

In a way, the sculptural theory explains even the messiness of the Ive-led iOS 7 redesign, with oft-unreadable fonts, indecipherable glyphs replacing clear icons, and lost affordances everywhere. ("Who needs outlines to clearly indicate what is a button and what is text, or whether a toggle is depressed or not!") The aesthetics of display trumped the pragmatic concerns of interaction and use, especially for a designer who was expanding into a new area.

The Late 2013 Mac Pro was the first really big post-Jobs product redesign. 2012 had given us the first MacBook Pro with Retina Display, but the enclosure was an iteration of the design language already firmly in place, a cross between the MacBook Air and the preceding MacBook Pro. It was the Mac Pro that was a "blank canvas" product iteration, and it was a visual stunner, but if you really think about it, it was also the epitome of this device-as-sculpture problem. Its case was polished such that merely touching it covered it in fingerprint smudges (for a device that depended on external peripherals for extendability).

I have felt, over the past two years, that Jony has lost interest at Apple, delegating more and more of his responsibilities and disinterestedly narrating videos from within a white room (or not even appearing on camera!) for WWDC keynotes. Perhaps he's been hard at work on a final hurrah in the form of the 10th-year anniversary iPhone, due this Fall, or some other top-secret (Car?) project.

There was a haphazardness to the recent MacBook Pro with TouchBar, especially in the size of the trackpad starting to eliminate wrist rest space, and a third straight year of the same iPhone 6 "lozenge."

Even the Watch suggests a measure of design disinterest, or sculpture over ergonomics, looking as it does like a miniature iPhone 6 with a strap attached. Every time I look at it, I find it so completely divorced from the aesthetics of the human body. It's fascinating.

I'm hoping this Mac Pro reset represents a rebalancing of input constraints within Apple, and hoping it carries over to other product lines simply because it means even better results.

As for Jony Ive, I think he's done. I could be wrong, but it looks like it's time to move on. So long, and thanks for all the hits!