DEV Community: cwisefool

Is NoOps mostly fluff?

cwisefool — Thu, 28 Jan 2021 19:33:20 +0000

So I've been hearing a decent amount about "NoOps" and how it's supposed to revolutionize infrastructure management by removing the need for a DevOps team. However, when I look into it, it seems that a lot of it is just DevOps but where infrastructure isn't managed in code anymore. And when I've asked about what's supposed to happen when say, a server goes down, the answer seems to be that the dev team is notified about it and goes in and corrects the issue...which just seems like DevOps.

So I'm curious, has anyone heard of NoOps? Did it seem like mostly hype or something that has actual merit?

Software Testers, interested in a browser specially designed for you, with JIRA integration built in?

cwisefool — Sat, 09 Jan 2021 14:28:26 +0000

Imagine while conducting exploratory testing, you identify bug. With push of a button, you automatically create JIRA ticket with a repayable user session attached (user session has last page with login form auto chosen as starting step). Developer can then replay same session repeatedly while fixing bug (features exist to make it easy for developer to use their local URL while fixing bug). Once bug is fixed, you can replay the same user session to verify, and close the ticket automatically.

Other features planned: auto-detect forms and fill in with auto-generated data appropriate to the field; easily create variants of steps recorded instead of having to record separate user sessions.

