vanderwal.net

Vibe Markets Don’t Always Rhyme with Good Product

My recent Four Cornerstones of Development post (which I found the initial blog mention on a March 2001 archive page - Off the Top :: March 2001 and later on mention I’m working on an essay on it, which I somewhat remember having a publication ask me to write it for them, but no longer exists) was surfacing in discussion a bit lately when talking with those building quick things for themselves that they had used LLM for coding (as well as much of the interaction and visual design), which is viable for personal use for a stretch and then you hit the reliable, maintainable, repeatable thresholds of pain.

Ooh! This Looks Interesting

But, I’ve looked at a quite a few of these projects (not those that aren’t really products) as they initially seem like they would solve a use case gap I have. But, I saw a video for an app that was pitched and it hit a long-standing need I had that has heavy friction. It was an app that linked to Glaze, which is a product / service from Raycast. I read through the information about Glaze and thought this could be “interesting”. I had trouble finding the app that caught my interest as the Glaze app marketplace is a mess. I finally found the app, looked at the descriptions and images and figured I’d give it a go. I found I had to download the Glaze app to seemingly run the app I wanted within Glaze. This was less than optimal putting a silo wrapper around apps, that has never worked well and there is a long and abundant history of attempts at this poor model. (An app with scripts and workflows that can be added through a marketplace / gallery like Raycast or Alfred is a good model, but full apps that is a very different story).

The Needed Perspective Framing (Likely to be skipped to preserve a rant)

I’m not adverse to people using coding assistance, but there is a lot more to building an app or script than just code (and often being a developer or engineer helps keep the AI coding assistance in check as they can resurface long gone poor practices that are abundant in the training material). Not having background in development nor product management nor design creates a lot of gaps and little depth to know if something is actually good or not.

I’ve Seen this Movie Before and …

I opened Glaze and got the app I had interest in set up, and it was slow, not well considered with limited functionality that would be helpful for a basic app in the genre it sat in. The hope I had was shot, I was rather disappointed (it happens a lot) with the level of a “proof of concept” build that only examines is something possible to let you then you interrogate the hell out of it to figure out what is wrong and how to improve it before you get to the prototype or alpha version. I shut the app and won’t open it again.

I looked at other apps in Glaze. All I looked at had the same level of quality (or I should say lack of quality and basic understanding of what an app is, let alone what a product is).

I jumped to the four cornerstones, as I would on something I was building or running a product group that is creating and developing. Things were sort of usable, but half a cornerstone doesn’t get you very far. There is a lot to know and understand beside an interface that does something and I haven’t found AI services that fill much of this ground that needs to be covered in a solid manner. They can help code decently on small-ish projects (and slightly larger) and get okay (yet often problematic) interfaces. But, the other considerations and forward-looking needs to plan for or at a minimum consider so to account for future adaptation are missing or not supported well. The person building has to bring that understanding with them to drive this to a decent outcome.

Creating an app seems easy but there is a lot that should be considered and accounted for in the process, even for something simple. Putting out what will soon be abandoned ware with a “developer” / creator that didn’t quite ship something solid and left it at that, and not to return.

It May be an Idea Farm

There are a lot of great ideas in Glaze, but the lack of quality has me deleting the Glaze and adding a reminder to not go back. The deletion of Glaze took around 2 hours as the thorough app deletion tools I have were getting errors from many components claiming deletion was not permitted. This often happens when an app is running, but the app had been quit. It has been a long time since I’ve had to go through rounds of rebooting my Mac to rip out stubborn poor app remnants.

Know What You are Getting In To

There are people who have been building good niche products that have used AI to help fill gaps. Most of them have a lot of experience with UI, UX, product, and/or development to know what needs to be done at least at a basic level. Not all of them have worked through all four cornerstones, but they have considered them, and have lived through the hell from not considering and/or working through the cornerstones.

Four Cornerstones of Development

In the late 1990s through 2010s when working with development and product teams the four cornerstones of development were always at the tip of the tongue or as a small poster on a wall somewhere. I know I wrote this up somewhere before and likely presented it in the late 1990s and/or early 2000s. Working in enterprise environments where people would get involved in product and development, but don’t have background these cornerstones were essential to bring up as basics.

The last few weeks and months I’ve been thinking of this a lot and wanting to point to it, but realized it isn’t really on line other than a quick mention in a 2003 post of mine – Needs When Running a Service. Actually, it is something I am always wanting to point to. With the increase of vibe coding and people creating products for “unique” purposes, but then people are sharing these more widely than personal use, the need for understanding and considering what they are getting into is really needed.

