Re: [xml-dev] How to design XML to have broad utility and yet alsoenable

[Ihe Onwuka <ihe.onwuka@gmail.com>]

On Thu, Nov 21, 2013 at 2:18 AM, Rick Jelliffe <rjelliffe@allette.com.au> wrote:
> Knuth was wrong about avoiding premature optimization. Because there is now
> a generation of coders who take him to mean that you should initially ignore
> performance or implementation heuristics or real-time aspects and
> concentrate on correctness. The result is systems that fall over in
> certification or integration testing.
>

But I don't read that as Knuth being wrong. They haven't completed the
job. It is sound engineering to concentrate on correctness at the
outset. If you concentrated on say memoising from the outset you could
lose yourself. Get it working and then review for possible
optimisations.

Write it out in longhand get it right then see where you can
procedurally abstract. Code review is another stage where such
efficiencies could be pointed out (maybe a library function you didn't
know about is available).

Don't want to say refactor because that has been colonised to have
narrow meaning but that is the spirit of a better approach than trying
to nail it from scratch.

> In fact, team leaders need to be constantly vigilant that their developers
> dont suddenly stick in code of such inefficiency that it compromises the
> project: in Xml systems, the one i see most is where the developer cannot
> figure out how the stream api works,  so they save the document out to the
> file system (potentially getting encoding wrong then) because thst is
> easier. This is nothing to do with correctness: they are choosing an
> inefficient and error-prone method over one that may be less obvious but
> safer and nonwrecking. The coder thinks they are avoiding premature
> optimization, but they are just being lazy.
>
> Indeed, many projects run late: the time where optimisation should have been
> done never occurs.
>

As you say thats nothing to do with correctness. Thats just incompetence.