Closed raganmcgill closed 5 years ago
nyctef
commented
5 years ago 👍 This is a logical next step after https://github.com/red-gate/Tech-Radar/issues/117 ("master is always releasable").
As far as I know the only time we've done this at RG previously is with .NET Demon, which got auto-released to the VS gallery on every successful build. From what I heard it worked pretty well - IIRC one or two bad bugs made it through, but both incidents were fixed within a couple of hours.
garethbragg
commented
5 years ago I'm a tad wary of this being explored by an individual - how can we effectively explore this as a technique unless a deploying team is engaged?
raganmcgill
commented
5 years ago @garethbragg i wouldn't be exploring it individually :scream_cat: that would end in disaster :laughing: - i'm putting myself forward as a champion to work with teams to drive this forward (apologies if i have misunderstood the last section - previous tech radars i have worked with call out for a champion of sorts and then teams volunteer to engage based on their direction and the alignment there of)
its something i'd like to explore with Prompt and Toolbelt but need input from @Dave-Rook and @juliahayward on this :eyes:
Dave-Rook
commented
5 years ago Today, it is time consuming and cumbersome for Prompt users to upgrade. This is something we want to address, because it is an obstacle that prevents the user from being exposed to the latest and greatest (and we all understand the impact that has)! This means, I am doubtful if the Prompt architecture will allow us to benefit from Continuous Deployment but, I think we will benefit from Continuous Delivery (which I'm defining as automating the release from Master, but the process is started manually).
If we can resolve the upgrade challenge we currently face, then there is a lot more room for us to get more excited about Continuous Deployment.
garethbragg
commented
5 years ago Totally agree, @Dave-Rook 😄
Incidentally, "Release scripts" are already in Adopt, while "Manual releases" are in Retire.
nyctef
commented
5 years ago #eng-auto-update has been looking into making the update experience better for users, although it hasn't made much progress beyond Clone unfortunately - would be nice to work on that some more next year.
I think the other big issue is security - currently we don't trust teamcity to do a release by itself [ref] so if we wanted to fully automate releases, we'd need to figure out how to get a trusted chain of actions from a verified github commit or something like that.
garethbragg
commented
5 years ago eng-auto-update has been looking into making the update experience better for users [sic]
This is on the Tech-Radar as "User-controlled background updates" (Tools/Explore).
...my feeling the need to drag knowledge from my withering brain seems an information management problem. I'll open a PR to consolidate this information a little, and see if that's any better.
raganmcgill
commented
5 years ago Just to be clear, I would class auto-update is an entirely different technique to continuous deployment.
For me (in very high level terms - i appreciate there are more to these)
continuous integration is around test automation to check that the application is not broken whenever new commits are integrated into the main branch.
continuous delivery is building upon CI and is around automating your release process so you can deploy your application at any point of time by 'clicking a button' (human involvement); This is sometimes refereed to as a PUSH method as we have to push our changes to live (sometimes batching up changes in order to release a feature)
continuous deployment builds upon continuous delivery and is around deploying every change that is committed to master. There's no human intervention and only a failed test will prevent a new change to be deployed to live. This is sometimes called a PULL method as the changes are pulled through to live automagically. In a hosted website scenario, techniques like blue/green deployment would be used to mitigate the risk of downtime, but in the simplest of scenarios, it could be that we just update the link on our website to the latest version.
At this point, I am suggesting that the change is simply available for the user. i.e. the latest exe / bundle is on the website / portal and can be downloaded by anyone.
Auto-update is then an optional implementation that can allow the user to pull and update to the latest version available.
Automating & having confidence in our testing capabilities as well as automating other processes like internal and external documentation is something that Prompt are interested in tackling during 2019. Both of these are enablers for the exploration of cont. deployment. The architectural nuances will then be faced into should the team identify that auto-update adds value
Dave-Rook
commented
5 years ago I was listening to an audio book called the Phoenix Project for the second time and something in the book got my attention. They claimed that work committed to master is still WIP (work in progress). I was surprised at this and sadly, the authors don't give any explanation why they felt this.
This doesn't (didn't) align with my understanding of Done but, has really got me thinking. Redgate already have (in their induction notes for new starters) that work is not complete until the user has it in their hands (on screen). I thought about this a lot and I then realised that even committing to master there are still additional tasks to get it to the customer. So I've come full circle and also feel that, until it's in the hands of customers, it remains as WIP! This PR will help reduce WIP. It will be interesting to see what the exploration digs up and to see if I'm just being too influenced by a book and my own thoughts!
So, based upon that book and time where I've digested things, I've now gone from "I want to do this but I don't see huge value for Prompt" to "I want to do and I see how it will affect any one installs the latest version of Prompt since it will be nearly identical to our master branch (the latest and greatest)".
fredjeronimo
commented
5 years ago A rabbit-rich world is a lettuce-poor world, and vice versa. The obverse of a population problem is a scarcity problem, hence a resource-allocation problem. There is only so much lettuce to go around, and it will have to be allocated somehow among the rabbits. In an information-rich world, the wealth of information means a dearth of something else: a scarcity of whatever it is that information consumes. What information consumes is rather obvious: it consumes the attention of its recipients. Hence a wealth of information creates a poverty of attention and a need to allocate that attention efficiently among the overabundance of information sources that might consume it. -- Designing Organizations for an Information-Rich World (1971) (full text), Herbert Alexander Simon (American political scientist and Nobel prize laureate)
This is a controversial topic and I don't share @raganmcgill and @Dave-Rook's enthusiasm in this matter (at least not in the way it has been presented). I want to offer a diverging and opinionated individual view from within the SQL Prompt team that I only claim to be mine and mine alone (with the hope that more share some of my concerns). To put it simply, I'm extremely sceptical of completely automated continuous deployment releases for desktop applications and even more so for productivity tools and plugins like SQL Prompt. I will offer an alternative in the end though that is somewhere halfway between continuous delivery and fully automated continuous deployment.
Apparently, I don't really do short statements (apologies), so if you are in a hurry:
TL;DR We want to be able to release at any point in time with a single button click – following continuous delivery (#186), master is always releasable (#117) and one-step release scripts (#38) -- regardless of the software product we are talking about.
Fully automated 0-click releases (continuous deployment) are situational and completely reliant on a myriad of interdependent variables (e.g. type of product, development resources, customer base and expectations, market fit, etc.). In most cases, for desktop applications, we want to maintain human control of when to release.
As @raganmcgill pointed out, it's quite unfortunate that in our industry continuous delivery is regularly confused with continuous deployment and sometimes even used interchangeably. A graphical view does wonders for me though (source):
From my non-English foreign angle, the choice between delivery and deployment is not immediately clear when you don't know the context (they even share the same first letter!) and perhaps the main wrongdoer behind the lack of a ubiquitous common language between developers.
Unless you are in the know already, you cannot really pick between them based on logic alone. I prefer to use 1-click release/deployment (continuous delivery) and 0-click release/deployment (continuous deployment) to differentiate between both concepts as it makes the manual and automated dichotomy at the heart of their separation transparently univocal.
To simplify, I will use release, shipment and deployment reciprocally here with the meaning of getting a version of the product to our users. Likewise update and upgrade are also synonyms in this text.
1-click deployment (#186) is a no brainer in my mind, a standard in our industry, a desired outcome of automation, a strong statement of trust in the quality of our automated test pipeline and I suspect it generates little to no opposition in our midst. Master should always be releasable (#117) and we want to deploy to our customers on demand and effortless (#38) when we feel it's needed. Choosing when is variable according to development, business and marketing requirements (e.g. we might want to wait to have a functional group of features/capabilities we want to release in tandem for maximum impact or we desire a release as quickly as possible to assess the impact of an MVP or an uncertain added value to reduce our feedback loops). The beauty is that this is under our control though.
0-click deployment is a different beast and is far from being universally accepted. It changes the rules of the game and introduces a very important paradigm transformation: control is transferred from the organic plane to the silicon one. And this is where the problems of 0-click deployment show their ugly heads. The decision to ship shifts from humans to machines and in this type of decisions I trust humans much more than I trust machines...
Taking a more pragmatic perspective, I struggle to see any real benefits for SQL Prompt, but I perceive several time-consuming challenges (on top of the already mentioned imperative for immaculate test quality and the real risk of losing track of non code elements such as documentation) in the road ahead - some of them of an herculean nature - if we choose to pursue this. I'm also not convinced that even if we were able to overcome these and reach our final destination safely, that it would be the right thing to do: we may end up lost in the wrong neighbourhood!
0-click deployment is extremely situational in my opinion.
It's hard to find balanced views on this topic. Most of the online content on the World Wide Web is simply following the bandwagon hype and reinforcing the echo chamber by simply praising the benefits of 0-click deployment to the high heavens without mentioning any of the potential drawbacks and pitfalls (other than technical hurdles such as lack of test coverage -- strangely enough, the equally important test completeness is almost never mentioned -- or your company might not be scaled or prepared for this yet).
It also doesn't help that 0-click releases are usually put at the apex of Continuous Integration/Continuous Delivery/Deployment (CI/CD) maturity level plans as if they were their natural evolution. To posit that 0-click deployments are the ultimate goal of software project management regardless of its nature is misleading in my mind. I feel a dissenting voice is needed as a lot of the problems as I see them lie on the fringe or outside of the technical realm (not that we are short of technical obstacles as well).
Not everything that can go wrong with a release is of a pure technical nature. Take look and feel/aesthetics, usability, discoverability/findability, accessibility, affordance, intuitiveness, cultural fit and glocalization/globalization/localization (e.g. minimal in SQL Prompt, but we still have US English as a customer facing goal – see #111), principle of least astonishment (just as valid in the product itself for our users as it is in code), etc.
No matter how good our automated test suite is, it will never reliably detect these and how they feel from an emotional perspective. You need humans. Humans are fallible by nature (both our curse and our blessing) and at least as emotional as rational in decision making, which is a great thing for both our species survival and civilization as a whole.
If we remove the human decision step, we lose touch for very little (if any) gain.
In SQL Prompt, we don't dogfeed (#102), we are not T-SQL experts, we have a growing but limited knowledge of our userbase and personas and we are a small development team.
As such, having things rest on master for a bit before being hit by public opinion can be beneficial for development and for overall quality control and team knowledge. Even when working on other tasks, we end up implicitly testing the features/capabilities that have been recently merged. We increase our awareness of them, our shared knowledge of the product but also have a chance to see them in action with a perspective untouched by the outside world (but not fully unbiased as we are too close to the act of creation) even if we haven't worked on them directly. We can assess how they feel in addition to how they work. Using Daniel Kahneman and Amos Tversky terms, we allow both our System 1 and System 2 thinking to process the modifications and that's a win/win.
Additionally, it mitigates the risk of knee jerk reactions as we let our initial opinions marinate before taking shape. We can do a pre-emptive course correction if something feels wrong.
But do non-technical things like aesthetics and intuitiveness really matter in the grand scheme of things? Yes, they do. They are essential elements of how the user reacts emotionally with a product and how he/she attaches to it rather than feel frustrated by it.
Taking aesthetics as an example, it has been proven that it has a subtle effect on users' tolerance of other shortcomings in the user experience. The aesthetic usability effect shows that users are more forgiving of minor usability issues in visually appealing interfaces. Inventive energy and visual verve go places. But they only go so far. A pretty design can make users more forgiving of minor usability problems, but not of larger ones. And when it goes wrong, it can have a multiplier effect even if it doesn't force the user to stop using the product.
In other words, the negative impact of subpar aesthetics is higher than the positive one (remember the negativity bias of human nature, where the majority of the population remembers negative things more strongly and in more detail than the positive ones) and it builds up over time, often without the user's immediate realisation. On a subconscious level, it slowly cultivates aversion surreptitiously.
This could lead to an unruly explosion and our hard-earned high customer satisfaction could be in jeopardy, especially if we lose their trust due to automated bad decision making. It's much harder to regain trust once it's lost than it is to grow it in the first place...
In the classic Exit, Voice and Loyalty: Responses to Decline in Firms, Organizations and States (1970), the German/American economist Albert Otto Hirschman points out that users who are unhappy with a product have exactly two options. Just two, no more:
Someone who abandoned our software isn’t likely to tell us about their issues (except to vent). And someone who cares enough to file a bug, report an issue or participate in research calls is less likely to switch away from our software.
In short, loyal users employ their voice, disgruntled ones will leave. Provided they have a choice obviously.
SQL Prompt is in a privileged situation which could turn into a poisoned apple gift if we are not careful. It has a somewhat niche but very impactful fit, an almost undisputable market monopoly, very high customer satisfaction and the competition pool is small and still lagging a comfortable distance behind. But they are gaining ground. We cannot be complacent nor rest on our laurels. If we brew dissatisfaction by unsuccessful automated releases with unforeseen consequences, our reluctant customers might not leave immediately but they will jump ship at the earliest opportunity once the acceptance threshold is reached somewhere else. The bar for transition is now reduced, especially if our competitors' prices remain attractively lower. And it's very unlikely we'll ever recover them from the open sea if that happens.
An overabundance of choice or overchoice, even when we encourage the adoption of the latest, has known detrimental psychological effects as well. Having a large array of versions at your fingertips can cause cognitive dissonance, when there is a mental difference between the real outcome and what should have happened. More choices lead to more cognitive dissonance because it increases the chance that the decision-maker made the wrong decision.
Who hasn't struggled to pick the next book to read when presented with a big unread pile of them but found it quite easy when the choice was limited to 2 or 3?
The impact is bigger if there is indecisiveness or a competitive element affecting the choices and limited time to do it, but also happens when there is a distinct favourite to begin with (e.g. "the latest version is always the best"). Paradoxically, these large array situations cause the chooser to feel both enjoyment as well as feel overwhelmed with his/her choices. Having less time to process the choice -- for example, when more and more releases appear in the list -- results in more regret with the decision if something goes wrong.
We love the freedom of extra possibilities but dread the responsibility that comes with it (even when there is only an illusion of choice). Having a larger set of choices also makes it harder to highlight the important stuff in each as a cohesive unit from all the myriad of small differences. For software updates, this basically means answering the user question of "What has changed and what is relevant to me?".
Several people have mentioned in Prompt research calls that they felt overwhelmed by the amount of releases that we do (currently on a weekly basis) and that it was hard to determine what was really relevant to them. They added that it made them lose trust in the product ("look at all the bugs they need to fix every week -- it must be unreliable"). If we control the releases, we can adjust this frequency to try to find the optimal value. If we fully automate this, we are in the hands of the chaotic and autocratic whim of the ephemeral cadence of present-day development work...
This also feeds into another phenomenon, the tyranny of small decisions, where a number of decisions, individually small in size and time perspective, cumulatively result in an outcome which is not optimal nor desired. If we view the choice to upgrade as a small decision (and it should be if we do it properly), then with a high frequency of updates people could mindless focus on always getting the latest instead of thinking why they need the latest and what benefits they can extract from it.
Furthermore, if users become unhappy with the direction a product is taking, small incremental negative changes generate a delayed reaction. In fact, it will take them longer to realise it but when they do the ripple effect will be immense. The American historian and scientist Jared (Mason) Diamond called this the creeping normality (or death by a thousand cuts) in his haute vulgarisation book Collapse: How Societies Choose to Fail or Succeed (2005), where major changes can be accepted as the normal situation if they happen slowly, in unnoticed increments. The overall modifications would be regarded as objectionable if they took place in a single step or short period.
This can break what we desire - short feedback loops – by having the reverse effect!
Likewise, familiarity in small increments can be constructed on purpose to raise acceptance of new features/capabilities and it's a powerful technique to force change (that can backfire, be used for evil or mask problems until it's too late), which I will discuss in more detail a bit further down.
Finally, we shouldn't demote the importance of the economical and psychological aspect of diminishing marginal utility (related but not the same as diminishing (marginal) returns). The law of diminishing marginal utility states that all else remaining equal as consumption increases the marginal utility derived from each additional unit declines. Marginal utility is derived as the change in utility when an additional unit is consumed. Utility is an economic term used to represent satisfaction, enjoyment or happiness (in entertainment, you can also add fun to the lot).
This typically means that the first unit of consumption for any product is typically highest, with every unit of consumption to follow holding less and less utility. On top of this, marginal utility of each homogenous unit decreases as the supply of units increases (and vice versa).
As we add more and more updates, their utility (or the customer's perception of it) will sink, even if the product itself is providing constant added value. From the customer's viewpoint, he perceives less utility (benefit) from additional updates and subsequently values them less. If you update a product 400 times in a year, the cumulative upgrade impact (and thus customer satisfaction) might be lower than if you do only 50 updates to reach the same upshot.
I'm not convinced the association between frequent software releases and an increase in quality is anything but a spurious correlation. There is a lot of contradictory information floating around and most of what I saw stems from opinion, ideology or data not backed up by any scientific evidence. As far as I know, there are no rigorous scientific studies that prove it either way.
Just to be clear, I’m only talking about how we release to our customers, not about splitting development work to small atomic components using proven techniques such as vertical slicing (#145).
On a personal anecdotal level, I've participated in projects with frequent releases that had high quality standards and others with very poor ones (likewise for infrequent or big bang release cycles).
The jury may still be out on that subject but I have a strong opinion on this subject. For me, quality is only really raised when the team thinks, breathes and cares deeply about it, actively adds it to the schedule and follows through on those resolutions (unlike New Year ones). It's mindset-based instead of process-based!
In web applications, users typically always run the latest and they have no control over this (and frequently no awareness, especially over minor changes) . I go to a website and bam there is the new and shiny version. This changes the release dynamics completely as you don't need to worry about older versions lifecycles. As soon as you deploy something, the new fully replaces the old and your entire userbase is automatically migrated to the latest version.
It's a "fire and forget all past" operation that fits like a glove to 0-click releases.
In the desktop world, in most cases we don't have that luxury and I would argue that we don't want to either as there is an explicit desire to place upgrade control in the hands of the user.
There are several consequences to this, starting with a psychological effect at play on how people deal differently with upgrades when they are visible or hidden away.
As a desktop user, unless we offer amazing communication mechanisms (and almost no application ever does), recall that overchoice of too many software versions makes it much harder to know what has been modified since I last updated and how impactful it is to me.
In SQL Prompt, we made a conscious decision to improve our release notes in the future and make them more appealing to minimise confusion. If ever adopt 0-click releases, we would need more, something to determine what has changed in the product between the current version and the latest. Perhaps something that dynamically constructs release notes client-side and groups similar items depending on the context and potentially even customer habits:
We have released 5 new code analysis auto-fixes and fixed 13 bugs (3 around formatting, 1 around suggestions and 10 around refactorings). We've also added a new filter to the split table functionality (that you used 34 times last week). Click here to see the full list.
Websites don't worry about it, as they are not expected to notify users and often don't have any type of release notes or transparency in regards to change. Consequently, they can get away with freeform experimentation and if we're honest pretty shady stuff provided they manage to hide it away from their customers.
How people perceive web and desktop products and furthermore productivity tools and other types of applications also varies.
In IMDB, as a casual user, I don't really care about all the small changes they might frequently do on a daily basis. It mostly doesn't affect me, so I just go with the flow. But if something big changes (e.g. how movie ratings are calculated), I want and need a notification to be aware of it (as my whole usage of the product could change).
But in a desktop productivity tool like SQL Prompt or Resharper, where my own work depends on knowing what is available and how to use it, I want to know when and if to upgrade. It's all a matter of economics. Problems could cost money (or worse, my job) and new features in this type of product require investment (i.e. money) to learn. This is equally true for developers, team leads and managers.
And this leads us to the approach customers take in the face of small changes and MVPs. If an area of the product is under constant restructuring and suffering significant cumulative differences between frequently released versions, not every user will commit to the effort to try out this WIP version while still under the obligation of performing his/her day to day duties.
It's too risky, for limited payoff. Only the more adventurous, curious or power users will venture forth. Others will need reassurance that something is stable before going with it (especially when using it as part of their professional life).
How many SQL Prompt users fall in each camp? That might be the first question to ask.
On the development side, relying on bleeding edge data could influence our assessment of a prototype or MVP. If customers don't get involved as early adopters or they get an underwhelming experience throughout that makes them quit halfway through before the final and polished version is out, then our research might (wrongly) conclude that there was no interest in this feature/capability to begin with, dropping potentially useful features from the radar completely.
Coming back to the technical kingdom, regardless of whether they are done manually or automatically, under 0-click deployment scenarios product upgrades need to be smooth, reliable and quick.
When upgrading SQL Prompt, our users currently have the restriction of having to close the IDE prior to launching the process. The upgrade process itself is fairly fast already. The UI based version of the installer takes little more than 1 minute and requires very little user interaction.
However, this all adds up if we have multiple releases during the day. Even if we reduce our upgrade times to less than 1 minute and we ensure an in-product upgrade from within SSMS/VS, if we release 10 times a day, this would mean several daily lost minutes of downtime to our customers (aggravated if we have an auto-update mechanism in place). This is even worse for large teams or if you need to deploy in multiple environments (even if you opt to go with silent unassisted installations).
If people don't see significant improvements over time that target them specifically (people don't care about all the wonderful features that affect others), they will get annoyed.
As no update system is flawless, there is also an added risk of failures at any point (e.g. failed to download, either on our end or due to intermittent connection on the customer side) -- this adds to the frustration.
The cost of failure is even more horrific if we add auto-updates to the mix. Few things are as annoying as a tool deciding to upgrade to the latest and then falling to accomplish its quest (e.g. the infamous Adobe Flash Player is a very good example of doing this in appalling fashion).
If an update leads to an undesirable outcome, as a user I want to be able to quickly downgrade to a version that was working as I wanted. Mind you, this might not be a technical problem at all that's bothering me -- it might be a cosmetic issue such as difference in the way things are now formatted that no longer obeys to my expectations (several of our users still remain in version 7 of Prompt after we revamped the entire formatting system in version 8).
Having too many versions to choose from can cause mayhem.
When was the last time I updated before this last one that broke things for me? A couple of months ago? What do you mean there have been 100 releases in that time period? Argh, which one is the right one? You could end up going much further back to prevent problems (e.g. 3-4 months ago), but then you may have other missing improvements in those older versions that you also rely on for your workflow. You might be hunting in a game of cat and mouse for a long time and you will resent it in the end.
There are several additional considerations and open questions that I can think of (most of these are not insurmountable obstacles, but all require effort):
0-click releases (in their defence, they are adjusting to add functionality to partially contemplate this). Even with unique version numbers attached to each automated release, their sheer number will make grouping harder and human unfriendly and it will consume a lot more effort from the developers and support. For instance, when filtering for something, you would likely need fuzzy boolean operators 'bigger than' and 'less than' instead of specific version numbers and because the frequency of releases is variable, you will need to continuously adjust these values (e.g. in one week you might have 50 and in the next only 15).0-click releases move the human manual testing cycle towards the real world as quickly as possible to get early feedback. But how much do we trust the reporting faculties of our users? Real users are not professional testers and their degree of commitment to the product varies wildly. They take time to report, sometimes even in the face of catastrophic behaviour. For example, a few months ago, Prompt was broken for more than a week in Visual Studio (would not load at all) before it was first reported to support. This might lead to a false sense of security, where we as developers feel protected thinking the right measures are in place in the real world reminiscent of the security theater practice.This is but a small list. I'm sure it can be expanded to cover a wider net.
In addition to wanting to avoid bad releases, we also don't want to provide pointless releases. We want each release to offer added value and raise the overall quality of the product, making sure to target the user's perception of it. Upgrading to get nothing in return is never desirable. But what about maintenance and kaizen work? If we do a PR that only does internal refactorings, we want to ensure we don't trigger an automatic 0-click release. And what about edge cases or something that only affects a tiny subset of our userbase?
You might counter that every change to master should be impactful to our users. But that's a fallacy and an artificially imposed restriction on development that acts as a hindrance. As I view it, in a simplified model (I appreciate there are more nuances to this), we can basically encapsulate modifications in 3 main layers (not to scale):
Outer layers include the totality of the inner layers or if you prefer the inner layers are a subset of their parent layer (e.g. anything that is visible to our users, impacts the product and is also needed for development but what is needed for development may not impact the product nor the user). To fully control our releases effectively across these various layers, we require rules to control what gets released and when.
Again this cannot be fully automated. We can easily add exclusion rules for types of files and regions of the codebase (e.g. .md files never trigger release nor comment changes or this particular internal development tool) but for much of everything else that's qualitative based it's much more complicated. We would need additional manual processes (e.g. PR tags in Github). And these are error prone and easy to forget even with iron-clad team discipline.
This means extra maintenance moving forward that conditions our work, increasing the global effort and cost of development, automation and code reviews.
The American software engineer Frederick Phillips Brooks (Fred Brooks), in his key book The Mythical Man-Month (1975), states that over 90% of the costs of a typical system arise in the maintenance phase, and that any successful piece of software will inevitably be maintained. When we add to this maintenance pile, it has a discernible impact. In other words, economics could be adversely affected. Is it worth it just to go from 1-click to 0-click releases? Do we even want that behaviour to begin with?
Obviously there is a possible compromise here by having a human controlled automation of 1-click releases (or human scheduled 0-click releases). For example, if we have a 0-click deployment that is triggered on a specified human-controlled scheduled frequency (e.g. every week on Wednesday at 14h00, we automatically trigger the release and deployment) while also allowing 1-click overrides on demand (e.g. we can cancel the scheduled release at will or if we want a hotfix on Thursday, we can trigger it manually), then it could offer us the best of both worlds...
I want to end this long discourse with a cautionary tale. We need to avoid leading our customers into the trap of the tyranny of the new, of the perpetual craving of the always available shiny novelty just around the corner. Users need to feel updates matter. I'm always reminded of the Greek mythological fable of Erysichthon, king of Thessaly who was cursed with eternal hunger, a punishment for destroying a grove of sacred trees and killing a dryad, a protegé of Demeter, the Greek goddess of grain, agriculture, harvest, growth, and nourishment.
Food acted like fuel on a fire: The more he ate, the hungrier he got. He tried several horrible things to quench his all-consuming appetite (including selling his shape-shifting daughter Mestra into slavery consecutive times) and in desperation eventually ate himself in hunger.
This is particularly ironic as Demeter herself had been eaten alive by her Titan father Cronus, who never too bright by nature foolishly though he could escape the Fates by eating his six children who were predicted to kill him one day but forgot to check that in Zeus place was a rock wrapped in cloth due to a clever swap by his wife and sister (!) Rhea. Zeus grew up in hiding and eventually returned as an adult to cut his father open (in some accounts offering him a magic potion brewed by Metis, mother of wisdom and deep though, that caused him to regurgitate his siblings in reverse order) and allowing his five siblings, Demeter, Hades, Poseidon, Hera, and Hestia, to escape.
Building up delayed gratification is an effective alternative strategy. Sometimes it's better to deliberately withhold than to offer immediately. The entertainment industry (where I've worked for many years) is particularly adept at this by generating hype through various means (e.g. teasers, conferences, easter eggs, etc.) and then creating enough self-sustaining momentum to drive adoption on large scale (provided the end product delivers). Obviously they deal with a commodity (fun) that dramatically impacts customer behaviour and that we usually don't have on more traditional venues, but there are still lessons to be learnt.
Delayed offerings and anticipation build-up can lead to everlasting longing, even one that is not built on impulsivity (and thus free from dangerous side effects like addiction). In my opinion, we should focus on building long-term customer engagement. We should make it crystal clear what the product already offers as we prepare him/her for the future.
Features/capabilities in our products should never be a surprise or an unknown ace. There should only be a binary choice involved from our users: To consciously use them (either regularly or sporadically) or to consciously ignore them (not needed or not desired).
In the The Cinematic Mode of Production: Attention Economy and the Society of the Spectacle (2006), the American film theorist Jonathan Beller notes that the value of an image increases in the view of others simply because we are looking at it.
As we read [objects] (Coke bottles, sneakers, automobiles, whatever), we produce their signification. The image is perceived not only in and of itself, but as a consequence of the perception of others. The density of this perception of others is part of the quality of the image -- its caché. [...] The perception that images pass through the perception of others increases their currency and hence their value. Vision adds value to visual objects, value that is often capitalized. [...] To "see" is already to "buy" (I'll buy that), to look is to labor.
This is quite interesting as it implies that our individual attention actively participates in its currency, which is to say, its value, inasmuch as this depends on the reach of its circulation (the collective aspect).
As the Swiss thinker Yves Citton highlights in his The Ecology of attention (2014), there is a clear economic consequence that brings about a principle of valorisation through attention: the simple fact of looking at an object represents labour which increases the value of that object.
Like the mythical Ouroboros eating its own tail, we enter the domain of the circular self-reinforcing dynamics of attention economy: attention attracts attention. In other words, attention accumulated in the past and the present supports the future accumulation of attention. And this sells. No question about it.
Furthermore, this circular dependency explains the power of phenomena like word of mouth and going viral and is recognised, with admittedly a high dose of sarcasm and criticism, by French poet and writer Jean-Michel Espitallier in his scathing De la célébrité: théorie et pratique (2012):
It is because I am renowned that I am known. It is because I am known that I am renowned. / C'est parce que je suis reconnu que je suis connu. C'est parce que je suis connu qu'on me reconnaît.
By showing and highlighting our product features, we sell them even if the user doesn't use them regularly. He/she needs only to be aware of them.
In an information-rich world, richer by the minute, we want to grab our user’s flickering attention and keep hold of it, heeding the warning of Herbert Alexander Simon at the beginning of this post.
But we need to be cautious as well, there is a fine balance at play here. Psychologists and social scientists are well aware that attraction (and also repulsion) leads to familiarity. In what is known as the mere-exposure effect (or familiarity principle) people tend to develop a preference for things merely because they are familiar with them, even if they were disliked initially. The impact can be artificially inflated by forcing constant exposure and, like an avalanche, only grows stronger with time.
Exploiting this psychological phenomenon is a well-known marketing strategy and the entertainment world (especially the music industry) has masterfully used and abused it to fabricate trends (e.g. soft brainwashing by playing the same song over and over again across all mediums and locations, be it on websites, shops, subways, adverts, movies, digital billboards, etc.).
Each feature in our products should stand on its own feet and people should be using each one not only because they grow accustomed to it but because they also feel it's the right and best option for the task at hand. We want exposure and discoverability but we also want our customers to engage with our products on an emotional level so the experience feels special, almost magical.
Following the footsteps of St. George we hunt dragons at Redgate to improve development practices but we ought to always keep the fantasy and magical realism alive for our customers (high quality and no fuss releases when needed as determined by humans that supply effective wonder) so they are not continuously hungry like Erysichthon...
fredjeronimo
commented
5 years ago Following the above, I've had some conversations with @raganmcgill to go over the considerations and concerns expressed here and how they affect the things we want to trial out in SQL Prompt. Here's a quick summary of our findings and current inclinations:
fffej
commented
5 years ago Closing this due to inactivity.
What change would you like to make to the tech radar?
Add it to the radar
Why do you believe this is valuable to Redgate?
Continuous deployment goes one step further than continuous delivery. With this practice, every change/commit to master that passes all stages of our production pipeline is released to our users. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.
As such, our testing culture needs to be at its best. The quality of our test suite will determine the quality of our releases. Documentation processes will need to keep up with the pace of deployments. Feature flags may become an inherent part of the process of releasing significant changes to make sure you can coordinate with other departments (Support, Marketing, PR...).
Value presents itself here as we can develop faster as there's no need to pause development for releases. Deployment pipelines are triggered automatically for every change. Releases are less risky and easier to fix in case of problem as you deploy small batches of changes. Users see a continuous stream of improvements, and quality increases every day.
Where should this be on the tech radar?
Explore
If this should be in the Explore ring, who is committed to exploring it?
Ragan