The Four Cornerstones of Development

These four cornerstones were initially called out for information application development, but applied to all user-centered development and product management. If a team building didn’t focus on all four of the elements from the beginning to make the right decisions early (or have them framed and adaptable) the product was really going to struggle.

The four elements are: Usable; Reliable; Maintainable; and Repeatable.

In the current state of quick development by non-developers using LLM coding tools the only one of these cornerstones that is known or partly handled is the first cornerstone, usable. What is made may be usable, or mostly usable, but that won’t really last and when selling it, sharing it widely, or having others rely on it. The reality means the person developing and shipping has unintentionally signed up for things they don’t have background in and often the LLMs aren’t that helpful with. Much of what is coming out as apps are proof-of-concept level of completion, which doesn’t get into any consideration of the other three cornerstones.

Usable

Usable is the first hurdle and focusing on the user and their needs. If things aren’t usable the offering doesn’t really have much. The other cornerstones don’t really matter, if the offering isn’t usable. But, usable and not having the other cornerstones will be problematic.

To be usable, even if it is a single simple use case, how adjacent use cases that aren’t supported are handled or avoided should be as clear as possible. The capabilities and limitations being clear help with the ease of use and understanding something when someone hasn’t touched it in months.

Reliable

The reliable cornerstone is what starts making the offering stable, secure, and enduring. The bugs have been remediated and it works as intended continually. Security and levels of privacy considerations have been put in place and consistently work as intended. But, so do the core myriad of use cases that were intended to work and also be supported, continue to work.

Lacking reliability you have something that breaks at various stress levels and use cases (core uses cases or edge cases). Building and shipping requires setting bounds for what is supported and how, but also how well the edges of what is supported are handled.

Maintainable

Maintainable gets to the reality that products and shipping them doesn’t mean something is done when shipped, it is the beginning. When planning out what is being built how it will be maintained over time and supported is essential. How will the product be updated to support changes to the coding language and/or operating system, and device updates. How do the regular changes in languages and operating systems get handled where security patches are made and break apps and services for users that use apps and services that aren’t updated.

User / customer support and how this is handled also falls into the maintainable cornerstone. Planning for maintainability and how that will be handled needs to include support as the two are often tightly related. When something breaks or doesn’t work as expected, that becomes support work. The support work is often related to considerations and steps (or not making them) the area of the maintainable cornerstone.

Repeatable

Repeatable is one that often gets left of consideration and one that is essential if what you built gets popular and scale. It is often thought of as something that may happen in the future, but understanding early on how to handle repeatability means it should be easier when the time arrives. Repeatability is needed when a server or service built on crashes and is not available or you need to replicate server backends for supporting the service as it scales (there are a lot of needs for repeatability, including building sandboxes to test and develop).

Everything changes as it scales and understanding that at the start of everything (product, organization creation, shared simple scripting project, etc.), gives a decent foothold to when growing and scaling hits. Planning not to scale is also an option, but often that can take just as much work as scaling and you need to be prepared for not scaling when others really want what you’ve made.

Not planning for this early and accounting for how to design the development of the app and/or services for this will lead to painful issues with growth or the reality of moving from one supporting backend server / service to another as things change (often more quickly than we expect).

Wrapping the Cornerstones to Help Make Decisions

The cornerstones were really helpful 20 to almost 30 years ago for a quick reality check for early early-stage planning and building something to ship. Building something and shipping it is the start, not the end. All four cornerstones will provide stability once things are shipped if you have planned understanding and using the cornerstones.

Today, much like early-ish web thinking of how far you want to open something up for use by others comes from considering the cornerstones. If all that is considered is just use and there is no interest in the other corner stones or just partial interest or capacity, it is likely good to keep the use of it limited to friends and or family, similar, or perhaps tighter.

Google Plus Social Model Facepalm

I was watching Vergecast this week, (Google’s AI shake-up: What’s next for Demis Hassabis and DeepMind | The Verge) and in it David Pierce brought up Google+ again. Pierce uses it as a call out when large organizations jump into things they don’t fully understand.

Google had some understanding, but the biggest problem was their going with “Circles”. Circles were akin to groups, but the Circles were largely a construct from a user’s perspective. The individual leaning perspective of “Circles” is really odd and broken as each person has a different idea around who should be or is in a Circle, but also what gets shared in and out of the Circle. There were semi-closed groups / Circles but the boundaries weren’t clear at all. Who was in a Circle? What could be shared out (seemingly most anything) and its lack of clarity was deeply problematic as it was very porous.

