# HG changeset patch
# User meillo@marmaro.de
# Date 1234131495 -3600
# Node ID a3d9a63defa7d5018fa0a5c38fd1be16476aaae9
# Parent  f0fa40e30dfbdaacb5d073b08eb8aeb765cc79b3
trivial change

diff -r f0fa40e30dfb -r a3d9a63defa7 thesis/tex/4-MasqmailsFuture.tex
--- a/thesis/tex/4-MasqmailsFuture.tex	Sun Feb 08 23:15:35 2009 +0100
+++ b/thesis/tex/4-MasqmailsFuture.tex	Sun Feb 08 23:18:15 2009 +0100
@@ -796,7 +796,7 @@
 In the short-time view, the effort for improving the existing code is much smaller than the effort for a new design plus improvements. But to have similar quality properties at the end of the short-time frame, a version that is based on current code will probably require nearly as much effort as a new designed version will take. For all further development afterwards, the new design will scale well while the old code will require exponential more work.
 \index{existing code}
 
-The Break Even is the point in time when a new design is better than improvements of the old code for the first time. From this point on, the new design will be the better solution.
+Break Even is the point in time when a new design is better than improvements of the old code for the first time. From this point on, the new design will be the better solution.
 
 In the long-time view, a restructuring for modularity is necessary anyway to keep the maintaining effort bearable. The question is, when the restructuring should be done: Right at the start in a new design, or later as restructuring work.