From 07e4a2dafe248280b5610f8c7d09b0f30b530f54 Mon Sep 17 00:00:00 2001 From: Bradley Taunt Date: Mon, 10 Jun 2024 09:41:25 -0400 Subject: Initial modifications to rebuilt only changed files based on mod date, performance updates --- build/af/index.html | 63 ----------------------------------------------------- 1 file changed, 63 deletions(-) delete mode 100644 build/af/index.html (limited to 'build/af/index.html') diff --git a/build/af/index.html b/build/af/index.html deleted file mode 100644 index 4fcce2d..0000000 --- a/build/af/index.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - - Avoiding Featurism - - - - - - - -
-

Avoiding Featurism

-

2022-10-14

-

I rather enjoy the term “featurism”. I came across this term while reading the wonderful article Why I don’t use Netscape, which the author credits to Bernd Paysan. Although it sums up the current “digital product” industry quite well the more specific terminology, creeping featurism, works better:

-
-

creeping featurism (noun)

-

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.

-
-

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 “featurism” is there is no single person to blame. It probably seems easy to place all the responsibility on PMs or team leaders, but even if 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 whole team needs to be on-guard to avoid it.

-

Simple Guidelines

-

These “tips” 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.

- -

That’s it. Just a nice, simple baseline to branch off from to avoid “featurism”. Some items listed won’t make sense for certain teams and that’s okay. If you take the time to at least reflect on your feature workflow, I guarantee you’ll find areas to improve.

-

Creeping featurism can kill your product and the morale of your team. Avoid it like the plague!

-

Refs

-
    -
  1. This is easier said than done. Normally you will need to have developed some form of “point system” internally, so you know how to effectively divide features.
    2. -
  2. Taking away complexity, making changes that do not impact workload or reducing the ticket is fine - within reason.
    3. -
- \ No newline at end of file -- cgit v1.2.3-54-g00ecf