|
|
MVP.txt - bitreich-style - Style guide for programmers. |
|
|
 |
git clone git://bitreich.org/bitreich-style (git://bitreich.org) |
|
|
 |
Log |
|
|
|
Files |
|
|
|
Refs |
|
|
|
Tags |
|
|
|
README |
|
|
|
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 |
|