In a message of Sun, 18 Sep 2005 16:45:21 PDT, "Kirby Urner" writes:
>Perhaps my version of Python is evolving at a faster rate, and in differe
>nt
>directions, than you necessarily need in your version, for what you're
>trying to do. What's the harm in that, as long as your code still runs?
>
>Kirby
There is enormous potential harm in this. The problem is that
programming is not an individual activity. When new features make
code harder to read, or harder to understand, then readers are
penalised at the expense of writers. When bugs are easier to make,
or harder to detect when reading code, then everybody suffers.
This is terrible for the productivity of a company. Once your company
is beyond a certain size -- the exact number is subject to debate, and
it varies depending on what language you use -- and once your codebase
is beyond a certain size, you will find that you spend far, far, far
more time _reading_ code than _writing_ it. The more senior you are,
the worse this is, and managers often end up writing little or no code
at all.
This means that any productivity gains you get when you add {feature}
which makes it easier to write code X has to be weighed against the
productivity losses when you have to read {feature}. Since readers
outnumber writers, there comes a point where no feature should be
added that produces less-readable code, on the grounds of productivity
gains to the code-writers alone. Remember, the productivity of a
company is not driven by the speed at which your coders can write
new code. Instead it is the speed at which they can understand the
codebase, and the ease in which they can make modifications to it, and
how bug-free those modifications are that matter. So if your new
feature makes the code harder to read, it had better make certain
bugs harder to make, or certain modifications easier to make in a
bug free way, or have some other benefit.
Some languages have developed the way they have precisely because
they have persued some other benefit to the exclusion of all else.
C++ sacrifices readability for speed. This was a fine trade for
those people who absolutely must have the speed. But as CPUs
got faster, people found their companies were more productive
using something else.
If you have worked commercially, then you will already be familiar
with this situation. 'I don't have time to understand this code, I
will just rewrite it instead'. This happens all the time. Writing is
easy. Understanding is hard. But every time this happens, there is
an indication that something is seriously wrong in your company.
The fact that it is wrong in everybody else's company too is no
excuse, just a sad commentary on the state of the art.
Was the original code too poorly written? poorly documented? Is the
new programmer too lazy to read the code? Too unskilled at reading
code? Is the old code obscure but really damn excellent at something
important, and the new version inferior? Will it cause subtle bugs?
What about the reabability of the new version? Next week will
somebody come along, not understand _it_ either, and reinvent the
wheel a third time?
Sometimes the problem is with the language itself. Take Perl.
I never bother, any more, trying to deeply understand what any
Perl script I find is doing. I just rewrite it in Python. I will
never have any confidence in my ability to 'understand' what an
arbitrary Perl script does. I've been wrong too often.
One of the sad things about life as a commercial programmer is that
often only the most junior programmers get to write code all day.
This is because somebody else has come and given them the specs and
told them what to write. Everybody else has to figure out what to
write and where to write it, which requires being familiar with the
code base, which requires reading it regularly, which takes time.
This means that the coolest in new features, those meant to be used
_sparingly_ fall directly into the hands of those who do not have the
maturity and experience to know when not to use them. With predictable
results. :-)
This means come code review time, you have to waste a whole bunch of
time explaining to your junior people why they need to rewrite their
code to not use this feature. This makes code review a lot more
painful and acrimonious than it was. And it is difficult on the
reviewer. What do you say when you are only 65% convinced that this
is a poor use of {feature}? Especially when what you want to say
amounts to 'my XX years of experience in the field say that this is
too cutesy?' Your junior programmers may only conclude from this that
you are an senile old fart. You may conclude that they lack the
wisdom that God gave green apples. Age-based splits in your company
are among the hardest things to combat and sap morale and team building.
Pair programming will not work unless there is mutual respect.
In general, the greater the difference between 'your best people'
and 'your worst people' the harder productivity suffers. If the
language is hard to use, you may find out that only your top people
provide positive value to the company. Your worst people subtract
value. Not only do the things they write have to be rewritten, but
everybody wastes time on bugs they caused, and talking to them with
their problems and so on and so forth. I once managed a project
that was late, and the only way we found to fix it was to take the
6 worst people on the team and send them to the other side of the
country to take 3 weeks of training in some damn thing that wasn't
even relevant to what our company did -- I forget what. Then
everybody else got the job done. But those 6 people didn't learn
much about how to be productive. What they really needed was
training in UI design and how to use C++ without screwing up so much.
But Andrew Koenig hadn't written _C++ Traps and Pitfalls_ yet,
http://www.accu.org/bookreviews/public/reviews/c/c002114.htm
so we couldn't give them a course based on it. And so it goes.
Some languages have grown so much that only experts can be
productive with it.
What's more, even after you have your own company in shape, with nobody
abusing the new features any more, you still have to interface with
code written by people who do not work for your company. And they may
not have as strict a set of standards as you do. If the innappropriate
use of a new feature makes for buggy code, then you may be forced to
not use some package that over-uses the feature despite its attractiveness
in other ways. And you have absolutely no control over these people.
Even deciding whether to use somebody else's code requires reading it.
If the code is hard to read, you may find that you do not have the
time. Obscure language features can make 'spot the poorly written
code' game a lot harder. What you need is a way to quickly tell if
the code you are reading is good or not. For my own peace of mind, I
have decided that 'anybody who over-uses language feature X as much as
those guys do is statistically unlikely to be up to anything good' - but
I know as well as anybody that 'statistically unlikely' is not the
same thing as 'never'. What opportunities are being missed?
It is the tragedy of the commons all over again. Code-writers have
the interest and motivation to add every feature they dream up into
the languages they create, in the same way that sheep-owners have
the interest and motivation to overgraze the commons.
Laura
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
