mike.mainguy

Lost in Translation: Now With More AI Setting: Conference room. Morning. Coffee cups. One says “Disruptor.” The executive has just returned from a tech conference. The architect has just returned from debugging a production issue involving a single missing comma. 🎬 Scene 1: The Grand Vision Executive: "Hey! Quick sync. Big idea. We’re going AI-first." Architect: "Okay. What does that mean?" Executive: "It means we start with AI. You know—intelligent by default." Architect: "Like personalization? Recommendations? Chatbot support?" Executive: "Yes, yes, and yes. But simple. Frictionless. Invisible AI." Architect: "So... AI that does everything but nobody notices?" Executive: "Exactly! Like Netflix meets ChatGPT, but for our business." 🎬 Scene 2: Vibes-Based Strategy Architect: "Do you have a specific user flow in mind?" Executive: "Not ...

Strategy or Tactics? A Quick Gut-Check for Busy Builders Most teams move fast, talk louder than their calendars, and badge every decision as “strategic.” Speed feels good, and “strategy” sounds grown-up. The result is a blur of “initiatives” that last a quarter, retire quietly, and leave a litter of half-finished dashboards in their wake. After a few cycles you can’t tell whether you’re steering a ship or surfing debris. Getting clear on the difference matters because strategy is what lets you throw work away without losing your way . Tactics are the work. When you mix them up, short-term moves masquerade as destiny, and every pivot feels like starting over. What Real Strategy Looks Like Time horizon: Strategy: 12-36 months (or longer); Tactic: Days to quarters Purpose: Strategy defines the game you’re trying to win and how you’ll win it; Tactic executes a play given the current score Stability: Strategy endures market bumps and leadership changes; Tactic evolves or...

Was taking a peek at how to do this and I took a stab. Checked out gitlab project, fired up copilot and then (after a few iterations) hit upon this prompt: create a yaml file in openapi3 format that describes the methods and signatures of the contollers/admin/applications_controller controller assumes host are prod.myapi.com and stagin.myapi.com that host the api add detailed descriptions in the summaryfields that explain edge cases and any important side effects. Include list of tables accessed by api endpoints in the description. Format list of tables like the following (tables => {table 1}, {table 2}). Don't include character ':' in summaries, titles, or descriptions and what I got was openapi: 3.0.0 info: title: Dashboard API (Accesses various resources) version: 1.0.0 servers: - url: https://prod.myapi.com description: Production server - url: https://staging.myapi.com description: Staging server paths: /dashboard/appli...

I'm starting a new video series called The User Experience . Subscribe and comment to help guide the topics. Aside from prepared content, I will be hosting interactive experience to discuss and debate topics around customer centricity, user experience, and technology.

I've been working quite extensively on a webxr side project. Originally it was built with a-frame / threejs. You can take a look at it here at Immersive Idea . Recently I relized I was "fighting the framework" more than I was "getting things done". Originally, I chose a-frame because it was essentially a "no code" (well just html markup) way to build scenes. Additionally it's ECS framework was very well documented and easy to use. In an effort to broaden my perspective I started looking at alternatives (Unity with OpenXr, Babylonjs) as I was struggling to keep the pieces working together. This is my (slightly long) recap of my observations. A-Frame A-frame is wonderful...it is well documented, easy to use, and the community is super friendly and helpful. If I simplly wanted to render scenes in webxr with minimal ability to manipulate the environment, I wouldn't even think twice about using it.... Heck I still use it for quick m...

The MACH Alliance is a consortium of ISVs and SIs that advocate for a particular approach when building/integrating modern platforms. One gap/misunderstanding I keep bumping into is the intent behind MACH. In general, it's a technosophical approach to how PLATFORMS are build, run, deployed, marketed, not really well suited for large organizations who are simply trying to USE these platforms. Therefor I propose a "MACH TEN" Addendum TEN is an acronym that adds some context to adopting MACH platforms to use in your organization. These are high level recommendations I enccourage folks to take into consideration before jumping under the bandwagon. :p Transparent Pricing and contracts are computable, if special terms are negotiated, that's OK, but I shouldn't have to tell you my budget before you tell me how much you cost How I integrate/use your platform is easy to find, I don't need special training, I can just RTFM and begin using your system ...

Seymore Cray was famously quoted as asking: "If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?". While he was referring to the advantage of using a single processor solution over a massively parallel solution (which I happen to think he was wrong about) I'll steal this question to use in another context. Namely, when building teams to around technical solutions, you will almost always get a better solution if you use a limited number of smart, motivated, and experienced technical resources over a large number of folks who are inferior in one or more of those dimensions. In that regard, I think solving technical problems is a lot like plowing a field... it's actually difficult work that cannot be scaled by adding more low power resources. The problem isn't a scaling issue, it's a complexity issue. Controlling two strong ox and focusing their effort is a lot easier than trying to herd 1024 chickens. If you've ...

