Add MVP principle to bitreich style. - bitreich-style - Style guide for programmers.
HTML git clone git://bitreich.org/bitreich-style
DIR Log
DIR Files
DIR Refs
DIR Tags
DIR README
DIR LICENSE
---
DIR commit a9d1a41e65352022f88865d209269def59979346
DIR parent f428b125ec23c9c03c88380e2ecde62c04a943bf
HTML Author: Christoph Lohmann <20h@r-36.net>
Date: Sun, 22 Aug 2021 21:39:16 +0200
Add MVP principle to bitreich style.
Diffstat:
A MVP.txt | 115 +++++++++++++++++++++++++++++++
1 file changed, 115 insertions(+), 0 deletions(-)
---
DIR diff --git a/MVP.txt b/MVP.txt
@@ -0,0 +1,115 @@
+Original: gopher://katolaz.net/0/p/MVP.txt
+
+@var title = "Minimal Viable Programs"
+@var tags = "programming"
+
+A minimal viable program is the smallest program that solves a
+particular problem. It is small and beautiful. It has no additional
+features.
+
+If you removed a single feature it would be totally useless. If you
+added a new feature that feature would not be essential, you could use
+the program without making use of the new feature.
+
+Very few of the programs I use are minimal viable programs, but some
+are. I'll describe one such program. This is the ticket system that
+was used in the Erlang distribution.
+
+* The Erlang Ticket System
+
+The Erlang ticket system was designed and implemented by Peter Högfeldt
+in 1986. We needed a ticket system that was easy to use, intuitive,
+reliable and we wanted it yesterday, so Peter got the job, since he
+was very busy and didn't have time to take on any new jobs.
+
+If you want a job done find the busiest person you know and give them
+an extra job. This is because the reason they are busy is that lot's
+of people want them to do things because they are good at doing things
+and that's why they are busy.
+
+Peter built the ticket system in a couple of hours and we've been
+using it ever since. I guess the couple of hours were divided into an
+hours drinking coffee and drawing things on a white board and twenty
+minutes programming.
+
+* The Ticket System
+
+Peter's ticket system was simple in the extreme. There was one command.
+You typed **newticket** in the shell and got an integer back. Like this:
+
+$ new_ticket
+
+
+The system had made a new file in `${HOME}/tickets/23` and the content
+of the file would be:
+
+ticket: 23
+responsible:joe@erix
+status:open
+title: ?
+----
+Describe your problem here
+
+This file was also checked into a global CVS archive that all project
+members had access to. Today one might use GIT or SVN but any revision
+control system would do.
+
+The ticket system had a few simple rules:
+
++ The status is open or closed
++ The responsible person cannot be changed to somebody new without the permission of the new person
+
+Project management wanted a reporting system. This was pretty easy,
+this was done with a few simple shell scripts. For example to
+find the number of open tickets a simple shell script does the job:
+
+#!/bin/sh
+grep 'status:open' ${HOME}/tickets/* | wc
+
+The first ticket system was operational in 1985 and we have used it ever since.
+
+* Adding features
+
+Do we need to add additional features? The first point to note is
+there is no time or dates - but wait a moment, this file is checked into
+a revision control system, so the times when the file is created and modified
+are in the revision control system and do not need to be added to the ticket.
+
+* What happened later?
+
+Feature were added - but none that broke the original spirit of the design.
+
+* But we can't make money from a MVP
+
+ Many companies sell ``features'' - so a MVP will be useless - a product
+needs new features. But the MVP program will do exactly the same thing
+in 100 years time as it did yesterday.
+
+New features mean new sales opportunities, good for the company but
+not good for the user.
+
+New features mean new untested code, and backwards incompatibility
+with earlier versions of the program. Things that are stable for a
+long time are good.
+
+The problem with adding features to MVP is that when we ship more
+complex products like complete operating systems that are packed with
+programs, the complexity of the individual programs contributes to the
+complexity of the whole.
+
+If a system shipped with one complex program it probably would not
+matter - and it's difficult to imagine the idea of a MVP applying to
+a complex program like photoshop.
+
+If the individual components in a system are not MVPs we will soon be
+overburdened by complexity when we start combining programs to build
+larger systems.
+
+If we to have any control over complexity then we should ensure that the
+basic components are MVPs.
+
+I really like systems that do one essential thing and do it well.
+Good examples are Dropbox and Twitter. Dropbox just works. Twitter
+has a no fuss 140 character tweet box. Simple, easy to understand
+and minimalist.
+