The Cost of Doing Internet Business

Screenshot of Netscape Navigator browser

A couple decades ago the costs of putting up a website seemed really reasonable–especially as compared to pre-Internet media like books, newspapers, and encyclopedias. A lone webmaster toiling away in the wee hours of the night could get a site up and running with HTML and CGI by the break of dawn. Pages were static, served directly from a server’s hard disk, and JavaScript and CSS non-existent.

iOS 6 TableViewController example app

Mobile apps were in a similar state a decade ago. The costs were small as compared to full featured desktop and web applications and there wasn’t much a mobile app could do that a simple table view controller couldn’t do. A lone mobile dev toiling away in the wee hours of the night could get almost any app ready for release to any app store in a few weeks. Back then most mobile apps were under the constraints of low-powered processors, limited memory, and ephemeral battery life. These constraints required mobile apps to be more like single-purpose widgets than multifunction applications.

Today it’s a more complex world for web and mobile apps. We have seriously sophisticated tech stacks that include the Cloud, HTML5, and advanced mobile operating systems that target screens of every size and devices without any screens at all. We don’t create websites or apps, we build multi-sided networks with so many features that vast teams of developers, scrum masters, product managers, designers, data scientists, and service reliability engineers are required.

In the modern world of 2019 no developer works alone in the wee hours of the night.

This hit home to me when I met a talented Google Doodle developer with amazing JavaScript skills. This dev explained that thier code was not allowed to go into production without a dozen teams looking it over, testing it, and beating it up. Because, you know, scale, performance, and security. By time the Google Doodler’s code appeared on the Google Search home page it was unrecognizable.

In my own work as a software developer and software development leader I’ve seen the rise in complexity and cost hit web and mobile development hard. GDPR, PII, COPA, OWASP, and other standards have added hundreds of dollars of cost to the development of iOS and Android apps. So has the proliferation in diversity of mobile devices. Are these pocket super computers with super high-resolution screens, prosumer cameras, always-hot microphones, machine learning chips, GPS, motion sensors, and unlimited cloud storage still phones? I don’t think so. Some are as big as coffee table books and others can be strapped to a wrist. When they start folding up into intelligent origami I don’t think we can call them phones anymore.

If you are not a developer, imagine trying to writing a book for new kind of paper that can change its shape, size, and orientation at a reader’s whim. Sometimes this paper has no visual existence and the user can choose to listen to your writing instead of reading. This protean piece of paper has all sorts of sensors so you, as the author, can know in real time where you reader is and what your reader is doing (if your reader accepted the EULA). How do you write a book for paper like this? It refuses to be any one thing and requires you, as the author, to image every possible configuration and situation. This is what software development is like today!

With 5G, Blockchain, AR/VR, and AI just around the corner the business of web and mobile development will become an even more unconstrained hot mess.

As developers we have gone from being lone wolves working independently to two-pizza teams collaborating in agile to multiple feature teams networked globally. It’s all we can do to just keep up with advances in hardware, software, operating systems, communications, and regulations.

We, as an industry, have not recognized the costs of software eating the world.

The hidden costs and ignored costs of crafting software for consumption on the Internet has grown non-linearly and I don’t think it’s stopping anytime soon. These costs are disrupting almost everybody everywhere. It’s gotten so bad that the generally favorable view of the Internet has soured.

So there are a few things we need to do!

Hold honest conversations about the costs of open and connected Internet software. We can’t keep throwing apps out into the wild and expect them to be safe and reliable. Cloud computing has solved this problem for the backend services as we now accept that servers are not pets and because we aggregate the costs and leverage expertise of giants like Google, Amazon, and Microsoft.

While we have learned to treat servers like machines, we still treat apps like pets, grooming them and agonizing over their look and feel while ignore our duty to make sure these apps are not vectors for malware and malcontents.

We need new software development tools and services that give cloud-like benefits to the mobile side. I’d love to have a CodePen or a Glitch for native mobile apps that aggregate costs and expertise required for responsible mobile app development. Apple and Google should not only give developers open SDKs and dev kits but something like a Swift Playground that we can release enterprise and consumer apps on top of. Yes, I’m asking Apple and Google to be gatekeepers, but we’re too irresponsible to abandon gatekeepers.

Finally, I would like to see a return to physical books, newspapers, and encyclopedias (insert your favorite old-school media product here) for the public mainstream use case. Digital-only isn’t yet the best way to communicate and express ideas for the commonweal. A paper publisher can at the very least assure us media experiences without any Momo Challenges inserted between the pages. Even more importantly a paper publisher has a name, an address, a phone number, and a way for us to legally hold them responsible.

We shouldn’t put the digital genie back in the pre-Internet bottle. We should be extremely realistic about the costs and responsibilities of developing software applications that users must depend on and trust.

Book Binder Update

My comic book collection iOS app continues to evolve. I continue to strip out features and focus on the core mission: Buy a comic, snap a photo, add it to your collection.

