The Microwave With Feature Creep
Find the English version below
Hi ,
Also: Eine neue muss her.
Ich habe hier aber einen kleinen Tick. Das betrifft alles unvergängliche das ich kaufe. Ich will einen Fehlkauf vermeiden. Lieber einmal mehr Geld ausgeben, als in zwei Jahren wieder neu kaufen.
Hier muss ich aufpassen nicht in einer Rabbit-Hole zu landen. Ich kann Stunden in das Lesen von Reviews versenken.
Aber was will ich überhaupt vergleichen?
Als erstes Kommt die Anforderungsanalyse
Bevor ich überhaupt zwischen Modellen vergleichen kann, muss ich mir klar werden was ich eigentlich brauche.
Meine alte Mikrowelle war fancy. Sie hatte 21 verschiedene Programme: Auftauen, Aufwärmen, Heißgetränke, Hühnchen, Suppe, Steak, Popcorn, Pizza, Burger, Sandwich, 5-Sterne-Menü….
Okay, vielleicht habe ich mir ein paar davon ausgedacht.
Aber es hat sich genauso angefühlt!
Die Mikrowelle konnte “alles”.
Als ich sie kaufte fand ich das cool. Ich könnte ja dadurch ganz viel Zeit und Energie sparen. Dann brauche ich ja nicht mehr so oft den Ofen anmachen.
Letztlich habe ich diese Funktionen nie genutzt
Die Grillfunktion lief genau einmal…
Ausversehen…
Und sie schmolz meine Plastikabdeckung. Nice!
Also, was brauche ich wirklich? Jedenfalls keine Grillfunktion.
Ich brauche auch keine Programme. In der Praxis hat jeder selbst die Dauer und die Leistung (Watt) eingestellt.
Wichtig ist mir eine lange Lebenszeit
Ich habe keine Lust in zwei Jahren schon wieder einen neue Mikrowelle zu kaufen.
Und wann ist etwas stabil? Wenn es einfach ist.
Viele Features heißt auch: Vieles kann kaputt gehen.
Feature Creep gibt es auch in der Softwareentwicklung
Was ich gerade an meine Mikrowelle beschrieben habe, gilt auch für die Sofwareentwicklung! Es ist leicht sich viele tolle Features auszudenken. Wir bauen sie alle fleißig ein. Aber brauchen wir sie auch? Werden sie wirklich benutzt? Oder sind sie nur “nice-to-have”?
Jedes Feature kommt mit Kosten.
Und das geht über die Implementierung hinaus.
Irgendwann wird es in deinem Feature ein Bug geben.
Dann muss sich wieder jemand damit auseinandersetzen.
Oder irgendwann erweiterst du einen Teil deiner Applikation und plötzlich musst du das “nice-to-have”-Feature mit berücksichtigen. Das kostet wieder Zeit.
Wir bauen einen Lasttest? Naja, das “nice-to-have”-Feature muss mit getestet werden.
In der Praxis haben wir nicht 1 solches Feature, nein. Wir haben 100 von der Sorte. Ist der Calendar-View bei der Eingabe wirklich nötig? Müssen die Kunden wirklich ihren Adminbereich branden? Ist es notwendig, dass der Kunde persönliche Notizen an seine Daten heften kann? Braucht die Mikrowelle wirklich ein Popcorn-Programm?
Konzentriere dich auf das wesentliche in deiner Anwendung
Du hast einen USP. Es gibt eine Kernfunktionalität.
Wegen dieser sind deine Kunden bei dir.
Alles andere ist zweitranging.
Am Ende habe ich übrigens diese Mikrowelle gekauft. Ohne Schnick-Schnack.
Rule the Backend,
~ Marcus
Hi ,
So: I need a new one.
However, I have a little quirk when it comes to buying anything that's not perishable. I want to avoid making a bad purchase. I'd rather spend more money once than have to buy a new one in two years.
Here, I have to be careful not to fall down a rabbit hole. I can spend hours reading reviews.
But what do I even want to compare?
First Comes the Requirement Analysis
Before I can compare models, I need to understand what I actually need.
My old microwave was fancy. It had 21 different programs: thawing, reheating, hot beverages, chicken, soup, steak, popcorn, pizza, burger, sandwich, 5-star menu...
Okay, maybe I made up a few of those.
But it felt that way!
The microwave could do "everything."
When I bought it, I thought that was cool. I could save so much time and energy. Then I wouldn't have to use the oven so often.
Ultimately, I Never Used These Features
I used the grill function exactly once...
By accident...
And it melted my plastic cover. Nice!
So, what do I really need? Certainly not a grill function.
I also don't need any programs. In practice, everyone sets the duration and power (wattage) themselves.
A Long Lifespan Is Important to Me
I don't want to have to buy a new microwave in two years.
And when is something stable? When it's simple.
Many features mean: many things can break.
Feature Creep Also Exists in Software Development
What I just described about my microwave also applies to software development! It's easy to think of many great features. We eagerly implement them all. But do we really need them? Are they actually used? Or are they just "nice-to-have"?
Every feature comes with a cost.
And this goes beyond the implementation.
Eventually, There Will Be a Bug in Your Feature
Then someone will have to deal with it again.
Or someday you'll expand a part of your application, and suddenly you'll have to consider that "nice-to-have" feature. This takes more time again.
We're building a load test? Well, the "nice-to-have" feature needs to be tested too.
In practice, we don't have just one such feature, no. We have hundreds of them. Is the calendar view really necessary when entering data? Do customers really need to brand their admin area? Is it necessary for the customer to attach personal notes to their data? Does the microwave really need a popcorn program?
Focus on the Essentials in Your Application
You have a USP (Unique Selling Proposition). There is a core functionality.
That's why your customers are with you.
Everything else is secondary.
In the end, by the way, I bought this microwave. No frills.
Rule the Backend,
~ Marcus