2 Jan
2013
2 Jan
'13
1:54 a.m.
Op 1-1-2013 20:32, Alexander Schreiber schreef:
On Sun, Dec 30, 2012 at 06:18:19PM -0800, steve
wrote:
Not-reusable code does not imply badly maintainable code. You could
write high quality code to solve a problem in the shortest possible way
(both in code-writing time and execution time) or you could write a more
generic approach that could also be used to solve a similar problem. I
think the former is an example of what Steve ment.
I had a guy working for me who spent several days on adding a database
to a program to make everything in the program configurable. Most of the
configuration items would have done fine as a program constant IMO. The
others could have easily be set by commandline parameters.
IMO this is an example of overkill and I would fully understand it if
the customer was unhappy with the amount of "improvement" gained for the
costs involved.
Regards,
Bert
Engineers get paid by generating code that works
within the performance
capabilites of the system it's implemented on, not how it looks. Reuseable
code is about 3x the cost of a point design, your customer wants to pay for
that? No way. You want nice readable code, change the incentives.
If you write release-once-then-run-away code, this may hold true. But a lot
of code is written for systems that are maintained for more that one release.
Having throw-away code in such a system will increase the risk of errors
and the cost of maintenance quite a bit. Which is why people being serious
about code quality usually have code commits gated by code reviews.