With that in mind the UX now looks a lot like a photo app that has been preconfigured for storing comic book metadata. Here are the most recent screen shots from my iPhone XS Max:

  • Summary View
  • Edit Series Popover
  • Detail View
  • Edit Issue Popover

Summary View

The Summary View displays a scrolling list of series. Each series displays the covers you have photographed. Right now I’m using placeholder covers–I don’t actually own the original Superman comics from the 1930s! This is all built with standard UIKit UIViewController and UICollectionView. I’ve added a custom UICollectionReusableView for the header of each section (series) and for the last cell of each collection I’m using a custom UICollectionViewCell.

I sort the comic book covers in each section by ID, which is a mashup of issue number and variant string. I sort these strings using localizedStandardCompare so that issue 2a comes before issue 20. I love localizedStandardCompare because I didn’t have do any work to solve the thorny “sort strings with numbers and letter as if they are numbers” problem.

The custom collection reusable view is mostly there to display the publisher, name, and era of a comic book series but also to host an edit button that brings up an EditSeriesPopoverView.

Popover views are cool but no longer supported as a presentation type by UIKit so you have to manually display them. I use a UIVisualEffectView to blur out the background behind the popover. I love it when I don’t have to write code!

Detail View

Each detail view displays a large image of the comic book cover photo and some metadata around it. The UISwitch sets the alpha of the cover image to 0.3 if false and 1.0 if true–this give you a nice visualization of what you still have in your collection and what you have sold.

The Edit button brings up the EditIssuePopoverView. I’ve figured out how to pass functions so that I can reuse popover views from different buttons: add an issue vs edit an issue. That’s very cool and has ramifications for how hardcoded view controller need to be to views.

Cutting Scope == More Value

This app looks nothing like my initial conception and has far less functionality than I thought I needed. I find this to be true with most apps I download. They do too much and don’t focus enough on their core use-case. Too much scope means the value of an app is diffused like the pixels behind a UIVisualEffectView.

As always you check out my code on GitHub!

Book Binder App Update: Variant Chaos!

I’m still working on that comic book collecting app! It’s starting to look and feel like a real app but still has a long journey of test driven development ahead of it!

Here’s what it looks like so far…

On the left is the Summary View and on the right is the Detail View. The summary view displays all the series and all the issues in each series that you are tracking. The detail view displays a particular issue, selected from the summary view. As I’ve complained, comic book publishers have little or no organizing skills and important identifying metadata is driven by marketing and whims. My app has to shoehorn a seriously fuzzy world of comic book print editions into data structures that can be sorted. This requires hard choices about how to organize comic book data so the user gets a usable app.

One of the biggest puzzles is what to do with variant covers!

Purchase a recent issue of any popular comic book, especially from Marvel, and you’re just as likely to get a variant cover edition as not. Marvel, as far a I can tell, doesn’t identify variant additions with a signifier. This is probably great marketing. There is some unknown number of variant covers for Fantastic Four #1 (volume 6, started this year 2018). I’ve counted 28 so far!

Hunting variants is like hunting Pokemon! You never know what is lurking in the next comic book shop. Some variant covers are created by famous artists, others feature famous moments or particular characters, some are specific to a comic book shop, and others are created for the dramatic effect of displaying all the covers side-by-side.

Faced with no official designation and a need to figure out what you may or may not own, comic book collectors and sellers have developed their own, local, ways of identifying variants, usually a single letter or string of letters, but also potentially any printable character.

After considering all this madness here is what my super sophisticated user experience for recording variant identifiers looks like…

There’s not much I can do to help the user other than provide some examples in the prompt and make sure she doesn’t add the same variant twice. I’ll probably find a way to list the current tracked variants, if any, and a way to add cover photo as well. But for now the simple text field does the job!

I think this is why general purpose productivity tools, that give people the work of organizing information in to a structure, usually seem easier to use than specialized apps like Book Binder. A simple spreads sheet could be built in minutes the job that my app is taking months to figure out.

I can’t easily use a spread sheet with my iPhone. I tried the iOS versions of Excel and Numbers and they are great for viewing but not so great for data entry or creation. Spread sheet are famous for being so open that errors in data and formulas are hard to detect. Squishy data like variant edition covers is easy to put in a spreadsheet but hard to test, hard to verify, and hard to maintain.

My long term hope is to use Apple’s MLCore Vision framework to identify variant editions on the user’s behalf. But that will only work if I work with a comic shop or collector who can tag all known variant editions and provide me with that data–or just make it available for free on a nicely scalable web server.

As always you can find the Book Binder Code on GitHub: https://github.com/jpavley/Book-Binder

Unit Tests Equal Awesome

I’m working on a hobby project iOS app that lets me track my comic book collection. I’m interested in comic books because all these super heroes from my misspent youth rule the world of popular culture. While the cool kids were playing sports and going to parties I stayed at home reading comic books. In college I stopped and found other things to do (computer programming, talking to humans, MTV). But now in the September of my life comic books are back and grip our imaginations tightly with their mutant powers.

