aboutsummaryrefslogtreecommitdiff
path: root/build/posts/af/index.html
diff options
context:
space:
mode:
authorBradley Taunt <bt@btxx.org>2024-06-10 09:41:25 -0400
committerBradley Taunt <bt@btxx.org>2024-06-10 09:41:25 -0400
commit07e4a2dafe248280b5610f8c7d09b0f30b530f54 (patch)
tree8a145d1d4d07e1278a837ff15dadccc322d27515 /build/posts/af/index.html
parent16d28628aca9b2d356de31c319f5e7bc0f5b2b02 (diff)
Initial modifications to rebuilt only changed files based on mod date, performance updates
Diffstat (limited to 'build/posts/af/index.html')
-rw-r--r--build/posts/af/index.html63
1 files changed, 63 insertions, 0 deletions
diff --git a/build/posts/af/index.html b/build/posts/af/index.html
new file mode 100644
index 0000000..4fcce2d
--- /dev/null
+++ b/build/posts/af/index.html
@@ -0,0 +1,63 @@
+<!doctype html>
+<html lang="en">
+<head>
+ <meta charset="utf-8">
+ <meta name="viewport" content="width=device-width, initial-scale=1">
+ <meta name="color-scheme" content="dark light">
+ <link rel="icon" href="data:,">
+ <title>Avoiding Featurism</title>
+ <link href="/atom.xml" type="application/atom+xml" rel="alternate" title="Atom feed for blog posts" />
+ <link href="/rss.xml" type="application/rss+xml" rel="alternate" title="RSS feed for blog posts" />
+<style>*{box-sizing:border-box;}body{font-family:sans-serif;line-height:1.33;margin:0 auto;max-width:650px;padding:1rem;}blockquote{background:rgba(0,0,0,0.1);border-left:4px solid;padding-left:5px;}img{max-width:100%;}pre{border:1px solid;overflow:auto;padding:5px;}table{text-align:left;width:100%;}.footnotes{font-size:90%;}</style>
+</head>
+
+<nav>
+ <a href="#menu">Menu &darr;</a>
+</nav>
+
+<main>
+<h1 id="avoiding-featurism">Avoiding Featurism</h1>
+<p>2022-10-14</p>
+<p>I rather enjoy the term &#8220;featurism&#8221;. I came across this term while reading the wonderful article <a href="https://www.complang.tuwien.ac.at/anton/why-ancient-browsers.html">Why I don&#8217;t use Netscape</a>, which the author credits to Bernd Paysan. Although it sums up the current &#8220;digital product&#8221; industry quite well the more specific terminology, <em>creeping featurism</em>, works better:</p>
+<blockquote>
+<p><strong>creeping featurism</strong> (<em>noun</em>)</p>
+<p>A condition in which one or more people, often in the form of a committee, progressively increase the scope and complexity of a project until the project is deemed infeasible and subsequently cancelled to the detriment of all involved.</p>
+</blockquote>
+<p>Throughout my career of designing and developing software I have run into this exact issue far too often. The major issue with getting sucked into a black-hole of &#8220;featurism&#8221; is there is no single person to blame. It probably seems easy to place all the responsibility on PMs or team leaders, but even <em>if</em> they are the ones adding excessive complexity to a given project, it is the role of developers and designers to speak up. It requires a team effort. Therefore, the <em>whole team</em> needs to be on-guard to avoid it.</p>
+<h3 id="simple-guidelines">Simple Guidelines</h3>
+<p>These &#8220;tips&#8221; are not perfect, nor will they work for every work environment. Hopefully they can at least be used as basic guidelines and expanded upon from there.</p>
+<ul>
+<li>Explore the feature&#8217;s <em>benefit</em> to the product. You need to confirm that this addition will be a net-positive for both customers and your bottom-line.</li>
+<li>All team members assigned to a feature need to scope it out. Far too often I see feature sets that require design input being estimated solely by developers and vice versa.</li>
+<li>Radically limit the scope of each individual task[^1]. Each task should be clear-cut, bite-sized and look almost trivial.</li>
+<li>Lock-in tickets. Once they are agreed upon they <strong>cannot</strong> be altered[^2]. Anything that absolutely <em>needs</em> to be added should become a future ticket itself.</li>
+<li>Follow-up with feature reviews. When a sprint or milestone is reached, it is important to reflect on what worked and what didn&#8217;t. Call out any instances where the team steered away from the guidelines above.</li>
+</ul>
+<p>That&#8217;s it. Just a nice, simple baseline to branch off from to avoid &#8220;featurism&#8221;. Some items listed won&#8217;t make sense for certain teams and that&#8217;s okay. If you take the time to at least reflect on your feature workflow, I guarantee you&#8217;ll find areas to improve.</p>
+<p>Creeping featurism can kill your product and the morale of your team. Avoid it like the plague!</p>
+<h2 id="refs">Refs</h2>
+<ol>
+<li>This is easier said than done. Normally you will need to have developed some form of &#8220;point system&#8221; internally, so you know how to effectively divide features.</li>
+<li><em>Taking away</em> complexity, making changes that do not impact workload or reducing the ticket is fine - within reason.</li>
+</ol>
+<footer role="contentinfo">
+ <h2>Menu Navigation</h2>
+ <ul id="menu">
+ <li><a href="/">Home</a></li>
+ <li><a href="/projects">Projects</a></li>
+ <li><a href="/uses">Uses</a></li>
+ <li><a href="/wiki">Wiki</a></li>
+ <li><a href="/resume">Resume</a></li>
+ <li><a href="/colophon">Colophon</a></li>
+ <li><a href="/now">Now</a></li>
+ <li><a href="/donate">Donate</a></li>
+ <li><a href="/atom.xml">RSS</a></li>
+ <li><a href="#top">&uarr; Top of the page</a></li>
+ </ul>
+ <small>
+ Built with <a href="https://git.sr.ht/~bt/barf">barf</a>. <br>
+ Maintained with ♥ for the web. <br>
+ Proud supporter of <a href="https://usefathom.com/ref/DKHJVX">Fathom</a> &amp; <a href="https://nextdns.io/?from=74d3p3h8">NextDNS</a>. <br>
+ The content for this site is <a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>.<br> The <a href="https://git.sr.ht/~bt/bt.ht">code for this site</a> is <a href="https://git.sr.ht/~bt/bt.ht/tree/master/item/LICENSE">MIT</a>.
+ </small>
+</footer> \ No newline at end of file