A core element of social that is closed or semi-closed groups have very clear boundaries. Knowing how those boundaries work, who is allowed in, and the process to get allowed in. Google+ started at a time when those running social platforms were becoming abundantly aware there were some really toxic people and had learned how to handle them (to some degree). Google+ started with a foundation that made it really difficult to handle this, but also lacked the well known concepts to have clear boundaries for groups and interactions.

When you talked with anybody if they were using Google+, who were in many other platforms that were either fully open (like Twitter), and in closed group environments where the boundaries were clear and methods for dealing with bad actors (intentionally bad or accidentally) in clear means. The lack of comfort with the who and what is done with what is shared in Circle had a lot of people really uncomfortable with the oddly structured Circles.

Google+ didn’t last long and is long enough ago that it doesn’t come up often. Occasionally the Google+ getting woven into the Google applications like Sheets and Docs brought the really odd social structure with it, which made things really odd. Other services have done really well integrating these, but they have really solid and structured boundaries and groups with clarity as the core.

While I am one of the odd ones who really enjoyed Google Wave - Wikipedia and its wild flowing stream of interaction, the odd Google+ is one I don’t miss. Hearing David Pierce bring up Google+ and how always makes me chuckle. I always wish Google had spent time to sort out Google+ properly, but that didn’t quite happen.

The Poetry of Time

Today a package arrived that I’ve been deeply looking forward to. Part of the anticipation is the pure utter whimsy of it, part is it was a Kickstarter project that involved hardware (read hardware is hard when manufacturing is involved), and knowing the creator and watching all the steps along the way I was happy to see it and touch it. This is the Poem/1.

Most of all, this device is giving me a lot of enjoyment and, well, glee.

The Poem/1 Arrived

This poetry clock in the few hours I have had it running, with its e-ink display that updates every minute with a new poem for the time, which is / was generated by AI. Some of the poems are, well unique, and others are wonderful, but they can be favorited with the one button on the device.

The one button does a lot of work. It can be used to favorite a poem. There is a site with a dashboard for your device where you can push it notes you write to display, but to clear the note and get back to the clock you use the one button. There is a sleep mode with a screen saver and to clear that, you use the one button.

The Poem/1 also has one USB-C cable. There is no manual in the box. Everything you need is the new Poem/1 device, the USB-C cable, and the e-ink screen tells you the rest.

After plugging it in you get a screen with some technical details and a QR code and using your phone with the QR code it then walks you through everything from easily connecting it to your WiFi (if printers could do this…), then make a selection or two and you have poetry time. There is also a dashboard website and the setup to your device is incredibly easy as is the setting up the account on that site.

The Journey of Poem/1

About 3 years ago Matt Webb blogged about an idea he had about an AI poetry clock, My new job is AI sommelier and I detect the bouquet of progress (Interconnected). This soon got connected to an e-ink device and Matt was on his way.

Matt setup a Kickstarter, which I happily backed. It wasn’t that I was overly keen with the AI bits (I’ve been working with AI/ML going back to 2008 and stayed current and it is a thing that I treated, like most everything else, as a tool). But I enjoyed the process of little printer – BERG and its outcome from afar. Having watched Little Printer’s journey of toil to come to life from Berg London (Matt and the amazing folks there), I wanted to support Matt (who mostly did this Poem/1 project alone). This provided insite into his long journey of quickly getting to a working prototype, then the slog of finding viable parts, a manufacturer, various regulatory approvals, and iterations when due to various things there were changes made late mid-stream to add to the delays.

Matt has done a good job logging his slog and journey. There were times where I’d realized I’d forgotten about Poem/1 and not heard of any progress in a while. About that time Matt would have an update in Kickstarter or on his blog.

Then there was US Customs, which stalled things for a while (not the tariffs, which became a hurdle earlier), but there there was more paperwork needed around “what is this clock”, oddly I (the customer) was sent the forms and I knew there wasn’t a winding mechanism nor jewels in it (well I haven’t checked inside, but pretty sure there are no jewels). Matt did a great job documenting the US Customs documentation hurdle in his post, How global logistics got me over my fear of personal agents (Interconnected) (my having worked at a Custom’s Brokerage for a few years I know the many reasons brokerages are needed).

What Time Is It?

I love the ability to favorite a time. (What is your favorite time?) In a few hours I have a couple favorites that I quite like:

Puddles reflect lost skies, / At two forty-five, heart sighs.

At twelve fifty, shadows creep, / Secrets held within silence deep.

Willow branches gently sway, / It’s twelve twenty-five today.

Thank you Matt I now have favorite times and a wonderful product.