MVP.txt - bitreich-style - Style guide for programmers.
(HTM) git clone git://bitreich.org/bitreich-style
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) Tags
(DIR) README
(DIR) LICENSE
---
MVP.txt (4190B)
---
1 Original: gopher://katolaz.net/0/p/MVP.txt
2
3 @var title = "Minimal Viable Programs"
4 @var tags = "programming"
5
6 A minimal viable program is the smallest program that solves a
7 particular problem. It is small and beautiful. It has no additional
8 features.
9
10 If you removed a single feature it would be totally useless. If you
11 added a new feature that feature would not be essential, you could use
12 the program without making use of the new feature.
13
14 Very few of the programs I use are minimal viable programs, but some
15 are. I'll describe one such program. This is the ticket system that
16 was used in the Erlang distribution.
17
18 * The Erlang Ticket System
19
20 The Erlang ticket system was designed and implemented by Peter Högfeldt
21 in 1986. We needed a ticket system that was easy to use, intuitive,
22 reliable and we wanted it yesterday, so Peter got the job, since he
23 was very busy and didn't have time to take on any new jobs.
24
25 If you want a job done find the busiest person you know and give them
26 an extra job. This is because the reason they are busy is that lot's
27 of people want them to do things because they are good at doing things
28 and that's why they are busy.
29
30 Peter built the ticket system in a couple of hours and we've been
31 using it ever since. I guess the couple of hours were divided into an
32 hours drinking coffee and drawing things on a white board and twenty
33 minutes programming.
34
35 * The Ticket System
36
37 Peter's ticket system was simple in the extreme. There was one command.
38 You typed **newticket** in the shell and got an integer back. Like this:
39
40 $ new_ticket
41
42
43 The system had made a new file in `${HOME}/tickets/23` and the content
44 of the file would be:
45
46 ticket: 23
47 responsible:joe@erix
48 status:open
49 title: ?
50 ----
51 Describe your problem here
52
53 This file was also checked into a global CVS archive that all project
54 members had access to. Today one might use GIT or SVN but any revision
55 control system would do.
56
57 The ticket system had a few simple rules:
58
59 + The status is open or closed
60 + The responsible person cannot be changed to somebody new without the permission of the new person
61
62 Project management wanted a reporting system. This was pretty easy,
63 this was done with a few simple shell scripts. For example to
64 find the number of open tickets a simple shell script does the job:
65
66 #!/bin/sh
67 grep 'status:open' ${HOME}/tickets/* | wc
68
69 The first ticket system was operational in 1985 and we have used it ever since.
70
71 * Adding features
72
73 Do we need to add additional features? The first point to note is
74 there is no time or dates - but wait a moment, this file is checked into
75 a revision control system, so the times when the file is created and modified
76 are in the revision control system and do not need to be added to the ticket.
77
78 * What happened later?
79
80 Feature were added - but none that broke the original spirit of the design.
81
82 * But we can't make money from a MVP
83
84 Many companies sell ``features'' - so a MVP will be useless - a product
85 needs new features. But the MVP program will do exactly the same thing
86 in 100 years time as it did yesterday.
87
88 New features mean new sales opportunities, good for the company but
89 not good for the user.
90
91 New features mean new untested code, and backwards incompatibility
92 with earlier versions of the program. Things that are stable for a
93 long time are good.
94
95 The problem with adding features to MVP is that when we ship more
96 complex products like complete operating systems that are packed with
97 programs, the complexity of the individual programs contributes to the
98 complexity of the whole.
99
100 If a system shipped with one complex program it probably would not
101 matter - and it's difficult to imagine the idea of a MVP applying to
102 a complex program like photoshop.
103
104 If the individual components in a system are not MVPs we will soon be
105 overburdened by complexity when we start combining programs to build
106 larger systems.
107
108 If we to have any control over complexity then we should ensure that the
109 basic components are MVPs.
110
111 I really like systems that do one essential thing and do it well.
112 Good examples are Dropbox and Twitter. Dropbox just works. Twitter
113 has a no fuss 140 character tweet box. Simple, easy to understand
114 and minimalist.
115