I wanted to get back to the source. Where did all this cultural power come from? As I started buying physical comics again I realized I needed to track these objects of my affection on my phone. And I bet there are already dozens of apps that do this but I like to create my own tools.

Book Binder is the app and you’l find the code on GitHub.

Book Binder is an iOS app with a web backend. It’s an enormously long way from finished. I have lots of parts of it to figure out. The two current big problems are that comic book publishers can’t count and the number of comic books published is huge.

Comic book publishers can’t count!

Let’s take the case of Daredevil. One of my favorites as a teen and now a big show on Netflix. For reasons that are beyond comprehension (probably marketing) Marvel has restarted the numbering of the “man without fear” 6 times! Daredevil #1 was published in 1964, 1998, 2011, 2014, 2015, and 2017–and I don’t mean republished (that happens too). Daredevil #1 from 1964 is a completely different comic book from all the other Daredevil #1s in the five succeeding years! At one point Marvel tried to fix the problem with “legacy numbering” and that’s why the current series of DD started with #598 in 2017 instead of #29. I have no doubt in my mind that Marvel will start over with Daredevil issue #1 soon.

The other counting problem created by comic book marketing is variant issues with different covers. The most recent issues of Doctor Strange may or may not be published with different covers for the same issue. Collectors apply letters to each variant but Marvel doesn’t seem to have official variant designations. I have Doctor Strange #2 variant edition, legacy #392, second printing. I’m not sure how many variant editions were published or what the variant letter for each edition should be.

