Earlier this week I was at the TailscaleUp event in London and one of the panels raised that we are losing sight of how long work actually takes. This also connected with the idea that in this new AI future there will be 100x more builders. That means there will be 100x more people who’ve never felt the gap between a working prototype and a production-ready product, and AI has vastly reduced the barriers to building, but there are still some hard things that need to be understood.
Someone who’s a true subject matter expert carries that field in their bones, and so knows whether a task will eat two hours, a day, or a few days, with all the time factored in of what could go wrong. That’s reliant on the fact that they know the field inside out, and so it’s done to a high standard, whereas someone who doesn’t know the area could maybe do it in a day, but it’s not going to be anywhere near that standard of the other person (with or without AI).
It’s a bit of a self-reflection, because I’ve been the one going, “oh, it didn’t take that long to do this”. The most recent one for me is mobile app development, which is not something I ever thought I’d look into, and I’ve only been exploring it for the last three weeks, and so I very much do not know the challenges with it.
After building an Android app for the first time for a hackathon, I started to look into how I could do more with this. The builds themselves have been going at a good pace for me, and so I’ve also started to investigate porting Android to iOS, which before the world of AI would have been a large decision after doing real research, due to the cost of the work itself and everything around it. However, right now, looking at two very different Android apps I made, I’ve got massively different expectations. The first conversion was a simple app that was just pulling data and presenting it, and it was able to use the same codebase of TypeScript, so it was a few hours and ready to go. The second was very much involved with Android, being written in Kotlin and needing access to hardware components, lock screen access and so on, and so I’m having to basically rebuild everything from scratch, which has taken over a day if not longer and it’s still running. If I had been doing mobile dev before, this would not be new information and my planning approach at the outset may have been different, but it is just one example of someone not really knowing the true cost of their decisions.
The visible build is only one part of the work involved in moving an app between platforms.
This is before we even start worrying about the other problems outside of it. When I went to Semaloop’s “From Build to Launch” panel last week, an important thing which they raised, which I agree with, is that the issue isn’t really making the app, it’s getting it on the store and keeping it on the store, and it can take days and days and days just of back and forth to get something on there. I’ve signed up to Google Play, and it was something I was concerned about when I was doing the application, and so I made sure I sat down and properly did it and, being very millennial, got the laptop out and everything. I haven’t actually put my app in the store yet, and going to that talk has shown me that maybe it’s going to take a lot longer than I expected, and that’s before making sure there’s a proper testing suite for it, or that it’s something doable for other people to work within. That’s why in most companies you have a whole separate mobile app team, and a lot of their work is literally just making sure the app can stay relevant in the store and keep up to date.
In a small company that’s not something you can have resource-wise, and with a personal one the only person maintaining it and the time being wasted is mine. When you’re thinking about a company, then what is the actual business case for it, and does it really make sense? That goes back to the old POC-to-prod kind of issue, where it’s ready to use as localhost and there is considerable effort required to make it to prod, with the timelines and rigour to make it safe. Just because you’ve built a POC doesn’t mean you’ve built prod, and people don’t actually have the empathy for that when they’re like, “oh, I made this, it’s easy”.
A working span is not the same thing as finished infrastructure.
Just because it works is great until it falls down, and then who’s going to be the one picking up the pieces, and who’s the one that’s maintaining it afterwards? I feel sorry for many people who are now having to start maintaining all of these creations that are being made by AI, and I am not one to speak about glass houses, as I’m still on that road and need to learn more.
However, once I get the two apps to a relative feature parity, hopefully it shouldn’t be too bad, because then it could just do a sync where possible, but that’s now a massive workload addition for maintenance, and if someone asked me how long it could take, I don’t really know.