User sessions will be JSON files containing intelligently chosen DOM selectors, and event information (i.e. for a form field there's usually no good reason to record click x,y). The intent here is to make the user sessions as robust as feasible so if, for ex. an input field is moved somewhere else on the page but retains its 'id', the user session replay is unaffected. If elements can't be located during a replay, instead of session failing it will pause and prompt for tester to perform replacement action, and then continue with rest of replay.

A companion tool is also planned to read these user session files and execute them using selenium, webdriverio, etc. for cross-browser headless testing.

I'm a software developer in the initial stages of developing such a tool and looking to gauge interest.

Are Private Enterprise Thought Police Consistent with the American Republic?

cwisefool — Tue, 10 Nov 2020 23:49:47 +0000

Subtitle: Considering the legitimacy of private enterprise interference in the quasi-public sphere

I'm going to be upfront: this post is overtly political. As such, I apologize in advance if the "debate" tag is inappropriate. I initially had tagged "watercoolor" but upon a re-read, I became convinced this post is hardly "light-hearted". I have provided this warning at the very beginning so that anyone who does not want to read anything political can stop reading now.

Still here? Then I will argue that the fiction sometimes presented that political discourse is outside the realm of "polite" discourse is a fiction that only works to the benefit of tyrants. For a free people, politics are not only a suitable topic, but a necessary one for the continued survival and vitality of us as a free people.

I have not before posted anything political in this community, so this will be a first. That said, it isn't pro-Democratic party or pro-Republican party (though it is pro Republic).

First, a disclaimer. It goes without saying (but I'll say it anyway): the opinions expressed here are in no way reflective of dev.to, my employers past or present, or anyone else other than the natural person [a United States citizen] writing this post right now (me). I encourage disagreement, debate, etc. All I ask is that, in consideration of the policies of this platform, all such is civil and courteous. Dev.to is really a wonderful platform where really smart and creative people can engage in meaningful dialogue with each other in a way that has rarely been successfully implemented in any other community I've ever been involved with. In many ways, it reminds me of the ideal of the Symposium or Academy of Ancient Greece. I sincerely hope that this post spurs the same kind of meaningful and civil discourse I have come to know and love from this community.

So what do I mean by "pro Republic"?

According to the United States Constitution, Article IV, Section 4: "The United States shall guarantee to every State in this Union a Republican Form of Government, and shall protect each of them against Invasion; and on Application of the Legislature, or of the Executive (when the Legislature cannot be convened) against domestic Violence."

This is known as the "Guarantee" clause.

It is a common misconception that here in the United States we have a "democracy". More properly, we have a democratic republic.

One of the early cases (probably the earliest, but IANAL) concerning this clause is Luther v. Borden (1849). If you look up that case (i.e. https://constitutioncenter.org/interactive-constitution/interpretation/article-iv/clauses/42), it is mainly quoted for the ruling that the question of whether the form of government is "Republican" is "nonjusticiable".

However, that seems to me a gross simplification of the text of the case, wherein if you take the time to read through the lengthy proceedings (https://tile.loc.gov/storage-services/service/ll/usrep/usrep048/usrep048001/usrep048001.pdf), you'll find this section:

"The institution of American liberty is based upon the principles, that the people are capable of self-government, and have an inalienable right at all times, and in any manner they please, to establish and alter or change the constitution or particular form under which that government shall be effected. This is especially true of the several States composing the Union, subject only to a limitation provided by the United States Constitution, that the State governments shall be republican...That the people are the sole judges of the form of government best calculated to promote, their safety and happiness...That, as the sovereign power, they have a right to adopt such form of government...That the exercise of this right, which is a right original, sovereign, and supreme, and not derived from any other human authority, may be, and must be, effected in such way and manner as the people may for themselves determine..."

To me this seems to codify a basic tenet of American government: the People of the United States are really the government. Our elected officials are merely representatives that we more or less "hire" to stand in for us, subject to the condition that they represent us faithfully. To put it much more bluntly, in America every one of "the people" are kings and sovereigns.

It also seems to touch a fundamental element of American culture: WE are more than capable of deciding for ourselves how we are to govern ourselves.

All of this brings me to my central question: Are Thought Police Consistent with the American Republic?

By "thought police" I mean any group that would, under whatever pretense real or pretend, seek to "protect" us from certain publications that they deem to be "harmful" to us.

I would argue that it is overwhelmingly clear that thought police are not consistent with the American Republic.

But, surely, in the Land of the Free, we don't have such entities operating do we? Until recently, I would have probably agreed with you. Or at least I would have agreed that we didn't have any significantly influential entities operating in such a manner.

Sadly, recent events have brought me to the inescapable conclusion that we very much do have such entities.

As many of you have probably seen if you've visited social media recently, any attempt to post certain publications or links that are deemed "misinformation" are resulting in a strange new phenomena: "fact check" warnings that all but directly state certain links are "misinformation" or "misleading".

I would argue these are a subtle form of thought police. The issue at hand is not whether the links or information posted is, in fact, true or false. That is, IMHO, for the reader to determine in accordance with their own faculties for logical reasoning and investigation.

Whatever their stated aims might be, such "fact checks" basically amount to a form of censorship: certain links are being treated differently than others, and this separate treatment is the very heart of the "chilling effect" that is prohibited the government by the First Amendment.

Of course, social media is not the government. However, few would argue that it is not a public forum, which would seem to, at the very least, make it a quasi-public sphere. By "public forum" I mean a central place where communications take place between the people. In fact, I would go one step further and argue it has largely become the de facto public forum. Especially given the circumstances of the pandemic, are not online communities the new streets? As such, it seems that it is not wholly outside the realm of the Constitution, which is, after all, the "Supreme Law of the Land".

That these "fact checks" are being added without the user's ability (so far that I know) to even opt-out [I would argue they would need to be opt-in to even begin to past Constitutional muster] only solidifies my view that they are completely against the spirit of the First Amendment and, in fact, American Liberty.

Now, whether such "fact checks" could be challenged as an actual violation of the letter of the First Amendment seems to be "no" (https://www.theverge.com/2019/6/17/18682099/supreme-court-ruling-first-amendment-social-media-public-forum). This seems inconsistent in that private enterprises are prohibited from certain conduct deemed unconstitutional (i.e. private enterprises cannot discriminate against protected classes such as race, disability gender, etc.), but again, IANAL.

For anyone who's read this far, what do you think? I look forward to a civil but engaging discussion in the comments below.

Why don't more devs answer WHY as part of a commit?

cwisefool — Wed, 04 Nov 2020 14:21:09 +0000

Despite every guide I've ever read recommending excellent commit practices (https://dev.to/chrissiemhrk/git-commit-message-5e21 is just one example), I have noticed that almost every single commit message I encounter on any project I've worked on (admittedly, I've only ever worked on for-profit software teams) is usually only a single line summary of what was done (which is pretty easy to see just from looking at the code diff) and nary a reason why in sight.

I don't understand this -- at all. It tends to make the commit message itself almost next to useless. I get that typically these commit messages include a reference to a ticket which hopefully contains more context, but that context is usually high-level and frankly often contains little more than "fixed" or "updated" so it's not that useful either. Plus, every dev knows that the ticket system used today will one day be replaced with another, and probably with a loss of all that context. Commit messages, on the other hand, are eternal.

What makes this even more perplexing to me is that commit messages are one area where we could be as verbose as we want. The only ones who will look at it are devs and dev managers, and so we can dive deep into the technical details and considerations that warranted the change that was made. At the very least, a commit message indicating why helps when, several months down the road, during a Planning or Refinement meeting, management inevitably asks why a change was made -- and inevitably no one remembers anymore.

Are we devs really too lazy? Or is it that we have a perceived idea that management doesn't want us spending too much time on any task other than mindlessly churning out code?

Free 1st mo + $5/mo LIFETIME hosting for select websites

cwisefool — Sun, 27 Sep 2020 14:12:35 +0000

I am a representative for a private exclusive web hosting company that is offering free first month + $5/mo thereafter hosting for a limited number of websites. If interested, please respond to this post with your current website URL or idea and it will be considered. More details will be discussed with chosen candidates, but our hosting setup is a drop-in replacement for Apache, yet significantly higher performing. As every website has different needs, if a website is chosen a subsequent technical screening will be conducted to ensure we will be able to provide sufficient resources for it to fulfill its mission. Providing known technical requirements in your reply will help streamline the technical screening, but is not required for consideration.

A few websites are explicitly excluded from participation:

websites promoting sexually explicit material or violence
any website whose content would be a violation of dev.to's community guidelines (our company has pretty much the same guidelines)

All others are welcome to apply. Websites whose content, in our exclusive discretion, are particularly beneficial to the Internet at large will be more likely to be chosen.

Not Quite Broken: How Business-as-usual Software Development Produces Barely Designed Software Systems

cwisefool — Sat, 26 Sep 2020 21:59:44 +0000

It is something of an open secret among long-time developers that practically every software system you work on as a for-hire developer in the private sector is, more or less, a huge mess; your job is merely to try to slow the inevitable code rot, that, like entropy, threatens to one day plunge the system into such a disorganized, overly complicated, chaotic state of "spaghetti code" that the only feasible solution is to completely rewrite it.

There is, by way of shared humor, of course, the inevitable half-joking references to Dilbert style bosses to explain why this is -- running the gamut from ineffective to possessing a perverse pleasure at orchestrating such an outcome -- but rarely, if ever, is it acknowledged that much of the blame lies with the core processes of for-profit software development.

The above assertions may seem overly harsh, but they directly follow from the processes that for-profit software development teams are constrained to operate within. For, despite the supposed "self-organizing" nature of Agile software development teams, the reality is:

Every task a developer is working on was assigned to them by the business. Their "leader" or "manager" or whatever title their boss has, is, primarily, the friendly face of management to the workers and vice-versa. Rarely, if ever, does the boss have any real significant power to advance any desired goals of the team or their own goals, unless they already coincide with the goals of the stakeholders. (They have other powers, but they're primarily concerned with "managing" the workforce in terms of interviewing potential new hires, approving PTO requests, etc.) They, like the rank-and-file developers, are employees able to operate only within the narrowly permitted freedoms that their bosses afford them.
Developers are discouraged, implicitly or explicitly, from devoting too much time to any one task, and are especially discouraged from devoting "sprint time" (which is the entire workweek in most companies) to any non-assigned tasks
Those in upper levels of management who actually write up the ubiquitous "tickets" that form the currency of software development to the rest of the business often have only a vague idea of how the system should actually work (not being technical experts), but a much better idea of how it should not work

The consequences of the above 3 realities lead directly to the common state found in almost every software development team: you rarely, if ever, get to work on any "feature requests" because almost ALL your time is spent fixing "bugs" (which can range from actual clearly incorrect behavior of the system to the changing whims of whoever originated the "bug" ticket).

Even more rare is an opportunity to "refactor" your system, write additional unit tests, or perform any work that wasn't directly assigned. Any thought of discussing high-level architectural concerns (such as S.O.L.I.D principles, etc.) with the team is laughable. Merely bringing up the word "refactor" during any of the team's meetings is a sure-fire way to have QA start to panic as they consider the thought of everything breaking before the next production push (an understandable concern given how little time they have to actually focus on any one ticket).

Now, a certain percentage of "bug" tickets is simply a consequence of software development in general: developers are humans and thus no software system will be perfect. But if almost all of the tickets being worked on every sprint are bug tickets it directly follows that the system that is demonstrating these defects has a highly defective design, by definition.

This leads back to my initial assertion: these "business-as-usual" practices and principles lead to software systems that are, just barely, but not quite broken. In other words, they are barely designed. They have gone through the theatre of "planning", "development", and "verification" (usually by a separate under-staffed, overworked "QA" department), but none of those practices have been done in any way that truly fits the meaning of those words.

Note to the reader, especially the non-developer reader (what few there may be in this community): the following can, but shouldn't, be understood as a concise insider's description of software development; it omits some very important steps, however, and is primarily intended to provide a brief idea of what "planning", "development", and "verification" typically boil down to in common practice.

During "planning", the whole team is presented with an often just-now-seen "ticket" they are expected to read, evaluate, and estimate in the few minutes provided during, for instance, "planning poker".

Given the complex nature of the software system and the ambiguous nature of the ticket, this is little more than a hopeful guess. The business barely cares if the estimate is a 5 or 8 (if using the common unit of story points) since all they really care about is how long it will take before the ticket is moved to "done". Very little discussion occurs in most cases. There are far too many tickets that need to be "estimated" to allow any significant time to discuss an approach, let alone the merits of alternative approaches, to any one of them anyway.

During "development", the developer finally has the opportunity to actually consider the business's ask (usually a "bug"), as recorded in the ticket.

From this point on, the developer will mostly work solo, with the main touch-point with the team on the actual implementation to be the later "code review" whereby another developer looks over the code and, if they don't believe there's anything obviously wrong with it, approves it.

Typically, the first step will be to try to reproduce the bug in a separate local development environment. This is often not straightforward at all since there might be little information on what even caused the bug.

Once a developer has the ability to reproduce the bug, they then will attempt to use their diagnostic and analytical skills to determine a likely cause.

Finally, they will try to identify the quickest, least invasive way to adjust the system as little as possible in order to correct the defect in a way that will require the least amount of "verification" (i.e. re-testing by QA).

Already, it's clear that the above process isn't geared towards an "optimal" solution, but merely a "workable" one.

Ideally, as part of this process, the developer would want to communicate with the person who requested the ticket to clarify any unstated assumptions, but, since that would take too much time, they instead end up implementing a minimal literal "fix" that, unless they have a very thorough understanding of the entire mechanisms of the system exhibiting the "bug" (a practical impossibility), probably ends up fixing that particular defect, but introduces several more in the process, thus setting the stage for the future bug tickets that will come as a direct consequence.

During "verification" a, usually separate, "QA" department (often just a single person or a handful; almost always drastically understaffed and overworked) does their best to repeat the steps that caused the bug and, provided that this brief walkthrough doesn't exhibit the bug, marks it as "done", freeing up the developer to pick up another of their pre-assigned tickets to work on.

Now, none of this is a reflection on the fine developers who work on such systems, who are fighting a Herculean uphill battle where every day a ticket is not "done" is one day too many from the business's perspective of constantly at-risk deadlines, but it is a complete farce to say the system is a "designed" system in any fair use of that word. A designed system is one that has been planned out, thought out, its pieces created to fit together into a cohesive whole. Houses are designed. Almost all modern physical products are designed. Software is not. Software is cobbled together by overworked, underpaid, highly talented, creative, and persevering individuals who have very little actual say in how anything is done.

So the next time you are faced with a website, app, or another piece of software and you ask yourself "who the hell would design it this way?" You now have your answer: it wasn't. It was barely designed. And the developers who are responsible for it can hardly be considered the "authors". Until the state of "business-as-usual" software development changes to actually give freedom to the developers to implement quality software we will continue to have barely designed, not quite broken systems, and you have the profit-is-everything, time-is-money mindset of the corporate world to thank for it.

The opinions expressed within this post are entirely my own. They are not those of dev.to, the unnamed company I work for, or the Internet at large. If you agree, and especially if you disagree, with any of the above, I highly encourage stating so in the comments below (and, note to moderators, why I tagged this with "healthydebate"). All I ask is any comments be logically sound, meaningful contributions, and constructive.

The Myth of the Spec

cwisefool — Fri, 18 Sep 2020 00:05:53 +0000

As a veteran of the software industry, it is always refreshing to talk to young people interested in becoming software developers. I first explain the standard perks of the job: typically, if you're decently talented, it can earn you the new American dream of a full-salaried, full-benefit position with decent wages, accompanied by that certain amount of autonomy and respect which comes from no one in the highest levels of management quite understanding exactly what it is you do every day, but knowing very well how much the continued success of the entire company depends on it continuing to happen with as few problems as possible. In light of certain socio-economic changes worldwide, it is now far more likely to also be a fully remote job than ever before.

At this point, they're possibly quite excited. Unfortunately, I can't let them leave with that overly rosy picture of the profession.

So I add the following: "And it's always a delightful challenge when a certain percentage of your job involves controlled cognitive dissonance"

If asked to explain this, I point to my go-to example: the prevalence of myths that form the operating capital of the planning of almost every software development team, but which are known (to those in the team itself) as far too simplistic to actually be true. It seems an open secret that this is a large part of what the software team is actually being tasked to balance: that spectrum between the ideal (what was assumed by management in planning) and the actual (the true task at hand)*

*All of these are based solely on my own experience. Your mileage may vary. These views do not reflect dev.to, etc. etc.

Today, I am going to discuss one of these myths: the myth of the 'spec'.

In theory, a "spec" (or "specification") refers to a full description of the intended behavior of a particular software system. The system is expected to work according to its specification. Simple, easy, clean. And a beautiful fiction.

In practice, this is impossible practically, and, in most cases, theoretically, as well. For any sufficiently complicated system that is actively being worked on, the "correct" behavior is changing on a day by day basis. Especially in modern agile practice, there is no spec of any given system. Instead, there is the concept of a set of updates being applied to that system (termed the "product") during the continual execution of sprints as the primary deliverable of each sprint, with any time actually allocated towards documenting the system behavior a happy accident.

Now, I don't want it to be thought that no documentation is being produced. Quite the contrary. A form of documentation is actually being produced at a consistent and regular pace: that documentation is simply not a spec in any meaningful sense.

For, as all devs know, the sprints of agile are all orientated around textual records called "tickets". These are usually created at the request of other departments or upper management, not the dev team. They are, in their core essence, a description in vague terms of what is desired from whoever is requesting the change, made by someone who doesn't really understand how the system works (since they're not part of the dev team). Further, it is well understood these are more "conversation starters" than concrete specifications. As the sprint progresses, these tickets move through various stages, are updated with extra comments that might drastically change what is actually implemented as the developer starts looking into the feasibility of what is being asked, and eventually, they are marked "done"; the process then repeats with a new ticket. Hopefully, each ticket is updated to reflect what was actually done in some way, as well, but that is the core process and documentation of modern software development: the effective management of these tickets.

At best, tickets can be described as the meeting notes towards whatever the spec eventually ends up being. Thus they come with all the accompanying issues that such forms of human communication inevitably entail: they are almost never technically precise enough to describe the intended behavior, may in fact present contradictory information as knowledge of the true task at hand is hashed out and compromises are made, and often bear only a weak connection to what was actually implemented in the final change made. Worse, these are only shallowly linked: a ticket might link to another related ticket, but there is nothing linking all the tickets that relate to any particular feature together, so simply finding the past tickets relevant to the feature you're working on is literally looking for a needle in a haystack.

From these, and examination of the source code history (hopefully the developer last working on the part of the system you're working on left good commits, or at least still works at the company) developers try to piece together how a system is supposed to work, constrained by a need to ensure they don't devote too much time to any one ticket, as they have been tasked with the mission of completing all of them in the timeframe previously committed to when they were assigned.

In other words, a large part of a developer's job is to, repeatedly, derive a partial spec from a system, under highly restrictive time constraints, and present it to management for the purposes of them confirming the partial spec is, at least for the moment, correctly understood.

Only then can they work towards actually fixing whatever that violation is (in the case of "bugs"), or implementing whatever the new feature is (in the far rarer case of "feature requests"), which is the part of the job that is deemed the "real work" of the developer. Developers might be often thought of as mechanics fixing a never quite working system, but they're really tasked with attempting to create the semblance of an impossible to achieve fictional order (a "fully working implementation" - i.e. 100% "correct") out of what they have to work with: bits of chaos (vague notions of what whoever asking for the change believes the system should do, in that given circumstance, without affecting the remaining 99% of a highly interrelated system which is ill-defined; all of which has zero guarantee of even remaining "correct" after the work is done).

As such, for any non-trivial concrete question about the system's intended behavior, usually no one really knows how it works or is supposed to work, no matter how "seasoned" they are in the project: there are no true experts. They couldn't possibly in a system that is undergoing constant change for varied reasons, especially when it is understood that every day a particular "ticket" is left undone is one more than desired. In the trilemma of quick, cheap, or well-designed, quick is always implicitly encouraged even if well-designed is publicly preached.

Until they derive that partial spec, devs simply do not have enough information to make accurate estimates. What estimates they can give are far better represented by relative measures unrelated to time, making the idea that a sprint represents a set of tickets that developers have confidence they'll complete in a given timeframe another too-rosy fiction.

That dev teams manage to complete most sprints with most tickets "done" anyway is a result of highly skilled and intelligent individuals following the business's implicit ask of "whatever it takes" to try to meet whatever timeframe they've been given. This also means software systems, rarely if ever, have any true "Architect" or "Architecture" as those terms are usually understood. In practice, this is impossible anyway, since most modern software development teams, even when"self-organizing" (as agile recommends), have little actual influence on what is implemented or how it is implemented.

At best, software development teams (including the development manager, who often has little actual power, and can best be thought as the cheery face of management to the dev team and vice versa) have the role of first paid advisor, who presents various choices to those who have actual decision-making power and, secondly, faithful executor of the actual decision-makers. The idea that the dev team makes the final decision is a convenient fiction assumed at times, but false on its face. No idea of any import is possible without either stakeholder request or stakeholder "buy-in". Of course, "healthy debate" may be preached, but all developers really know that is of a highly limited form evaporating almost instantly at the mere risk that some particular looming deadline might be missed (which is often).

If you've read this far, I'm opening this question up to my fellow developers in the private salaried sphere especially: what other "myths" have you found consistent across the various development teams and companies you've worked for?

Alternatively, if you work on an open-source software project not driven primarily for-profit, is there more of a place for design discussions when developing, or is it largely the same as the for-profit?

As a dev, what do you think about time-tracking?

cwisefool — Sat, 29 Aug 2020 21:24:16 +0000

i.e. do you consider them a bureaucratic time-waste, a genuinely useful practice, or something more complicated? :)

Standup Styles: Evaluating 3 Approaches

cwisefool — Tue, 09 Jun 2020 18:21:13 +0000

If you've worked on a dev team for any length of time, you're probably familiar with "the standup": that daily, time-boxed, status update by all members of the team where each answers three questions: what was worked on, what will be worked on, and any blockers encountered so far. The emphasis is on keeping the meeting brief and time-boxed (typically 15 minutes or less).

While the basic goal of a brief time-boxed status update meeting are the same across all the teams I've worked on, I've noticed that specific details on the approach used can have a significant impact on how effective these meetings are. Below I briefly discuss 3 different approaches I've experienced, and what I see as the pros/cons of each, using the example of 3 fictitious teams.

Team A: Everyone gathers in the same room, and provides their updates one after another. No meeting notes are typically taken.
Team B: Everyone posts written status updates in a shared chat, followed by a shared call to answer any questions. No meeting notes are typically taken.
Team C: Everyone posts written status updates in a shared chat channel. Everyone signals they read each status update by posting a emojii reaction. Each status update is its own thread, and any questions about the status update are asked and answered in the appropriate thread (which serves as a form of meeting notes).

Team A's primary benefit is probably ease-of-adoption and simplicity. No additional tools are needed, and it can be conducted anywhere. It is probably the approach that teams just getting started with Agile often use. However it comes with some notable cons:

Temptation to ignore time-boxing constraint, causing meetings to drag on longer than the allotted time. Disclipine must be taken to ensure that each participant sticks to the time-boxed nature of the meeting by answering briefly. Especially when reporting on bugs, conversations have a tendency to derail into a problem-solving brainstorm unless carefully managed by the Scrum Master.
Since no meeting notes are taken, any decisions that come as a result of the standup are often forgotten soon after. Worse, as there is no written record of decisions and status updates, different team members might leave with contrasting views on what stage a task is in, what decision was reached, etc.

Team B's approach mitigates both issues with Team A's, although it does require all team members to use a shared chat:

The written nature of status updates helps trend toward brevity, as well as encouraging clarity in writing since each team member has the opportunity to compose and edit their update as much as desired prior to communicating it to the team.
The status updates themselves form a kind of meeting notes, helping to ensure a shared understanding of what stage a task is in.

However, the follow-up shared call can easily exceed the time-boxed allotment, as well as suffers from the same problems as Team A's approach for the status updates because any discussion that does occur is not recorded.

Team C's approach seems the best to me (and is the one currently employed by my current team). One nice addition is the use of emoji's to indicate that members have read an update as it helps provide visibility that all relevant parties are aware of the status of a task. Further, while standups typically discourage discussion to keep the time-boxed nature of the meeting, the use of threaded chats seems to provide a way to include discussion without it detracting significantly from the ability to quickly digest the status updates of each member. The main potential con I can think of is it might be more difficult for members that don't excel in communicating by writing.

For myself, I can't imagine going back to Team A's approach, and would only reluctantly go back to Team B's, but I'm curious to hear from the wider DEV community: what standup styles have you encountered? Which have you found to be effective (or not effective)? What best practices and anti-patterns have you observed?