mike.mainguy

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