This counting (really identifying) problem makes it hard to come up with a good data structure for storing a comic book collection. I’m using a combination of a URI (unique resource identifier) and JSON (JavaScript Object Notation. This way I can easily share data between the iOS app and web server and with other comic book collectors, sellers, and buyers.

The number of comic books published is huge!

How many issues of Daredevil or Doctor Strange have been published since the 1960s? It’s hard to say. I estimate between 400 and 500 for Doctor Strange but I’m probably not including annuals, specials, team ups, side series, and all the variants. So let’s double that to 800 to 1000. And that’s the “master of the mystical arts” alone. If Marvel has around 200 books and DC has the same then we’re looking at a lower bound of 320K and an upper bound of 400K just for the two majors. Some of DC and Marvels comic books started in the 1930s and 1940s. If we include those and all the indy publishers (like Dark Horse) and all the publishers who have disappeared (like EC) then I’m going to estimate 1.6 million to 2 million unique comic books published in the USA. It’s really hard to say because it’s hard to know where to draw the line with publishers and if certain reprints should be included.

In any case I’m not going to be able to store more than a fraction of the millions of published comic book metadata representation in a phone. At best I can store a slice of this data locally and using any one of the big clouds to keep a shared catalog. I just want all this info to be quick to access, cheap to store, and easy to reconcile.

Testing an app for that

Let me tell you, creating an app, on my own, as a hobby project, is fun but hard. Like climbing a rock wall (which I would never personally do) you make a lot of false starts and have to retrace your steps trying to find a path forward.

This is where my unit test have helped. No, not helped. Made everything possible!

I started with three or four data structures. I’m testing out ideas and changing my mind as the idea do or don’t pan out. I’m not afraid to make large scale changes to my code because every function of every class has unit tests to make sure that if I break anything I can fix it.

Today I realized I had to take a big step back. I could not instantiate a comic book collection from a list of comic book URIs. I also realized I was storing state info in the comic book URIs which would not scale with millions of books to track. I finally realized that I had to enforce consistency in the formation of my comic book URIs (they all have to have four slashes). This way I could tell if a URI was mangled or incomplete.

I had to touch every one of my six major object that support my app… And I did! With Confidence. Once I removed state from my URIs and got all by unit tests to pass I fired up the app–and it worked fined. I had not added any bugs or broke any functionality. Whew!

If I didn’t have unit tests I’d be afraid to touch the code. I would be much more respectful of the code and I once I got some part of it to work I’d leave that part alone. As this is a lonely hobby project, I’d get stuck, give up, and move on to something easier.

Even with commercial software, with large teams of expert programmers, lack of tests and fear of changing the code, results in most software projects falling behind, abandoned, or just buggy.

I was sold on unit tests and Test Driven Development before and I’m resold every day I write code. I don’t care if you write the tests before or after the code that makes them pass (I do a bit of both). Just write the tests–especially if you are writing code for self-driving cars or robot military machines.

iPhone to the Max

I’m on that Apple program that where you pay for an iPhone over time and you get the opportunity to update immediately when a new model comes along, as it does every year.

While this is a very good deal for Apple, almost like a subscription service, it’s a good deal for me too. I hate the feeling of FOMO that comes along when a new computer, phone, or device is released. But with iPhones (and Android phones) it’s more than just a feeling. Missing out on the latest phone means missing out on important new features, security protections, and performance improvements.

FOMO used to be a big problem for personal computers as there were big performance jumps between PC models back when Moore’s Law was still in full effect. These days you can still get great results from a 5 year old PC or MacBook. Maybe you can’t play VR games but you email and browse the web like a champ.

Smart Phones are in a different place on the product evolution curve than PCs. They still have a long way to go before they settle down. Innovation in smart phones is driven by advances in displays, cameras, custom chips, and machine learning. Even incremental improvements in these technologies means far better user experiences, security, and even more epic cat photos.

I’m super happy with the jump between the iPhone 8+ and the XS Max. It responds faster, is easier on the eyes with its 6.5″ screen, and yet is basically the same size as the 8+. The name is kinda of silly. But I don’t care what Apple names their phones.

At some point phone hardware will cease to evolve and some new device will become our “primary interface” to the Internet. My guess is that it will be a watch of some sort with accessory glasses or screens. But these things are hard to predict.

I’m on the train as I type this post into my phone and one guy is still reading a paper news paper. I guess that iPhone XS Max just didn’t excite him.

Is It 1998 Again?

Set the Dial to 1998

Let’s power up the time machine and take a quick trip back to the wide world of tech around 1998. Microsoft was the Khaleesi of software and controlled a vast empire through Windows, Office, and Internet Explorer. Microsoft marched its conquering army of apps over the desktop and through the Internet with innovations like XMLHttpRequest, USB peripherals, and intelligent assistants.

All three of these innovations would go on to fashion the world we live in today with websites that look and feel like apps, devices that plug and play with our computers and phones, and helpful voices that do our bidding.

But back in 1998 these groundbreaking technologies were siloed, incompatible, and unintuitive!

  • You’d find that fancy web apps were usually tied to a specific browser (Walled Garden).
  • You’d buy a USB mouse and often find that it couldn’t wiggle your pointer around the screen (Standard Conformance).
  • You’d grow frustrated with Clippy (aka Clippit the Office assistant) because the only job it could reliably do was “Don’t show me this tip again.” (Poor UX).

And this is exactly where we are in 2018! Still siloed, incompatible, and unintuitive!

  • Do you want to run that cool app? You have to make sure you subscribe to the wall garden where it lives!
  • Do you want your toaster to talk to your doorbell? Hopefully they both conform to the same standard in the same way!
  • Do you want a super intelligent assistant who anticipates your every need, and understands the spirit, if not the meaning, of your commands? Well, you have to know exactly what to say and how to say it.

Digital Mass Extinction

The difference between 1998 and 2018 is that the stakes are higher and the world is more deeply connected. Products and platforms like Apple’s iOS, Google’s Cloud IoT Core, and Amazon’s Alexa existed in 1998–they just couldn’t do as much and they cost a lot more to build and operate.

In between 1998 and 2018 we had a digital mass extinction event—The dot com bubble burst. I was personally involved with two companies that didn’t survive the bubble, FlashPoint (digital camera operating system) and BitLocker (online database application kit). Don’t even try to find these startups in Wikipedia. But there are a few remains of each on the Internet: here and here.

Today, FlashPoint would be reincarnated as a camera-based IoT platform and BitLocker would sit somewhere between iCloud and MongoDB. Yet the core problems of silos, incompatibility, and lack of intuitive control remain. If our modern day apps, IoT, and assistants don’t tackle these problems head-on there will be another mass extinction event. This time in the cloud.

How To Avoid Busting Bubbles

Let’s take a look at the post-dot com bubble burst world for some clues on how to prevent the next extinction. After the startups of the late 1990s died-off in the catastrophe of the early 2000s the designers, developers, and entrepreneurs moved away from silos, proprietary standards, and complicated user experiences. The modern open standards, open source, and simplicity movements picked up steam. It became mission critical that your cool app could run inside any web browser, that it was built on battle tested open source, and that no user manuals were required.

Users found they could buy any computer, use any web browser, and transfer skills between hardware, software, and services. This dedication to openness and interoperability gave great results for the top and bottom lines. Tech companies competed on a level playing field and focused on who could be the most reliable and provide the highest performance and quality. Google and Netflix were born. Apple and Amazon blossomed.

Contrast that with the pre-bubble burst world of 1998 (and 2018) where tech companies competed on being first to market and building high walls around their proprietary gardens.

If we want to avoid the next tech bubble burst (around 2020?) we need Apple, Google, Amazon, and even Netflix to embrace openness and compatibility.

  • Users should be able to talk to Google, Siri, and Alexa in exactly the same way and get similar results (UX transferability).
  • Users should be able to use iOS apps on their Android phones (App compatibility).
  • Users should be able to share connected and virtual worlds such that smart speakers, smart thermostats, and augmented reality work together without tears (Universal IoT bus).

Google and Apple and Standards

At Google I/O last week the Alphabet subsidiary announced a few of examples of bubble avoidance features…

  • Flutter and Material Design improvements that that work as well on Android as they do on iOS.
  • AR “cloud anchors” that create shared virtual spaces between Android and iOS devices.

But sadly Google mostly announced improvements to its silos and proprietary IP.  I’m sure at the WWDC next month Apple announce the same sorts of incremental upgrade that only iPhone and Mac users will benefit from.

Common wisdom is that Apple’s success is build on its proprietary technology from custom chips to custom software. This is simply not true. When I was at Apple in the 1990s success (and failure) built on a foundation of standards, like CD-ROM, USB, and Unicode. Where Apple failed, in the long run, was where it went its own incompatible, inoperable, way.

In the 1998 the macOS was a walled garden failure. In 2018 macOS is a open source BSD Unix-based success. More than Windows, more than ChromeOS, and almost as much as Linux, macOS is an open, extensible, plug and play operating system compatible with most software.

The Ferris Wheel of Replatforming

Ask any tech pundit if the current tech bubble is going to burst and they will reply in all caps: “YES! ANY MOMENT NOW!!! IT’S GONNA BLOW!!!”

Maybe… or rather eventually. Every up has its down. It’s one of the laws of thermodynamics. I remember reading an magazine article in 2000 which argued that the dot com boom would never bust, that we had, through web technology, reached escape velocity. By mid-2000 we were wondering if the tech good times would ever return.

Of course the good times returned. I’m not worried about the FAANG companies surviving these bubbles. Boom and bust is how capitalism works. Creative destruction as been around as long as Shiva, Noah, and Adam Smith. However, it can be tiresome.

I want us to get off the ferris wheel of tech bubbles inflating and deflating. I want, and need, progress. I want my apps to be written once and run everywhere. I want my smart speaker of choice, Siri, to be as smart as Google and have access to all the skills that Alexa enjoys. I want to move my algorithms and data from cloud to cloud the same way I can rent any car and drive it across any road. Mostly, I don’t want to have to go back and “replatform.”

When you take an app, say a banking app or a blog, and rewrite it to work on a new or different platform we call that replatforming. It can be fun if the new platform is modern with cool bells and whistles. But we’ve been replaforming for decades now. I bet Microsoft Word has been replatformed a dozen times now. Or maybe not. Maybe Microsoft is smart, or experienced, enough to realize that just beyond the next bubble is Google’s new mobile operating system Fuchsia and Apple’s iOS 12, 13, and 14 ad infinitum…

The secret to avoid replatforming is to build on top of open standards and open source. To use adaptors and interpreters to integrate into the next Big Future Gamble (BFG). macOS is built this way. It can run on RISC or CISC processors and store data on spinning disk or solid state drives. It doesn’t care and it doesn’t know where the data is going or what type of processor is doing the processing. macOS is continuously adapted but is seldom replatformed.

To make progress, to truly move from stone, to iron, to whatever comes after silicon, we need to stop reinventing the same wheels and instead, use what we have built as building blocks upon which to solve new, richer problems, to progress.

 

Future Shock Reloaded

When I was a lad I would sneak into my father’s den and ransack his library. This was the early 1970s and I discovered all sorts of treasures, many of which I could barely comprehend, including The Godfather and even The French Lieutenant’s Woman. But the one book my pre-teen brain could parse was Future Shock by Alvin Toffler. I didn’t read the whole thing, too many pages! But I got the gist: “too much change in too short a period of time” is bad for us.

Toffler argued that human beings and culture just can’t keep up with the accelerating rate of modern technological change. For thousands of years we were farmers; for hundreds of years we were crafters; for decades we were factory workers, and now, what are we?

  • Last week we were web developers worried about search engine results.
  • This week we are gig-economy drivers living on apps for pickups.
  • Next week we’ll be data analysts mining Bitcoins on behalf of AIs.

Indeed, we’re getting those accelerating returns that Ray Kurzweil promised. Every week there is new technological anxiety adding to our already overwrought imaginations. Future Shock is back!

At home, at work, and on the road, I run into people worried about the impact of technology disruption on their careers, their health, and their spirits. And people have questions. Urgent questions that are difficult to answer but critical to understand in our Future Shocked world…

  • “Should I buy Bitcoin?”
  • “Will Robots steal my job?”
  • “Should I plug in an Alexa and allow it to spy on me?”

These are all great questions. And I don’t really have the definitive answers. But I have some ideas. The future is hard to predict but there are trends that we can look for and some basic laws of human behavior that we can count on. I’m going to share my answers below. I’m probably wrong but these answers are the best advice I can give.

Should I buy Bitcoin?

If you have to ask the question then the answer is probably “No.”

Buying or mining any cryptocurrency was a fun hobby in 2009. Today, Bitcoin and its friends Litecoin, Ripple, Dogecoin, Ethereum, et al. are basically a modern form of gambling and money laundering. If you have money you can afford to lose, and you’re not already in Las Vegas, go ahead, gamble on Bitcoin.

What we should buy as in buy into is Blockchain. It’s the future of how we’re going to contract with each other. There is a great book entitled Debt by David Graeber which explains that money is a social debt or obligation contracted between two parties. And these social contracts existed long before dollar bills, bills of sale, and other formal written contracts. Blockchain is the modern incarnation of social contracts as software. Blockchain is decentralized and open and part of a larger trend of “software eating the world.”

I bet in a decade or two almost every thing of value, including the labor of people like you and me, will be tracked and traded via blockchain-enabled smart contracts. Partnerships, concert tours, college educations, and even cute little human babies will hold ICOs (Initial Coin Offerings) and we’ll all invest in each other such that the rising or lowering tide of value we collectively earn (or mine) will be used to pay our debts.

Blockchain will make the value we create for society as individuals *fungible*. I’ll be able to buy a block of your creativity and you’ll be able to buy a block of my coding skill.

Will robots steal my job?

Yes… but it’s ok, you’ll get another job (if you become T-Shaped).

There is no industry, vocation, or advocation that will not be impacted by automation and machine learning. In only a few more years RPA, Robot Process Automation, will automate entry level and managerial tasks. Everything from buying toilet paper to approving expense reports will be automated by a narrowly smart bot—not a physical robot like R2D2. Telemarketing, accounting, retail, sales, driving, and even acting and singing will be automated so that the labor is cheaper, cleaner, quicker, and more reliable.

And we want this world of smart, unbiased robots, lowering costs and improving service.

My favorite example is the Amazon Go Store. No cashiers, no money, no lines, no rudeness, and no shoplifting. Sooner than we think the major retail stores will be crewed only by a store manager or two while cameras and sensors do all the other jobs. Not only cashiers but security guards, cleaners, stockers, and customer service jobs will be automated away or performed remotely.

Luckily, in the world of software engineering, we have a great deal of experience with automation-driven employment disruption. When I started coding in the 1980s I used low-level programming languages like Assembly and C, but most of the work was the *housekeeping* required to build, test, and deploy software. Today, while I’m still programming, the real innovation is in DevOps and Cloud Computing and all the ways they automate the software development process.

Software engineers like me have learned to continuously learn! We’ve also learned to stretch and try new types of jobs every few years so we remain relevant and employable. In the software world we call this being T-shaped. This means we know a lot about a lot of things in our general domain but we also have a specialization or two where we have expertise and experience.

No matter what kind of expertise or experience that you have now, that enables your employment, it will probably be automated away in a decade or two. However, your domain will remain and new areas of specialization requiring new expertise and experience will open up, creating new jobs and new opportunities.

Should I plug in an Alexa and allow it to spy on me?

Absolutely.

Choose a voice assistant, Alexa, Google, Siri, and learn how to take advantage of it as it learns how to take advantage of you.

You’re worried about your privacy and security. Me too! But ignoring or unplugging technology won’t protect us from corporate snooping or hacking. The best defense of our privacy and data is strong engagement with and deep understanding of the technology that surrounds us.

Decades ago, I lived in a world where we had to type at a computer to get it to do anything. Today, I mostly touch screens to get stuff done. But typing and touching isn’t any more secure than a Home Pod that listens for and responds to my voice. And these smart speakers aren’t mind readers. We have to learn how to talk to a computer as it has to learn how to understand us. Both get better with practice!

What about privacy? Personally, I don’t think we have privacy anymore. That ship has sailed away in a sea of cameras and microphones built into everything. But we do have anonymity. For the most part, unless a shadowy government agency is out to get you, your personal data is lost in the noise of trillions of packets of data bouncing around the Internet.

Can we trust big capitalist enterprises like Amazon, Google, and Apple? Well, they are big enough to be held legally accountable and regulated. They are interested in our money, not our souls. So trust.. but verify!

How I learned to stop worrying and love Future Shock

The world works by each of us influencing each other. The whole history of computer-enabled communication is just the most recent installment of the ancient arts of oratory and rhetoric. “Friends, Romans, and countrymen, lend me your ears” is the invocation of a conversation. Just like Amazon, Google, and Apple, Shakespeare is trying to influence you. Shakespeare had an agenda. Shakespeare was selling something but he was also listening for what you had to say.

I know that this is sometimes hard to believe, but the overall trend in the USA is that people are healthier, living longer, and generally wealthier, even when we consider all the conflicts, violence, and greed in the world. In the Neolithic Era we lived to 25 and died in the jaws of a tiger. In the Middle Ages we lived to 35 and died at the end of a lance. In the 21st century we live well into our 80s and have the Netflix Skip Intro Button. That button alone gives me hope!

It is technology that is making the difference: all that technology that we are anxious about; all that technology creating Future Shock.

An electrical shock only happens when you make initial contact with a charged wire. Don’t wait for the charge to build up. And once you make contact, one you embrace the future, stay connected so you can influence and own the future.

Meeting Madness

It’s only getting worse. And there is no cure. I’m talking about meetings. Most sapiens are natural social networkers. And that means we need to know what is going on, who is doing what, how it’s going to be done, where we’re doing it, and why we’re doing it this way and not that way. Often the meetings take up more time than the task.

I have over 30 years of meeting experience and I feel confident that we can do better. Here’s my advice for optimizing meetings, both from the point of view of an attendee and as an organizer.

Attendee

Look at your calendar! Back to back meetings. Double and Triple booked. No time for lunch or travel between meetings. No time for work or thinking. So you bring your laptop and work during the meeting, not paying attention until you are called upon. You bring your lunch and eat during the meeting. You find yourself day dreaming as you wait your turn to give an update for 5 minutes during a 60 minute meeting. You try to ask questions and argue points only to get dragged off topic as the meeting spirals out of control. I’ve experienced all this and I’ve done all this.

First, don’t skip lunch. Take 30 mins in the middle of every day to eat, meditate, or watch a video on clean coding. You need your energy to focus and participate.

Second, tell everyone who invites you to a meeting (even me) that you are short handed and likely to remain that way so they have to accommodate you (not the other way around). You need the option to leave early after your part is over. Sit by the door. Arrive on time and leave as soon as you can.

Third, request an agenda or list of topics that require your attention and attendance. Try to do the work and provide the info before the meeting and politely ask if you can skip it. There are only 131,400 working hours in an average lifetime. Make sure you’re not spending all those hours in meetings.

Organizer

Every once in a while I bet a co-worker has grabbed you at the end of a meeting and complimented you on what a productive and inspirational discussion you just led. What a great feeling! Every meeting you hold should meet that bar!

First, ask yourself if you really need this meeting. If you don’t cancel it. Even if it’s a regular status meeting. If everything is on track and you don’t need anything from anyone, kill the meeting. The best meeting is the meeting that never happened.

Second, plan your meeting. Supposedly there are six types of meetings: status update, info sharing, decision making, problem solving, brainstorming, and team building. Use this list to make sure you and your attendees are ready to have the meeting.

  • Status Update and Info Sharing: Tell folks they can skip the meeting if they get you the info you need before hand. Make sure you send out a report of all the collected status after the meeting and only those with something to contribute need to attend.
  • Decision Making: Provide the decision points and analysis before the meeting. Make sure you provide a report of action items and decisions made after the meeting so that everyone is on the same page afterwords–that way you don’t have to repeat the meeting!
  • Problem Solving and Brainstorming: Provide background beforehand and outline the process you’ll use to run the meeting. After the meeting write up the results and explain next steps.
  • Team building: Have fun and keep it short. Frequent, brief, fun activities build better teams than infrequent, all-day, somber off-sites.

Most meetings are combo meetings as in let’s share some status and then make a decision or let’s doing brainstorming and then some team building. I’m pretty sure combo meetings are a bad idea. Try to turn combos into separate meetings. If you can’t break them apart, provide a break between segments and a formal agenda so that attendees know which meeting-within-a-meeting they are in.

Third, direct your meetings. Every meeting should be structured like a great movie with a beginning, middle, and end. Every meeting should have a clear protagonist and antagonist. Every meeting should have a quest, that once achieved, signals that the meeting is over and everyone can go home (hopefully early). Keep your attendees alert and awake. Give them permission to leave after their part in the movie is over. Edit digressions and dissembling out of the movie. Ensure the meeting is meaningful to your attendees. That means stopping some people from chewing the scenery and calling upon other people to play their parts.

My Favorite Meetings

Every week I hold a staff meeting with my direct and some in-direct reports. I don’t care much for the org chart so the invitation list grows and shrinks as needed. Sometimes I do a great job and the staff meeting is truly like a movie. But much of the time I create a flop of a meeting. I’m trying to do better.

I’m inspired by the brevity and tightness of the meetings recommended by the Agile development process. I’ve found that, even if you are not writing code, a daily standup that lasts for 15 minutes and asks three questions (What have you done? What are you planning to do? Are there any impediments in your way?) works wonders for managing any sort of on-going issue.

The retrospective is another great idea to steal from Agile, especially for performance reviews: What is working? What isn’t working? What needs to change?

We spend so much time in meetings that I fear we’ve become complacent. If you’re anything like me, you mindlessly accept any meeting that comes your way and then wonder how you’ve completely run out of time.

Well, let’s stop the meeting madness. it begins with you and me!

The Voices of Software Development

The other day I was writing up a job description, which I take rather seriously, and I remembered that I needed to include the statement that an engineering manager has the responsibility to function as the “voice of the engineer”.

Then I sat back for a moment and thought,

  • Is this true?
  • Why can’t engineers speak for themselves?
  • And what about other constituents in the software development process?

Let’s look at each of these questions in turn starting with the last and working our way up.

The constituents of the software development process include the engineers working on the problem, the code being written, the system that the code implements, the users who happily (or unhappily) use these systems, and the business that one way or another pays for all of this activity.

The business tends to be the most powerful entity in software development. If you don’t have a business, even if that business is free software, then you don’t have any of the other constituents. The business is the organizing principle around which everyone else is invited to the party. Without the business nobody gets paid, whether that payment is in dollars, bitcoin, downloads, or GitHub stars.

Thus the business has evolved elaborate techniques to insure its voice is heard by all team members loud and clear. We call these techniques Waterfall, Agile, Scrum, Kanban, etc. And yet, many times the voice of business gets lost in the drive to complete the project, hit the deadline, keep costs down, or please the boss. Many times, being the loudest voice in the room means you get heard but not necessarily understood. From my perspective, it’s the job of the project manager, product owner, and engineering manager to make sure the business’s voice is both heard and understood. That means not just driving the team to deliver but to ensure the right sorts of tradeoffs are made between time, cost, quality, and scope. Even if it drives business stakeholders to complain in angry voices!

The user’s voice is usually the hardest to hear—unless you have actual users on the team. Even then, those users might not be representative of all users, or even the average user. Before the web, we didn’t have a reliable way to talk to thousands or millions of users directly. We had to hear their voices though focus groups, surveys, and experts. The results were often products likes the Ford Edsel or Windows Vista. Whisper Down the Lane is a dangerous game when you’re developing software. Luckily, we have this World Wide Web and the ability to test theories about the user’s voice directly. Generally, product owners and engineering managers take ownership of listening carefully for the user’s voice in the din of conflicting use cases and market requirements. But still, we’re completely surprised by what the user says.

I want to talk about the system’s voice and code’s voice together because they are often confused. In software development, the code is not the end goal; the code is a side effect of a process to get to the goal; that goal is a well-functioning system. You have to listen very carefully to hear the voice of the system because it’s not a person (not yet). Product owners, engineering managers, engineers, and architects all have a big responsibility to quiet their minds and meditate on the telltale whispers of a happy or sad system. A happy system scales easily up and down, is readily extended, responds quickly, and doesn’t consume more resources than it needs too. A sad system is just the opposite. Unfortunately, most systems are sad because hardly anyone is listening to them. Instead most of engineers look myopically at the code. You have can great code and still have a lousy system. You have terrible code and have a great system. Look at any well-functioning software product and you’ll find many areas of poor code and hasty hacks.

To hear the voice of the system you have to write tests, compare log files, profile disk, memory, and CPU usage, and monitor everything. It’s hard, time consuming, and your stakeholders will get cranky because the they and user didn’t explicitly ask for all this system work. Just explain to them that the bestest, fastest, prettiest car in the world isn’t going anywhere without roads and fuel.

What about the voice of the code? I love code. I listen to it very closely. Even though code is a byproduct of a process and not what the philosopher’s call teleological, it’s one of my favorite parts of software development. Code and the ability to hear what it has to say is what separates the engineer and engineering manager from the rest of the development team. I like to say, I don’t care what the code does, as long as it does it well! But that’s not quite true. Code for code’s sake is like an award-winning marketing campaign for vaporware.

Between the engineers, their managers, and the architects, there are plenty of people worried about the code, its styles, its elegance, and its fitness. Still, like the voice of the user, the voice of the code can get lost in the mad rush to fix P0 bugs and hit the end of the sprint—usually with deleterious downstream effects on the system and those users that everyone is supposed to be centered around.

At long last, we come to the voice of the engineers, those people that the engineering manager is supposed to speak for and represent. Why can’t they just speak for themselves? After all, nothing gets done if the engineers don’t code it! (We can’t yet compile and execute Photoshop UX designs.)

In small organizations, the voices of the engineers are very audible.

In large organizations, the engineers need an authority figure, someone with gravitas and political power, to make sure their voices are heard and understood by everyone demanding their time and attention.

Even though engineers have a lot of options these days, we’re living in Edsger Dijkstra’s software crisis:

“The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.”

With the cloud, we have infinitely gigantic computers and programming them has become an infinitely difficult problem!

To solve for that problem every business is hiring more and more engineers. But we know from Frederik Brooks that adding more people to a software project simply makes it more complex and harder to deliver.

Why is that? The more engineers, the more voices, the more discussions, the more POVs, the more time spent on negotiation, and the less time spent on listening to the code, the system, the user, and the business.

This is why I like Jeff Bezos’s formula for team size: the two-pizza team. In large groups the quiet people stay quiet and the outspoken people spend all the time talking instead of listening. If you can break up your software development work such a team of six people can easily handle it over a serious of iterations, then there is a good chance every voice on the team will be heard.

This is why the engineering manager, the architect, and the agile coach have to be the “voice of the engineer”—Not because engineer voices are ignored but because there can be so many engineers on a team that their individual voices get lost in the roar of the crowd.

A sharp-eyed reader will notice that I’ve linked the engineering manager to every node in this graph of voices. A good engineering manager is usually the only team member technical and experienced enough to hear all the voices and try to balance them out. Of course, not every engineering manager remembers to do this. Often, we get lost listening to the loudest voice or the voice we like the most (our own). The trick is to stop talking long enough such that you have the time to invite other constituents to speak.