419
|
1 |
-*- mode: outline; coding: utf-8 -*-
|
|
2 |
|
|
3 |
* General discussion.
|
|
4 |
|
|
5 |
See
|
|
6 |
|
|
7 |
http://en.wikipedia.org/wiki/List_of_software_development_philosophies
|
|
8 |
http://en.wikipedia.org/wiki/List_of_eponymous_laws
|
|
9 |
|
|
10 |
* Principle of good enough (POGE).
|
|
11 |
|
|
12 |
It favours quick-and-simple (but potentially extensible) designs over
|
|
13 |
elaborate systems designed by committees.
|
|
14 |
|
|
15 |
Once the quick-and-simple design is deployed, it can then evolve as needed,
|
|
16 |
driven by user requirements.
|
|
17 |
|
|
18 |
This kind of design is not appropriate in systems where it is not possible to
|
|
19 |
evolve the system over time, or where the full functionality is required from
|
|
20 |
the start.
|
|
21 |
|
|
22 |
See
|
|
23 |
|
|
24 |
http://en.wikipedia.org/wiki/Principle_of_good_enough
|
|
25 |
|
|
26 |
* No Silver Bullet.
|
|
27 |
|
|
28 |
There is no single development, in either technology or management technique,
|
|
29 |
which by itself promises even one order of magnitude improvement within a
|
|
30 |
decade in productivity, in reliability, in simplicity.
|
|
31 |
|
|
32 |
See
|
|
33 |
|
|
34 |
http://en.wikipedia.org/wiki/No_Silver_Bullet
|
|
35 |
|
|
36 |
* Rule of thumb.
|
|
37 |
|
|
38 |
A rule of thumb is a principle that postulate in some case use simple
|
|
39 |
procedure wich produce approximate result instead use complex but exact
|
|
40 |
produce.
|
|
41 |
|
|
42 |
See
|
|
43 |
|
|
44 |
http://en.wikipedia.org/wiki/Rule_of_thumb
|
|
45 |
|
|
46 |
* The Zero One or Infinity.
|
|
47 |
|
|
48 |
The Zero One or Infinity (ZOI) rule is a rule of thumb in software design. It
|
|
49 |
suggests that arbitrary limits on the number of instances of a particular
|
|
50 |
entity should not be allowed. Specifically, that an entity should either be
|
|
51 |
forbidden entirely, one should be allowed, or any number (presumably, to the
|
|
52 |
limit of available storage) of them should be allowed. It should not be the
|
|
53 |
software that puts a hard limit on the number of instances of the entity.
|
|
54 |
|
|
55 |
http://en.wikipedia.org/wiki/Zero_One_Infinity
|
|
56 |
|
|
57 |
* 80-20 rule (pareto principle).
|
|
58 |
|
|
59 |
This rule postulate that roughly 80% of the effects come from 20% of the
|
|
60 |
causes.
|
|
61 |
|
|
62 |
This rule applied to optimisation (most time spent by program only by little
|
|
63 |
piece of code), functionality (80% of users use only 20% of program
|
|
64 |
functionality); bugs (fixing the top 20% of most reported bugs solve 80% of
|
|
65 |
the error and crashes).
|
|
66 |
|
|
67 |
See
|
|
68 |
|
|
69 |
http://en.wikipedia.org/wiki/80:20_rule
|
|
70 |
|
|
71 |
* 1% rule.
|
|
72 |
|
|
73 |
The 1% rule states that the number of people who create content on the
|
|
74 |
internet represents approximately 1% (or less) of the people actually viewing
|
|
75 |
that content.
|
|
76 |
|
|
77 |
See
|
|
78 |
|
|
79 |
http://en.wikipedia.org/wiki/1%25_rule_%28Internet_culture%29
|
|
80 |
|
|
81 |
* Parkinson's Law.
|
|
82 |
|
|
83 |
Work expands so as to fill the time available for its completion.
|
|
84 |
|
|
85 |
Data expands to fill the space available for storage.
|
|
86 |
|
|
87 |
See
|
|
88 |
|
|
89 |
http://en.wikipedia.org/wiki/Parkinson%27s_law
|
|
90 |
|
|
91 |
* Ninety-ninety rule.
|
|
92 |
|
|
93 |
The first 90% of the code accounts for the first 10% of the development time.
|
|
94 |
The remaining 10% of the code accounts for the other 90% of the development
|
|
95 |
time.
|
|
96 |
|
|
97 |
See
|
|
98 |
|
|
99 |
http://en.wikipedia.org/wiki/Ninety-ninety_rule
|
|
100 |
|
|
101 |
* Wirth's law.
|
|
102 |
|
|
103 |
Software is getting slower more rapidly than hardware becomes faster.
|
|
104 |
|
|
105 |
See
|
|
106 |
|
|
107 |
http://en.wikipedia.org/wiki/Wirth%27s_law
|
|
108 |
|
|
109 |
* Student syndrome.
|
|
110 |
|
|
111 |
Student syndrome refers to the phenomenon that many people will start to fully
|
|
112 |
apply themselves to a task just at the last possible moment before a deadline.
|
|
113 |
|
|
114 |
The student syndrome is a form of procrastination ().
|
|
115 |
|
|
116 |
See
|
|
117 |
|
|
118 |
http://en.wikipedia.org/wiki/Student_syndrome
|
|
119 |
|
|
120 |
* Conway's Law.
|
|
121 |
|
|
122 |
...organizations which design systems ... are constrained to produce designs
|
|
123 |
which are copies of the communication structures of these organizations.
|
|
124 |
|
|
125 |
Example: Consider a two-person team of software engineers, A and B. Say A
|
|
126 |
designs and codes a software class X. Later, the team discovers that class X
|
|
127 |
needs some new features. If A adds the features, A is likely to simply expand
|
|
128 |
X to include the new features. If B adds the new features, B may be afraid of
|
|
129 |
breaking X, and so instead will create a new derived class X2 that inherits
|
|
130 |
X's features, and puts the new features in X2. So the final design is a
|
|
131 |
reflection of who implemented the functionality.
|
|
132 |
|
|
133 |
A real life example: NASA's Mars Climate Orbiter crashed because one team used
|
|
134 |
United States customary units (e.g., inches, feet and pounds) while the other
|
|
135 |
used metric units for a key spacecraft operation.
|
|
136 |
|
|
137 |
See
|
|
138 |
|
|
139 |
http://en.wikipedia.org/wiki/Conway%27s_Law
|
|
140 |
|
|
141 |
* Brooks's law.
|
|
142 |
|
|
143 |
It takes some time for the people added to a project to become productive.
|
|
144 |
|
|
145 |
Communication overheads increase as the number of people increases.
|
|
146 |
|
|
147 |
Adding manpower to a late software project makes it later.
|
|
148 |
|
|
149 |
See
|
|
150 |
|
|
151 |
http://en.wikipedia.org/wiki/Brooks%27_law
|
|
152 |
|
|
153 |
* Code bloat.
|
|
154 |
|
|
155 |
Code bloat is the production of code that is perceived as unnecessarily long,
|
|
156 |
slow, or otherwise wasteful of resources. Code bloat generally refers to
|
|
157 |
source code size but sometimes is used to refer to the generated code size or
|
|
158 |
even the binary file size.
|
|
159 |
|
|
160 |
http://en.wikipedia.org/wiki/Code_bloat
|
|
161 |
|
|
162 |
* Beerware.
|
|
163 |
|
|
164 |
Beerware is term for software released under a very relaxed license. It
|
|
165 |
provides the end user with the right to use a particular program.
|
|
166 |
|
|
167 |
Should the user of the product meet the author and consider the software
|
|
168 |
useful, he is encouraged to buy the author a beer 'in return' (or, in some
|
|
169 |
variations, drink a beer in the author's honor).
|
|
170 |
|
|
171 |
/* ----------------------------------------------------------------------------
|
|
172 |
* "THE BEER-WARE LICENSE" (Revision 42):
|
|
173 |
* <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
|
|
174 |
* can do whatever you want with this stuff. If we meet some day, and you think
|
|
175 |
* this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
|
|
176 |
* ----------------------------------------------------------------------------
|
|
177 |
*/
|
|
178 |
|
|
179 |
http://en.wikipedia.org/wiki/Beerware
|
|
180 |
|
|
181 |
* Demoware.
|
|
182 |
|
|
183 |
Demoware (also known as trialware) is commercial software released for free
|
|
184 |
(shareware) in a version which is limited in one or more ways.
|
|
185 |
|
|
186 |
http://en.wikipedia.org/wiki/Demoware
|
|
187 |
|
|
188 |
* Crippleware.
|
|
189 |
|
|
190 |
Crippleware is any product whose functions have been limited (or "crippled")
|
|
191 |
with the sole purpose of encouraging or requiring the user to pay for those
|
|
192 |
functions (either by paying a one-time fee or an on-going subscription fee).
|
|
193 |
Crippleware is also a term used to describe software that makes use of Digital
|
|
194 |
Rights Management.
|
|
195 |
|
|
196 |
http://en.wikipedia.org/wiki/Crippleware
|
|
197 |
|
|
198 |
* Nagware.
|
|
199 |
|
|
200 |
Nagware (also known as begware, annoyware or a nagscreen) is a type of
|
|
201 |
shareware that reminds (or nags) the user to register it by paying a fee. It
|
|
202 |
usually does this by popping up a message when the user starts the program, or
|
|
203 |
intermittently while the user is using the application. These messages can
|
|
204 |
appear as windows obscuring part of the screen or message boxes that can
|
|
205 |
quickly be closed. Some nagware keeps the message up for a certain time
|
|
206 |
period, forcing the user to wait to continue to use the program.
|
|
207 |
|
|
208 |
http://en.wikipedia.org/wiki/Nagware
|
|
209 |
|
|
210 |
* Registerware.
|
|
211 |
|
|
212 |
Registerware refers to computer software which requires the user to give
|
|
213 |
personal information, e.g an email address, through registration in order to
|
|
214 |
download or use the program.
|
|
215 |
|
|
216 |
http://en.wikipedia.org/wiki/Registerware
|
|
217 |
|
|
218 |
* Scareware.
|
|
219 |
|
|
220 |
Scareware comprises several classes of scam software, often with limited or no
|
|
221 |
benefit, sold to consumers via certain unethical marketing practices.
|
|
222 |
|
|
223 |
http://en.wikipedia.org/wiki/Scareware
|
|
224 |
|
|
225 |
* Donationware.
|
|
226 |
|
|
227 |
Donationware is a licensing model that supplies fully operational software to
|
|
228 |
the user and pleads for an optional donation be paid to the programmer or a
|
|
229 |
third-party beneficiary (usually a non-profit). The amount of the donation may
|
|
230 |
also be stipulated by the author, or it may be left to the discretion of the
|
|
231 |
user, based on individual perceptions of the software's value. Since
|
|
232 |
donationware comes fully operational (i.e. not crippleware) and payment is
|
|
233 |
optional, it is a type of freeware.
|
|
234 |
|
|
235 |
http://en.wikipedia.org/wiki/Donationware
|
|
236 |
|
|
237 |
* Freeware.
|
|
238 |
|
|
239 |
Freeware is computer software that is available for use at no cost or for an
|
|
240 |
optional fee.
|
|
241 |
|
|
242 |
http://en.wikipedia.org/wiki/Freeware
|
|
243 |
|
|
244 |
* Shareware.
|
|
245 |
|
|
246 |
Shareware is proprietary software that is provided to users without payment on
|
|
247 |
a trial basis and is often limited by any combination of functionality,
|
|
248 |
availability or convenience. Shareware is often offered as a download from an
|
|
249 |
Internet website or as a compact disc included with a magazine.
|
|
250 |
|
|
251 |
The rationale behind shareware is to give buyers the opportunity to use the
|
|
252 |
program and judge its usefulness before purchasing a license for the full
|
|
253 |
version of the software.
|
|
254 |
|
|
255 |
The words "free trial" or "trial version" are indicative of shareware.
|
|
256 |
|
|
257 |
http://en.wikipedia.org/wiki/Shareware
|
|
258 |
|
|
259 |
* Software bloat.
|
|
260 |
|
|
261 |
Software bloat is a term used to describe the tendency of newer computer
|
|
262 |
programs to have a larger installation footprint, or have many unnecessary
|
|
263 |
features that are not used by end users, or just generally use more system
|
|
264 |
resources than necessary, while offering little or no benefit to its users.
|
|
265 |
|
|
266 |
|
|
267 |
Comparison of Microsoft Windows minimum hardware requirements (for 32-bit
|
|
268 |
versions):
|
|
269 |
|
|
270 |
Windows version Processor Memory Hard disk
|
|
271 |
Windows 95[4] 25 MHz 4 MB ~50 MB
|
|
272 |
Windows 98[5] 66 MHz 16 MB ~200 MB
|
|
273 |
Windows 2000[6] 133 MHz 32 MB 650 MB
|
|
274 |
Windows XP[7] 233 MHz 64 MB 1.5 GB
|
|
275 |
Windows Vista[8] 800 MHz 512 MB 15 GB
|
|
276 |
Windows 7[9] 1 GHz 1 GB 16 GB
|
|
277 |
|
|
278 |
Every program attempts to expand until it can read mail. Those programs which
|
|
279 |
cannot so expand are replaced by ones which can.
|
|
280 |
-- Jamie Zawinski
|
|
281 |
|
|
282 |
** Foistware.
|
|
283 |
|
|
284 |
Foistware, Bloatware, or Bundler is software bundled with completely unrelated
|
|
285 |
programs. That means that there is no particular property in the software that
|
|
286 |
makes it foistware, but rather the context in which it was installed.
|
|
287 |
|
|
288 |
http://en.wikipedia.org/wiki/Foistware
|
|
289 |
|
|
290 |
** Bloatware.
|
|
291 |
|
|
292 |
Software bloat is a term used to describe the tendency of newer computer
|
|
293 |
programs to have a larger installation footprint, or have many unnecessary
|
|
294 |
features that are not used by end users, or just generally use more system
|
|
295 |
resources than necessary, while offering little or no benefit to its users.
|
|
296 |
Bloatware, or foistware, is also used to describe software that comes
|
|
297 |
pre-installed on a computer when it's bought, mostly consisting of
|
|
298 |
time-limited trials or feature-lacking basic or "beginner" versions.
|
|
299 |
|
|
300 |
http://en.wikipedia.org/wiki/Bloatware
|
|
301 |
|
|
302 |
** Shovelware.
|
|
303 |
|
|
304 |
Shovelware is sometimes used to denote foistware which was chosen to fill up
|
|
305 |
the remaining space on a freely distributed CD-ROM.
|
|
306 |
|
|
307 |
http://en.wikipedia.org/wiki/Shovelware
|
|
308 |
|
|
309 |
* Second-system effect.
|
|
310 |
|
|
311 |
In computing, the second-system effect or sometimes the second-system syndrome
|
|
312 |
refers to the tendency, when following on from a relatively small, elegant,
|
|
313 |
and successful system, to design the successor as an elephantine,
|
|
314 |
feature-laden monstrosity. The term was first used by Fred Brooks in his
|
|
315 |
classic The Mythical Man-Month.[1] It described the jump from a set of simple
|
|
316 |
operating systems on the IBM 700/7000 series to OS/360 on the 360 series.
|
|
317 |
|
|
318 |
* Inner-platform effect.
|
|
319 |
|
|
320 |
The inner-platform effect is the tendency of software architects to create a
|
|
321 |
system so customizable as to become a replica, and often a poor replica, of
|
|
322 |
the software development platform they are using.
|
|
323 |
|
|
324 |
XXX read more http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx
|
|
325 |
|
|
326 |
http://en.wikipedia.org/wiki/Inner-platform_effect
|
|
327 |
|
|
328 |
* Feature creep.
|
|
329 |
|
|
330 |
Feature creep is the proliferation of features in a product such as computer
|
|
331 |
software. Extra features go beyond the basic function of the product and so
|
|
332 |
can result in baroque over-complication, or "featuritis", rather than simple,
|
|
333 |
elegant design.
|
|
334 |
|
|
335 |
http://en.wikipedia.org/wiki/Feature_creep
|
|
336 |
|
|
337 |
* Bullet-point engineering.
|
|
338 |
|
|
339 |
Bullet-point engineering is a software design anti-pattern where developers
|
|
340 |
use the features of competing software packages as checklists of features to
|
|
341 |
implement in their own product. These features are often implemented poorly
|
|
342 |
and haphazardly, without any real design, merely so they can be added to a
|
|
343 |
bulleted list of features in marketing material. Bullet point engineering
|
|
344 |
often leads to feature creep and software bloat but may also simply result in
|
|
345 |
a poorly designed imitative product.
|
|
346 |
|
|
347 |
http://en.wikipedia.org/wiki/Bullet-point_engineering
|
|
348 |
|
|
349 |
* KISS
|
|
350 |
|
|
351 |
Keep it simple and stupid, or keep it simple, stupid!
|
|
352 |
|
|
353 |
Instruction creep and function creep, two instances of creeping featuritis,
|
|
354 |
are examples of failure to follow the KISS principle in software development.
|
|
355 |
|
|
356 |
http://en.wikipedia.org/wiki/KISS_principle
|
|
357 |
|
|
358 |
* Minimalism.
|
|
359 |
|
|
360 |
In computing, minimalism refers to the application of minimalist philosophies
|
|
361 |
and principles in hardware and software design and usage.
|
|
362 |
|
|
363 |
http://en.wikipedia.org/wiki/Minimalism_%28computing%29
|
|
364 |
|
|
365 |
* Unix philosophy.
|
|
366 |
|
|
367 |
** From Doug McIlroy.
|
|
368 |
|
|
369 |
"Do one thing and do it well."
|
|
370 |
|
|
371 |
"Write programs that do one thing and do it well. Write programs to work
|
|
372 |
together. Write programs to handle text streams, because that is a universal
|
|
373 |
interface."
|
|
374 |
|
|
375 |
** From Pike: Notes on Programming in C.
|
|
376 |
|
|
377 |
1. You cannot tell where a program is going to spend its time. Bottlenecks
|
|
378 |
occur in surprising places, so do not try to second guess and put in a speed
|
|
379 |
hack until you've proven that's where the bottleneck is.
|
|
380 |
2. Measure. Do not tune for speed until your performance analysis tool tells
|
|
381 |
you which part of the code overwhelms the rest.
|
|
382 |
3. Fancy algorithms tend to run more slowly on small data sets than simple
|
|
383 |
algorithms. They tend to have a large constant factor in O(n) analysis, and n
|
|
384 |
is usually small. So don't get fancy unless Rule 2 indicates that n is big
|
|
385 |
enough.
|
|
386 |
4. Simplify your algorithms and data structures wherever it makes sense
|
|
387 |
because fancy algorithms are more difficult to implement without defects. The
|
|
388 |
data structures in most programs can be built from array lists, linked lists,
|
|
389 |
hash tables, and binary trees.
|
|
390 |
5. Data dominates. If you have chosen the right data structures and organized
|
|
391 |
things well, the algorithms will almost always be self-evident. Data
|
|
392 |
structures, not algorithms, are central to programming.
|
|
393 |
|
|
394 |
** From Mike Gancarz: The UNIX Philosophy.
|
|
395 |
|
|
396 |
1. Small is beautiful.
|
|
397 |
2. Make each program do one thing well.
|
|
398 |
3. Build a prototype as soon as possible.
|
|
399 |
4. Choose portability over efficiency.
|
|
400 |
5. Store data in flat text files.
|
|
401 |
6. Use software leverage to your advantage.
|
|
402 |
7. Use shell scripts to increase leverage and portability.
|
|
403 |
8. Avoid captive user interfaces.
|
|
404 |
9. Make every program a filter.
|
|
405 |
|
|
406 |
With this not all agree:
|
|
407 |
|
|
408 |
1. Allow the user to tailor the environment.
|
|
409 |
2. Make operating system kernels small and lightweight.
|
|
410 |
3. Use lowercase and keep it short.
|
|
411 |
4. Save trees.
|
|
412 |
5. Silence is golden.
|
|
413 |
6. Think parallel.
|
|
414 |
7. The sum of the parts is greater than the whole.
|
|
415 |
8. Look for the 90-percent solution.
|
|
416 |
9. Worse is better.
|
|
417 |
10. Think hierarchically.
|
|
418 |
|
|
419 |
** Misc.
|
|
420 |
|
|
421 |
"Unix is simple. It just takes a genius to understand its simplicity."
|
|
422 |
-– Dennis Ritchie
|
|
423 |
"Unix never says 'please'."
|
|
424 |
-– Rob Pike
|
|
425 |
|
|
426 |
http://en.wikipedia.org/wiki/Unix_philosophy
|
|
427 |
|
|
428 |
* Worse is better.
|
|
429 |
|
|
430 |
In the "Worse is better" design style, simplicity of both the interface and
|
|
431 |
the implementation is more important than any other attribute of the system —
|
|
432 |
including correctness, consistency and completeness.
|
|
433 |
|
|
434 |
Simplicity
|
|
435 |
The design must be simple, both in implementation and interface. It is
|
|
436 |
more important for the implementation to be simpler than the interface.
|
|
437 |
Simplicity is the most important consideration in a design.
|
|
438 |
Correctness
|
|
439 |
The design must be correct in all observable aspects. It is slightly better
|
|
440 |
to be simple than correct.
|
|
441 |
Consistency
|
|
442 |
The design must not be overly inconsistent. Consistency can be sacrificed
|
|
443 |
for simplicity in some cases, but it is better to drop those parts of the
|
|
444 |
design that deal with less common circumstances than to introduce either
|
|
445 |
implementational complexity or inconsistency.
|
|
446 |
Completeness
|
|
447 |
The design must cover as many important situations as is practical. All
|
|
448 |
reasonably expected cases should be covered. Completeness can be sacrificed
|
|
449 |
in favor of any other quality. In fact, completeness must be sacrificed
|
|
450 |
whenever implementation simplicity is jeopardized. Consistency can be
|
|
451 |
sacrificed to achieve completeness if simplicity is retained; especially
|
|
452 |
worthless is consistency of interface.
|
|
453 |
|
|
454 |
http://dreamsongs.com/WIB.html
|
|
455 |
Lisp: Good News, Bad News, How to Win Big
|
|
456 |
|
|
457 |
* The right thing.
|
|
458 |
|
|
459 |
The MIT approach (known as "The right thing"):
|
|
460 |
|
|
461 |
Simplicity
|
|
462 |
The design must be simple, both in implementation and interface. It is
|
|
463 |
more important for the interface to be simpler than the implementation.
|
|
464 |
Correctness
|
|
465 |
The design must be correct in all observable aspects. Incorrectness is
|
|
466 |
simply not allowed.
|
|
467 |
Consistency
|
|
468 |
The design must be consistent. A design is allowed to be slightly less
|
|
469 |
simple and less complete to avoid inconsistency. Consistency is as important
|
|
470 |
as correctness.
|
|
471 |
Completeness
|
|
472 |
The design must cover as many important situations as is practical. All
|
|
473 |
reasonably expected cases must be covered. Simplicity is not allowed to
|
|
474 |
overly reduce completeness.
|
|
475 |
|
|
476 |
http://dreamsongs.com/WIB.html
|
|
477 |
Lisp: Good News, Bad News, How to Win Big
|
|
478 |
|
|
479 |
* YAGNI.
|
|
480 |
|
|
481 |
"You aren't gonna need it" (or YAGNI for short) is the principle in extreme
|
|
482 |
programming that programmers should not add functionality until it is
|
|
483 |
necessary.
|
|
484 |
|
|
485 |
http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it
|
|
486 |
|
|
487 |
* DRY (DIE).
|
|
488 |
|
|
489 |
Don't Repeat Yourself (DRY) or Duplication is Evil (DIE).
|
|
490 |
|
|
491 |
* VCS allow multiple and diverging copies ("branches").
|
|
492 |
* Source code generation.
|
|
493 |
|
|
494 |
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
|
|
495 |
|
|
496 |
* Do it yourself (DIY).
|
|
497 |
|
|
498 |
Do it yourself (or DIY) is a term used to describe building, modifying, or
|
|
499 |
repairing of something without the aid of experts or professionals.
|
|
500 |
|
|
501 |
when tasklist longer then people life mutch easy use already written libraries
|
|
502 |
then wrote own.
|
|
503 |
|
|
504 |
http://en.wikipedia.org/wiki/Do_it_yourself
|
|
505 |
|
|
506 |
* Once and Only Once (OAOO).
|
|
507 |
|
|
508 |
|
|
509 |
|
|
510 |
* MoSCoW Method.
|
|
511 |
|
|
512 |
The capital letters in MoSCoW stand for:
|
|
513 |
|
|
514 |
* M - MUST have this (included in the current delivery timebox in order
|
|
515 |
for it to be a success).
|
|
516 |
* S - SHOULD have this if at all possible (critical to the success of the
|
|
517 |
project, but are not necessary for delivery in the current delivery
|
|
518 |
timebox).
|
|
519 |
* C - COULD have this if it does not affect anything else (nice to have).
|
|
520 |
* W - WON'T have this time but WOULD like in the future.
|
|
521 |
|
|
522 |
http://en.wikipedia.org/wiki/MoSCoW_Method
|
|
523 |
|
|
524 |
* Abandonware.
|
|
525 |
|
|
526 |
Abandonware is a term used to describe computer software that is no longer
|
|
527 |
sold or supported, or whose copyright ownership may be unclear for various
|
|
528 |
reasons. While the term has been applied largely to older games, utility
|
|
529 |
software, etc.
|
|
530 |
|
|
531 |
http://en.wikipedia.org/wiki/Abandonware
|
|
532 |
|
|
533 |
* Separation of concerns.
|
|
534 |
|
|
535 |
In computer science, separation of concerns (SoC) is the process of separating
|
|
536 |
a computer program into distinct features that overlap in functionality as
|
|
537 |
little as possible. A concern is any piece of interest or focus in a program.
|
|
538 |
Typically, concerns are synonymous with features or behaviors. Progress
|
|
539 |
towards SoC is traditionally achieved through modularity of programming and
|
|
540 |
encapsulation (or "transparency" of operation), with the help of information
|
|
541 |
hiding. Layered designs in information systems are also often based on
|
|
542 |
separation of concerns (e.g., presentation layer, business logic layer, data
|
|
543 |
access layer, database layer).
|
|
544 |
|
|
545 |
HyperText Markup Language (HTML) and cascading style sheets (CSS) are
|
|
546 |
languages intended to separate style from content.
|
|
547 |
|
|
548 |
http://en.wikipedia.org/wiki/Separation_of_concerns
|
|
549 |
|
|
550 |
* Modular design.
|
|
551 |
|
|
552 |
In systems engineering, modular design — or "modularity in design" — is an
|
|
553 |
approach that subdivides a system into smaller parts (modules) that can be
|
|
554 |
independently created and then used in different systems to drive multiple
|
|
555 |
functionalities.
|
|
556 |
|
|
557 |
http://en.wikipedia.org/wiki/Modular_design
|
|
558 |
|
|
559 |
* Occam's razor.
|
|
560 |
|
|
561 |
"entia non sunt multiplicanda praeter necessitatem"
|
|
562 |
|
|
563 |
Entities must not be multiplied beyond necessity.
|
|
564 |
|
|
565 |
* Code and fix.
|
|
566 |
|
|
567 |
Programmers immediately begin producing code. Bugs must be fixed before the
|
|
568 |
product can be shipped.
|
|
569 |
|
|
570 |
http://en.wikipedia.org/wiki/Code_and_fix
|
|
571 |
|
|
572 |
* Cowboy coding.
|
|
573 |
|
|
574 |
Cowboy coding is a term used to describe software development where the
|
|
575 |
developers have autonomy over the development process. This includes control
|
|
576 |
of the project's schedule, algorithms, tools, and coding style.
|
|
577 |
|
|
578 |
A cowboy coder can be a lone developer or part of a group of developers with
|
|
579 |
either no external management or management that controls only non-development
|
|
580 |
aspects of the project, such as its nature, scope, and feature set (the
|
|
581 |
"what", but not the "how").
|
|
582 |
|
|
583 |
http://en.wikipedia.org/wiki/Cowboy_coding
|
|
584 |
|
|
585 |
* Extreme Programming.
|
|
586 |
|
|
587 |
http://en.wikipedia.org/wiki/Extreme_Programming
|
|
588 |
|
|
589 |
* Hollywood Principle.
|
|
590 |
|
|
591 |
In computer programming, the Hollywood Principle is stated as "don't call us,
|
|
592 |
we'll call you." It has applications in software engineering; see also
|
|
593 |
implicit invocation for a related architectural principle.
|
|
594 |
|
|
595 |
http://en.wikipedia.org/wiki/Hollywood_Principle
|
|
596 |
|
|
597 |
* Inversion of control.
|
|
598 |
|
|
599 |
Inversion of control, or IoC, is an abstract principle describing an aspect of
|
|
600 |
some software architecture designs in which the flow of control of a system is
|
|
601 |
inverted in comparison to procedural programming.
|
|
602 |
|
|
603 |
http://en.wikipedia.org/wiki/Inversion_of_control
|
|
604 |
|
|
605 |
* Literate programming.
|
|
606 |
|
|
607 |
http://en.wikipedia.org/wiki/Literate_Programming
|
|
608 |
|
|
609 |
* Model-driven architecture.
|
|
610 |
|
|
611 |
http://en.wikipedia.org/wiki/Model-driven_architecture
|
|
612 |
|
|
613 |
* Quick-and-dirty.
|
|
614 |
|
|
615 |
Quick-and-dirty is a term used in reference to anything that is an easy way to
|
|
616 |
implement a workaround or "kludge." Its usage is popular among programmers,
|
|
617 |
who use it to describe a crude solution or programming implementation that is
|
|
618 |
imperfect, inelegant, or otherwise inadequate, but which solves or masks the
|
|
619 |
problem at hand, and is generally faster and easier to put in place than a
|
|
620 |
proper solution.
|
|
621 |
|
|
622 |
http://en.wikipedia.org/wiki/Quick-and-dirty
|
|
623 |
|
|
624 |
* Release early, release often.
|
|
625 |
|
|
626 |
Release early, release often (sometimes abbreviated RERO) is a software
|
|
627 |
development philosophy that emphasizes the importance of early and frequent
|
|
628 |
releases in creating a tight feedback loop between developers and testers or
|
|
629 |
users.
|
|
630 |
|
|
631 |
http://en.wikipedia.org/wiki/Release_early,_release_often
|
|
632 |
|
|
633 |
* Test-driven development.
|
|
634 |
|
|
635 |
Test-driven development (TDD) is a software development technique that relies
|
|
636 |
on the repetition of a very short development cycle: First the developer
|
|
637 |
writes a failing automated test case that defines a desired improvement or new
|
|
638 |
function, then produces code to pass that test and finally refactors the new
|
|
639 |
code to acceptable standards.
|
|
640 |
|
|
641 |
http://en.wikipedia.org/wiki/Test-driven_development
|
|
642 |
|
|
643 |
* Unified Process.
|
|
644 |
|
|
645 |
The Unified Software Development Process or Unified Process is a popular
|
|
646 |
iterative and incremental software development process framework. The
|
|
647 |
best-known and extensively documented refinement of the Unified Process is the
|
|
648 |
Rational Unified Process (RUP).
|
|
649 |
|
|
650 |
http://en.wikipedia.org/wiki/Unified_Process
|
|
651 |
|
|
652 |
* Waterfall model.
|
|
653 |
|
|
654 |
1. Requirements specification
|
|
655 |
2. Design
|
|
656 |
3. Construction (AKA implementation or coding)
|
|
657 |
4. Integration
|
|
658 |
5. Testing and debugging (AKA Validation)
|
|
659 |
6. Installation
|
|
660 |
7. Maintenance
|
|
661 |
|
|
662 |
http://en.wikipedia.org/wiki/Waterfall_model
|
|
663 |
|
|
664 |
* Do it yourself.
|