Paul Kedrosky and Eric Norlin of SK Ventures wrote an interesting and important essay titled Society’s Technical Debt and Software’s Gutenberg Moment.
The abstract follows. I encourage you to read the full essay.
There is immense hyperbole about recent developments in artificial intelligence, especially Large Language Models like ChatGPT. And there is also deserved concern about such technologies’ material impact on jobs. But observers are missing two very important things:
This technical debt is about to contract in a dramatic, economy-wide fashion as the cost and complexity of software production collapses, releasing a wave of innovation.
Until six weeks ago, my favorite software product of all time was Lotus Agenda. We ran my first company (Feld Technologies) on Lotus Agenda from when the first version of Agenda came out sometime in 1990 to when we sold the company in 1993. If you aren’t familiar with Agenda and want a quick, readable description, take a look at AGENDA: A Personal Information Manager (Belove, Drake Kaplan, Kapor, Landsman).
Agenda was the brainchild of Mitch Kapor (and several others) and, after Lotus killed it off in the time of a transition to Windows (Lotus Organizer was not an adequate Windows replacement), there was an effort (again led by Mitch Kapor) to recreate it with an open-source project called Chandler that never came to fruition.
Agenda is the only product that augmented my brain and how I think until I started using Roam on 9/11/20.
Since then, as I got up the learning curve on how to use it, I’ve found it amazing. It’s evolving rapidly, so there are lots of neat new features that show up on a regular basis. There are many integrations with other stuff, and, while a bunch of them are rough, several of them (like Readwise) solved a fundamental “notetaking while reading” challenge that I’ve had since the Kindle first appeared.
I use a lot of different software.
Nothing has had as much impact on me since Agenda as Roam. I’m sure I’ll be writing about it more in the future.
And, a post like this wouldn’t be complete without a thank you to Mitch Kapor. I have several entrepreneurial heroes. Mitch is one of them. Lotus Agenda is only one thing among many that I’m thankful to him for.
I’m been looking around for software to help me manage an increasing number of affinity networks. These are networks that I’ve created around different topics, such as the books I’ve written – like Startup Communities and Venture Deals – as well as topics I’m exploring with small to medium sized groups of people.
So far I’ve tried a bunch of stuff and have ended up back at email groups, which is the least common denominator. I’ve tried a few different products for email groups and always end up back at Google Groups, which is fine, but extremely uninspiring in terms of anything beyond “creating the group” and “sending around emails.”
I’ve tried Facebook, LinkedIn, and Slack. None of them work. I’m now completely off Facebook, so that’s not really an option anymore. LinkedIn is way too LockedIn and has serious limitations. Slack is a messy nightmare that has a geometric decline curve of activity.
Any suggestions out there?
The word “platform” used to mean something in the technology industry. Like many other words, it has been applied to so many different things to almost be meaningless.
Yesterday, when I started seeing stuff about the MacOS High Sierra blank root password bug, I took a deep breath and clicked on the first link I saw, hoping it was an Onion article. I read it, picked my jaw up off the floor, and then said out loud “Someone at Apple got fired today.”
Then I wondered if that was true and realized it probably wasn’t. And, that someone probably shouldn’t be fired, but that Apple should do a very deep root cause analysis on why a bug like this could get out in the wild as part of an OS release.
Later in the day, I pulled up Facetime to make a call to Amy. My computer sat there and spun on contacts for about 30 seconds before Facetime appeared. While I shrugged, I once again thought “someone at Apple should fix that once and for all.”
It happened again a few hours later. Over Thanksgiving, I gave up trying to get my photos and Amy’s photos co-managed so I finally just gave all my photos to Apple and iCloud in a separate photo store from all of Amy’s photos (which include all of our 25,000 or so shared photos.) I was uninstalling Mylio on my various office machines and opening up Photo so that the right photo store would be set up. I went into Photos to add a name to a Person that I noticed in my Person view and the pretty Apple rainbow spun for about 30 seconds after I hit the first name of the person’s name.
If you aren’t familiar with this problem, if you have a large address book (like mine, which is around 20,000 names), autocomplete of a name or email in some (not all) Mac native apps is painfully slow.
I opened up my iPhone to see if the behavior on the iPhone was similar with my contacts and it wasn’t. iOS Contacts perform as expected; MacOS Contacts don’t. My guess is totally different people (or teams) work on code which theoretically should be the same. And, one is a lot better than the other.
At this point, I realized that Apple probably had a systemic platform layer engineering problem. It’s not an OS layer issue (like the blank root password bug) – it’s one level up. But it impacts a wide variety of applications that it should be easily abstracted from (anything on my Mac that uses Contacts.) And this seems to be an appropriate use of the word platform.
Software engineering at scale is really difficult and it’s getting even more, rather than less, challenging. And that’s fascinating to me.
If there’s one consistent concern I hear from the companies I work with, it’s the shortage of qualified tech talent. But just like in so many other areas, a Boulder entrepreneur has come up a great idea to address the problem that not only adds to the talent pipeline, but also brings in more diversity — a personal passion of mine.
Too often, aspiring engineers who lack the funds to pursue a computer science degree from a university or take part in a bootcamp find themselves locked out of technology jobs, despite often severe talent shortages. Think about it: if you need to pay rent and buy groceries, it’s pretty tough to quit, or work part time, and pay either tuition or boot camp fees. To address this, Heather Terenzio, founder and CEO of Boulder’s Techtonic Group, developed Techtonic Academy, an innovative solution in the form of Colorado’s first federally recognized by the Department of Labor technology apprenticeship. Rather than paying thousands in tuition or fees, qualified individuals can get their foot in the door to a tech career while earning a salary from their very first day.
Techtonic Academy provides underprivileged youth, minorities, women, and veterans both technical training and mentorship to become entry-level software engineers and pursue a career in the technology field. It works like this: the program looks for people with an interest in and aptitude for tech but little or no formal training — think gamers, self-taught hobbyists and the like — and puts them to work as apprentices. They work with senior developers to gain coding experience on real client projects under careful guidance and supervision while earning a livable salary. They are required to earn a series of accreditation badges covering coding skills and are constantly mentored in “soft” skills — things like being on time or working effectively on a team.
After about six months, graduating apprentices are qualified junior developers, ready to work. Some choose to stay at Techtonic Group, where they become part of a team to build custom software, mobile applications and content-managed websites, while others move on to Techtonic Group clients. If a client hires an apprentice, Techtonic does not charge a conversion fee, which can run into the thousands for a junior developer hired through a traditional recruiter.
As Heather told me, “I have an Ivy League education, but that’s not where I learned to code. I learned to code doing it on the job.” I think many software developers share that sentiment.
Heather welcomes all technology hopefuls and works hard to bring diversity to the program, recruiting women, veterans and those who aren’t in a financial position to quit work to pursue a degree or certificate. The benefits are obvious. Apprentices earn a living salary on their first day, and we as a tech community can support a program that puts more coders in the market with a keen eye toward diversity and opportunity while getting work completed.
Heather’s got a great idea and it gives all of us the chance to both find help on projects and add new, diverse talent to our community. Reach out to Heather if you’d like more information.
There are two common email conventions in my world that I use many times a day in Gmail. I don’t remember where either of them came from or how much I influenced their use in my little corner of the world, but I see them everywhere now.
The first is +Name. When I add someone to an email thread, I start the email with +Name. For example:
+Mary
Gang – happy to have a meeting. Mary will take care of scheduling it.
Now, why in the world can’t gmail recognize that and automatically add Mary to my To: line? If I needed to do “+Mary Weingartner”, that would be fine. Gmail is supposed to be super smart – it should know my address book (ahem) or even my most recently added Mary’s and just get it done.
The other is bcc: Whenever I want to drop someone from an email chain, I say “to bcc:” For example:
Joe – thanks for the intro. To bcc:
Pauline – tell me more about what you are thinking.
Then, I have to click and drag on some stuff in the address field to move Joe from the To: line to the bcc: line.
Dear Developers Working On Email Clients Of The World: Would you please put a little effort into having the email client either (a) learn my behavior or (b) Add in lots of little tricks that are common, but not standard, conventions?
I hate doing “reflections on the last year” type of stuff so I was delighted to read Fred Wilson’s post this morning titled What Just Happened? It’s his reflection on what happened in our tech world in 2014 and it’s a great summary. Go read it – this post will still be here when you return.
Since I don’t really celebrate Christmas, I end up playing around with software a lot over the holidays. This year my friends at FullContact and Mattermark got the brunt of me using their software, finding bugs, making suggestions, and playing around with competitive stuff. I hope they know that I wasn’t trying to ruin their holidays – I just couldn’t help myself.
I’ve been shifting to almost exclusively reading (a) science fiction and (b) biographies. It’s an interesting mix that, when combined with some of the investments I’m deep in, have started me thinking about the next 30 years of the innovation curve. Every day, when doing something on the computer, I think “this is way too fucking hard” or “why isn’t the data immediately available”, or “why am I having to tell the software to do this”, or “man this is ridiculous how hard it is to make this work.”
But then I read William Hertling’s upcoming book The Turing Exception, remember that The Singularity (first coined in 1958 by John von Neumann, not more recently by Ray Kurzweil, who has made it a very popular idea) is going to happen in 30 years. The AIs that I’m friends with don’t even have names or identities yet, but I expect some of them will within the next few years.
We have a long list of fundamental software problems that haven’t been solved. Identity is completely fucked, as is reputation. Data doesn’t move nicely between things and what we refer to as “big data” is actually going to be viewed as “microscopic data”, or better yet “sub-atomic data” by the time we get to the singularity. My machines all have different interfaces and don’t know how to talk to each other very well. We still haven’t solved the “store all your digital photos and share them without replicating them” problem. Voice recognition and language translation? Privacy and security – don’t even get me started.
Two of our Foundry Group themes – Glue and Protocol – have companies that are working on a wide range of what I’d call fundamental software problems. When I toss in a few of our HCI-themes investments, I realize that there’s a theme that might be missing, which is companies that are solving the next wave of fundamental software problems. These aren’t the ones readily identified today, but the ones that we anticipate will appear alongside the real emergence of the AIs.
It’s pretty easy to get stuck in the now. I don’t make predictions and try not to have a one year view, so it’s useful to read what Fred thinks since I can use him as my proxy AI for the -1/+1 year window. I recognize that I’ve got to pay attention to the now, but my curiosity right now is all about a longer arc. I don’t know whether it’s five, ten, 20, 30, or more years, but I’m spending intellectual energy using these time apertures.
History is really helpful in understanding this time frame. Ben Franklin, John Adams, and George Washington in the late 1700s. Ada Lovelace and Charles Babbage in the mid 1800s. John Rockefeller in the early 1900s. The word software didn’t even exist.
We’ve got some doozies coming in the next 50 years. It’s going to be fun.
My post on How to Fix Obamacare generated plenty of feedback – some public and some via email. One of the emails reinforced the challenge of “traditional software development” vs. the new generation of “Agile software development.” I started experiencing, and understanding, agile in 2004 when I made an investment in Rally Software. At the time it was an idea in Ryan Martens brain; today it is a public company valued around $600 million, employing around 400 people, and pacing the world of agile software development.
The email I received described the challenge of a large organization when confronted with the kind of legacy systems – and traditional software development processes – that Obamacare is saddled with. The solution – an agile one – just reinforces the power of “throw it away and start over” as an approach in these situations. Enjoy the story and contemplate whether it applies to your organization.
I just read your post on Fixing the Obamacare site.
It reminds me of my current project at my day job. The backend infrastructure that handles all the Internet connectivity and services for a world-wide distributed technology that was built by a team of 150 engineers overseas. The infrastructure is extremely unreliable and since there’s no good auditability of the services, no one can say for sure, but estimates vary from a 5% to 25% failure rate of all jobs through the system. For three years management has been trying to fix the problem, and the fix is always “just around the corner”. It’s broken at every level, from the week-long deployment processes, the 50% failure rate for deploys, and the inability to scale the service.
I’ve been arguing for years to rebuild it from scratch using modern processes (agile), modern architecture (decoupled web services), and modern technology (rails), and everyone has said “it’s impossible and it’ll cost too much.”
I finally convinced my manager to give me and one other engineer two months to work on a rearchitecture effort in secret, even though our group has nothing to do with the actual web services.
Starting from basic use cases, we architected a new, decoupled system from scratch, and chose one component to implement from scratch. It corresponds roughly to 1/6 of the existing system.
In two months we were able to build a new service that:
Suddenly the impossible is not just possible, it’s the best path forward. We have management buy-in, and they want to do the same for the rest of the services.
But no amount of talking would have convinced them after three years of being entrenched in the same old ways of doing things. We just had to go build it to prove our point.
Orbotix just released a new version of the Sphero firmware. This is a fundamental part of our thesis around “software wrapped in plastic” – we love investing in physical products that have a huge, and ever improving, software layer. The first version of the Sphero hardware just got a brain transplant and the guys at Orbotix do a brilliant job of showing what the difference is.
Even if you aren’t into Sphero, this is a video worthwhile watching to understand what we mean as investors when we talk about software wrapped in plastic (like our investments in Fitbit, Sifteo, and Modular Robotics.)
When I look at my little friend Sphero, I feel a connection to him that is special. It’s like my Fitbit – it feels like an extension of me. I have a physical connection with the Fitbit (it’s an organ that tracks and displays data I produce). I have an emotional connection with Sphero (it’s a friend I love to have around and play with.) The cross-over between human and machine is tangible with each of these products, and we are only at the very beginning of the arc with them.
I love this stuff. If you are working on a product that is software wrapped in plastic, tell me how to get my hands on it.