This puts me in mind of the following extract from "Code Complete" by Steve McConnell in 1993."...people who refuse to write comments (1) think their code is clearer than it could possibly be; (2) think that other programmers are far more interested in their code than they really are; (3) think other programmers are smarter than they really...

There's no significant difference in the two versions of both examples - in their current form - however, there may be some implications when you modify the code in the future.1) In the first example b is initialized when the class is instantiated. In the second example it is not initialised until method A has been called called. This may have...

"If we write 10 programs a day instead of one program every 10 days, we just get that much more experience."This is a curious statement. Are we basically talking about processes that relate to problems of such simplicity that programs can be turned out at the rate of 10 per day?Maybe I'm slow (OK I admit I am, compared to some) but I can't...

This sound appropriate, given that Python size has been in the news recently...see http://news.bbc.co.uk/1/hi/world/asia-pacific/3354403.stm

> The important part, as Ward emphasized, is that you have> to be clear early on what is fundamental (i.e. static) and> what should be left sketchy or omitted (dynamic).In other words, you're saying... 1) You cannot get away from doing design up front and predicting what changes are permitted and what aren't. 2) There are limitations on what...

> Not only can a change made later in a project be the same> price as one made early – if the product is well-designed,> it can be cheaper.I can't see any reason why this should be true. From the day the first requirement is agreed, requirements are added and changed (usually added). The code-base inevitably increases in size and complexity as...

> "If we made a change during week one, and it took us two days to understand what was really required, it took two days to make the change. If we made a change during week 21, and it took us two days to understand what was really required, it took us two days to make the change."This is a disappointingly disingenuous statement. It says that a...

> Maybe not supplant, unless you count Linux's emergence in> the server market as an alternative.No. "Emergence as an alternative" does not count as supplanting.Curiously, my dictionary (Concise Oxford English) includes the following in the definition of supplant:"Dispossess and take the place of (a person), esp. by treacherous or underhand...

The point I'm making is not related to the dull and tendentious arguments about the relative merits of Linux and Windows. I'm simply pointing out that Linux has not supplanted Windows and therefore is not an example of how an open standard supplants a propietary one.

> If an idea can be> published in a relatively raw form, it will be knocked> about and changed and may morph over time into something> very good indeed. Linux is the poster child for this> approach.Is it? Doesn't Linux have have a desktop share of under 1% compared with Microsoft's over 95%. For all its morphing, it has yet to morph into an...

> Please take this next metaphor in the pragmatic spirit is> is given; not as a glorification of XP.> > > > The solution, of course, is not to get rid of lightbulbs.> The solution is to invest in screens. It's not a perfect> solution, but we live with it because we like having the> lights on.I tried but I despair. The trouble with dodgy...

Ward,In what way does the requirement that all developers have a working knowledge of the complete code-base act as a constraint on the size or complexity of said code-base?Vince.

When I release application versions (primarily front end stuff) I apply the following version numbering rules:Major: Increment if a massive change has happened to the UI. e.g Numerous UI changes that imply a significant change in the way application is (or can be) used. Reset minor and build numbers to zero.Minor: Increment if UI has changed...

> It is deeper than that. When you TDD you end up with> incredibly decoupled designs. It is one thing to talk> about decoupling when you design, yet another to end up> with one. If you want to see whether a non-TDDed design> is decoupled try to write a test for an arbitrary class.> It is usually harder than you might imagine.> > When you can...

Oh please! What is it about Extreme Programming that engenders so much of this nonsense from so many of its adherents. I think it does more damage to the acceptance of XP than any else I can think of.> All gospel begins as heresy, and once again, RCM is> spot-on.Classifying all opinions on software development as either extremes of 'gospel' or...