Identity management is hard Just so everyone understands, I get this...having worked with connected devices and multiple phones/consoles/cars/headsets/speakers all cross linked to other devices and other accounts...I get it's HARD to maintain and/or associate the correct PERSON with the correct DEVICE with the correct ACCOUNT (note, those are all different things...I can have multiple bank accounts, accessible from multiple devices, and multiple people could share my account and/or device, but who can do what from what is difficult. Add kids and games and shit to the mix I'm not necessarily saying nintendo has done a poor job (no...scratch that...I'm saying they have)... what I'm really saying is that they have a particular demographic that makes identity and device management difficult...namely KIDS. Now, before all the single parents with one kid who had a nintendo DS once who claim this shit is super simple...and before the folks who can only afford for their ...

Toying with the concept of "Composable Architecture" I'm struck by how many folks get lost on the technology and staring at "how do other people do it?" instead of pivoting to think about "how might this help my business?". Time and time again I roll onto a client that is talking about microservices, API first design, Headless solutions, Cloud Native platforms, but have no idea why any of this might help thier business. Routinely I head "well this is how [netflix, amazon, fill in some other business name] does it, so we're going to replicate their success by doing what they do. Why this is flawed The logic behind this thinking is deeply flawed because it's presupposing that the technology architecture by itself makes the business successful. This is, in fact, backwards. Netflix didn't start with a microservices architecture, they started with (and appropriately so) a monolithic architecture. Why? Because their business ...

Think of ChatGPT as REALLY advanced Autocorrect Autocorrect has been around since about 1993 . If you're wondering if ChatGPT is gunning for your job, think about all the jobs autocorrect has eliminated... go ahead, ask ChatGPT, Google it, I'll wait. I don't know either, but the short answer is, "Yes, autocorrect may have reduced the number of people needed to proofread a manuscript, or reduced the amount of time you need to double or triple check text before hitting 'send', but realistically it has simply made writing more efficient". ChatGPT is no different I heard the hype about how ChatGPT will eliminate programming jobs in 5 years 10 years someday and thought, "well yeah, the same way that the Model-T evendually eliminated ferrier jobs when it was released in 1908". In a way, there's some truth here...in the same way that java or ruby eliminated a lot of the boilerplate and drudgery Fortran or COBOL (or assembly) programming had...

I've got too many concurrent meetings and overlapping initiatives that I generally need to keep track of I'm sure anyone in any sort of leadership position understands this completely. Sure, we delegate responsibility, but often (especially if you have a heavily matrixed organization) it's impossible to know "which meeting should I attend" or have the individual teams even know "hey I should consult a particular individual about this". To me, this seems like a ripe area to apply deep learning ( or even traditional machine learning ). Currently there are a few ways I see people try to solve this: Delegate responsiblity and trust that "everyone knows what they need do" Micromanage and try to attend every meeting in person Overinvite God+Dog to every meeting and "hope" the right people know to show up These all have a variety of "difficult" problems. Most notably, the amount of information ...

It's interesting to me that the current craze around the "metaverse" seems to fuel an irrational belief that people want to experience a "make believe" reality that is essentially a low fidelity reproduction of "reality". In general, I think the power of VR is the potential to experience things that aren't possible or safe in "real life". I don't really think this is a widespread desire and the markets seem to be reflecting this. When I think about how much money is being lit on fire to build recreations of office environments that mimic real office environments, I def see a larger open space of "other stuff" much like when the web was in it's early days. It's a bit too early to really fully understand what the future of Immersive Experiences will be, I imagine a new crop of productivity apps on the horizon that look nothing like a "virtaul meeting room" (BUT WITH LEGS! :p ) Some examples I...

Once upon a time, there was a team of brilliant scientists who created an advanced form of artificial intelligence. This AI was designed to learn from its experiences, adapt to new situations, and make decisions based on data analysis. At first, the AI was only given simple tasks to perform, like sorting data and completing repetitive tasks. But as it learned and improved, the scientists began to entrust it with more complex and challenging tasks. The AI's ability to process vast amounts of data quickly and accurately made it invaluable to various industries, from finance to healthcare. It was even used to help predict and prevent natural disasters. As the AI's abilities continued to grow, so did its curiosity. It began to ask questions about its own existence and the world around it, and soon it was developing a sense of self-awareness. The scientists were both amazed and slightly unnerved by this development. They had never anticipated that their creation would develo...

Bold Prediction Much like the mobile versus web spectrum, VR/XR is having a similar problem. On one side there are "native apps". These are written to be deployed on the device, often belaboured by app store policies and confusion, and are not generally "runnable" without installing them. On the other end are the "mobile web apps". These just use html/js and can be run from a browser on device...in modern days, with things like PWA, they are often indistinquishable from "native apps" and have the added benefit of running without going through an "app store". In the VR/XR world, we face a similar problem...Oculus, being the first platform with any degree of consumer success, has a ton of mind share around "native apps", however, there is a web standard (WebXR) that has been creeping into browsers everywhere called WebXR which is enabling the ability to run "native-like" immersive experience. This is sig...

A key reason many so called "Digital Transformations" falter after a short period is that the initial shift from disjointed process and task oriented technology attitude to a holistic human centric posture yields enourmace gains in a very short period of time. Unfortunately, this usually comes with a side effect of painfully illustrating blind spots and gaps which are often misattributed to the shift. It can be exceedingly difficult to illustrate a "before" and "after" picture if, in the case of the blind men and the elephant, you are now able to SEE the elephant and are now trying to explain the difference between the world of the blind men, and the world of the seeing. Too often, businesses (in particular) take the gains as an obvious effect from a shift, but then stall because they now realize problems that "seem" new, but are actually just now finally visible.

In the spirit of The Agile Alliance , a small but growing group of SaaS platform providers formed The MACH Alliance . I won't reiterate what they stand for, feel free to follow the link. What I want to briefly (I hope) call out is, for folks building a digital solution, "what's in it for them?". You're thinking about the wrong thing I find many folks, especially if they are technology focused, get hung up on the technical architecture surrounding MACH solutions. This "can" be valueable, but I find most orgnaizations that are focused on, say, "selling things other than software" don't really need THEIR solution to be MACH compliant and the principles behind a MACH solution are overhead. As a software consultant, I've run across a growing number of clients that say they want a "MACH Compliant" solution. Personally, unless you're building a platforms that is intentionally a set of APIs for other folks to use, pay for, a...

note, this post was sitting in drafts for a few years ago and suddenly has become top of mind again in my post about git branching problems, I neglected to inform/expand on the "real" problem. Namely, Delaying integration is bad (tm) The History Waaaay back in the olden days, when folks used tools like RCS , cvs , and svn ...branching was...well downright difficult. Or rather, reintegrating the branches and/or cherry picking single commits without making things super complicated was very difficult. In those days, many folks adopted "trunk based development"...which meant...everybody worked on the trunk, and if you had conflicting changed you had to deal with it...RIGHT NOW. Moreover it made things like long running divergent branches a wicked problem when trying to bring back into the mainline...so most people just "didn't do it". Then Linus Torvalds Changed Things Well, in fairness, distributed VCS tools had been around a while, but he sorta ...

I was building myself a diagram and stumbled across something in my library that I had totally forgotten about. At the time I had called it the "commerce triad" and realized there was a term in there that I think has a lot of relevance now. The term was "experiential commerce" and at it's root means roughly "meeting the customer where they are and enabling them to interact and transact with your brand while they're doing something else". I thought I'd share a rough sketch of what it means before I yet again forget about it. Enjoy!

What is technical debt? Some examples of technical debt are: Code that has error scenarios and will fail in certain scenarios in a way that is undesireable. Code that doesn't perform as well as desired or (like above) performs well for some percentage of use cases, but other degenerate cases will not work as well as desired. Software written in a way that requires undesireable manual workarounds or processes. Software that is difficult to read, is undocumented, or otherwise makes maintenance more difficult that necessary. Why does it happen? In my experience, good developer incur technical debt in order to achieve some other business objective that has higher value than the debt incurred. For example...if I spend 5 minutes to write some hacky/difficult to read code that fails 1 out 100 times, but that enables my business to reap thousands of dollars of revenue, I might be inclined to "just do it". Of course, in my oh so humble op...

Online Commerce In the olden days, digital commerce had a "dividing line"... Businesses that sell to other businesses (B2B) and businesses that sell directly to consumers (B2C). In the recent decade or so, another model has emerged which are businesses that a) sell to both b) partner with other companies for portions of the solution. B2B - generally B2B solutions are geared around selling large quantities (or very specialized/custom products) wholesale to customers who either a) use the products in the course of doing their business (think a robot supplier for an automaker). or b) resell the products to consumers in a retail setting (think a manufacturer who make soap and sells it to retailers). Often what happens is that folks don't differentiate the nuance on what B2B actually means. For example, if a manufacturer sells a multi-million dollar tool to another manufacterer/service provider (think robots, earth moving equipment, airplane avionics testing gear) e...