quote:Abstract Programmers are often scared that they won't be able to optimize later. For that reason, they tend to optimize early leading to brittle design. Test driven design can lead to emergent optimization and code that is readily optimizable. If programmers develop test first, many of their upfront concerns about performance can be deferred.

edit: see also Yet Another Optimization Article Discuss [edited by - petewood on March 19, 2004 11:18:57 AM]

okay, daerid, I''m sitting at work on a Friday afternoon wasting time, not trying to get someone to write an essay for me.

So, on topic, most of the time there are a lot of questions on these boards from newbies making micro-optimisations when they are a long way from finishing their code.

It would seem to be a good idea to encourage them to see the bigger picture, to develop flexible code, to let go of the fear that every decision they make will have enormous impact on their design. etc.

Test driven development seems to offer the security needed to make large changes to your design without messing things up. This can lead to flexible designs which are well compartmentalised with a fine granularity. Optimisation often needs to happen at a higher level first, i.e. you cut down the number of times a function is called rather than optimising the function itself.

If your design is tied up with particular data structures it can be difficult to be flexible.

For example, this is why I would recommend using the STL algorithms with iterators and designing your own functions to similarly use iterators. Then if your data structure (container) changes it will still work. Also if you want to code your own container if you make it conform to the STL design you will be able to fit right in.

These design principles don''t seem to get talked about with the younger folks. I was wondering how we could encourage it.

Thanks. Pete

Actually writing tests is quite fun and it documents the intended behaviour in a quite nice way. However writing tests becomes more and more difficult the higher one gets in the code-hierarchy.

The problem with newbies is that it takes time to learn how to see the bigger picture of a program and therefor they focus on smaller parts.

Good programming practise and design skills takes a long time to learn. A person must experience a certain situation before (s)he can adopt a certain way of thinking.
For instance, I had a hard time understanding the usefulness of design patterns before I met a situation where one (design pattern) actually solved a problem for me.

It''s the same with XP (and no, not Windows). XP is design patterns in how to program. It''s a set of tested (and verified) methods of what is a good practise when writing (small to medium scale) software. It takes time for people to adopt these ways because as a beginner they don''t feel a need for them. I know I didn''t.

To be honest I don''t see the correlation between test driven design and readily optimisable code. But then I haven''t read those articles.

Test driven development doesn''t work for me. It seems to revolve around the idea of low-level testing of independent components, but if you''re not developing low level components, then it becomes largely impossible. As Amag rightly pointed out, the higher up in the code you go, the harder it becomes, because you''re typically writing code that involves many objects, none of which make any sense out of context.

I''ve often found that "the freedom to make big changes without breaking anything" is overstated. I''ve often made big changes and not broken anything that didn''t take just a few minutes to fix. I think the XP theory is to ''refactor often'' anyway, which implies lots of small changes, which in turn makes it even harder to really break something.

I do agree that premature optimisation is a problem and that many people here fall prey to it. To a degree it''s understandable. Most people start off being builders before they become architects and it''s natural to worry about individual bricks when you''ve never constructed an entire building before.

Many of the other points, about algorithms and data structures, I can see being an issue in C++ but not in higher level languages like Python. Maybe that is why I''ve found test-driven development to be underwhelming.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]