Slashdot Mirror

I think you are mistaking possibilities with realities

You're right, but there are for example lots and lots of eyeballs on the Linux kernel source. Also, at least FOSS has this possibility (and while not always being reality, it is sometimes).

Yes there can be profit in FOSS, but its not usually from the software itself (by definition "free" as in usually both "free beer" and "freedom"). Profit for companies dealing with FOSS is usually from selling boxed versions of the software, documentation or support contracts. The "features on demand" that you mentioned, if sold for profit, aren't really FOSS are they (even if the underlying application is FOSS).

Hacking has evolved beyond the original "tinkering" definition of yesteryear. It's now associated with unauthorized access.

From http://www.extremeprogramming.org/ "instead of delivering everything you could possibly want on some date far in the future [extreme programming] delivers the software you need as you need it". "Hacking something together and pushing it into production" might not adhere to all the rules of extreme programming, but I think it fits the extreme programming model well enough, particularly for in-house development where the customer and the developer both work within the same company.

As such is the opposite to engineering, which is about insure the results.

As long as any software produces the correct result, how it achieves it is usually of secondary importance. Many people with CS degrees focus too much on the "how".

One thing you quickly discover when you have to support hundreds of applications running on thousands of desktops is that Java applications are a system administrator's nightmare.

This is less true when dealing with server-side Java - if it's running on a server, and it behaves like a typical Java program, you can just give it ten or a hundred times the hardware resources you'd use for a compiled C program doing the same job. Hardware's cheap, so this strategy can be supportable.

On the desktop, however, it's nearly impossible to find six real-world Java applications (real-world means not academic software, but actual applications that perform functions having commercial value) that can run simultaneously with anything approaching acceptable performance. Usually such apps will require different, mutually incompatible versions of Java at any given time, which doesn't help this situation.

I don't think this necessarily means Java is a bad language (although it seems that most implementations of Java are bad enough that they need to be patched constantly). It may be that it's just Java programmers that suck - certainly the majority of Java programmers are incapable of accepting any criticism of their chosen faith, and will froth at the mouth when they read this post. Intransigent refusal to accept reality does not a good programmer make; you can't improve something until you recognize that it is imperfect, and Java programmers generally talk about their programming language as if it were divinely inspired and ordained.

âoeA simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work next. If you find something that is complex replace it with something simple. It's always faster and cheaper to replace complex code now, before you waste a lot more time on it.â â" from http://www.extremeprogramming.org/rules/simple.html

Compare any Java-based solution with another piece of software, written in C at roughly the same time, that solves the same problems. The Java solution is invariably slower, requires more resources, and has more extremely odd and difficult-to-isolate bugs. Anything written in Java can be rewritten in C to create a faster, more robust, more sustainable piece of software. Of course, this can also be said of C++, and as previously noted, this may simply be because C programmers are better coders than Java programmers. I dunno. Perl and Python do not have this problem, or at least not to the degree that Java does.

Re: "Why does an open-source project have a deadline??" ...because paying customers expect things in a timely manner (its actually required by law - you can't just accept payment based on an open-ended promise to deliver). Gnome is a product. Your open source project most likely isn't in the same league as Gnome. Re: "rather then hack something up that "works now", but needs to be re-written later". You haven't developed software in a commercial environment have you? Customer requirements ALWAYS change, so you ALWAYS have to re-write stuff. That's why the concept of "extreme programming" (http://en.wikipedia.org/wiki/Extreme_Programming or http://www.extremeprogramming.org/) came about, which I use in my own work. You can spend all your budget planning the perfect product before you realise there is no such thing. Paying customers want results, and are quite happy to pay money for something that isn't perfect but does the job, and they will keep paying money to improve it gradually. If you ask for top dollar to build the perfect software, not only are you setting yourself up for failure, but when you can't deliver after spending your client's investment, you will deliver a half-baked perfect product which is likely to be riddled with bugs and will have to be rewritten anyway because it meets very few of the proposed "perfect software" objectives. Gnome is an evolving product, and given the huge demand for (and already existing user base of) smartphones running Android, it makes sense to me that they would put more effort into targeting that market. Who really cares what a bunch of slashdot whingers want? After all. those who want a better Gnome3 are welcome to fork it themselves.

1. Blog your progress. Whatever you did today, blog it. Let people know what you did that worked, or what was faster (Nginx vs. Apache), or what wasn't (ColdFusion?). Don't reinvent the wheel, use WordPress, regardless of whether you like PHP/MySQL or not.

2. Use a subscription/payment management company. You're just a small group of nerds, not accounts receivable clerks. Fastspring, Plimus are free; Chargify, Subsify, Cheddar Getter, BrainTree, Spreedly charge; and Zuora is expensive.

3. Use Google Docs and Slideshare to share documents.

4. Chat. Don't just rely on email. Emails can often read like "this way or the highway". Be collaborative. You can often accomplish more with 15-30min collaboratively as opposed to composing and responding to long emails. Skype, Jabber, SIP

5. Take notes on what you did. Made a server configuration or a setting change in your CMS, your compiler, or whatever? Copy and paste from xterm so you don't have to guess about those commandline switches next time. Take screenshots and make them available to others. Zim, Projly, DokuWiki.

6. Have a phone numbers. If not bog-standard landline phones, take advantage of Google Voice and SkypeOut and SkypeIn (people can call your Skype line on a normal phone number). I realize Google Voice might not be available in South Africa yet.

7. Someone mentioned version control. Use git if you're a cool kid. Or svn if you're old and busted. Read the RedBean book. I've had success in having non-tech colleagues using graphical clients like TortoiseSVN (integrates into Windows Explorer).

8. Write tests. Any member of your team, sitting anyplace, should be able to push a button and run all your tests. Tests document how you're supposed to use a given method, class, etc., especially valuable when you're so far flung. Use JUnit, PHPUnit, FooUnit for your language. Write the tests before you develop, and you're doing Test Driven Development.

9. If you're writing tests, that implies loose coupling, which might require dependency injection. Can be difficult to climb that mountain, but it's worth it when you can just run a test and be sure your project works.

10. Development processes: Scrum, Extreme Programming. UML lets you communicate graphically about objects.

Indeed.

"Working overtime sucks the spirit and motivation out of your team. When your team becomes tired and demoralized they will get less work done, not more, no matter how many hours are worked. Becoming over worked today steals development progress from the future."
Quoted from: http://www.extremeprogramming.org/rules/overtime.html

If your boss wants you to work 10-11 hours a day, he probably would get more done by asking you to work 6-7 hours a day instead, and canceling all non-stand-up meetings for the foreseeable future.

Think extreme programming and agile programming for programming constructs used in small to medium groups:

• http://www.extremeprogramming.org/
• http://en.wikipedia.org/wiki/Agile_software_development

Of course, there's also different types of development models, such as object-oriented, aspect-oriented, et al. ad nauseum. Find a comfortable programming environment for your skill level (expression engine might be a good fit if you're a designer by nature), and keep it simple. Stay away from complicated constructs.

Also, read Joel on Software:

• http://www.joelonsoftware.com/
• http://www.joelonsoftware.com/BuytheBooks.html

Get the book, he's a good, entertaining writer.

Good point.

We'd go with: http://extremeprogramming.org/ (or the like)

I'm sure that was from the marketing dept, just like how you pointed out everything is now lo carb/no trans fat and my personal favorite Xtreme.

i need an Xtreme computer. i do lots of Xtreme programming so i need plenty of computing power when getting wicked air. perhaps you have seen my work in the latest mountain dew commercial?

We've found that writing User Stories together with the 'client' is the only sensible way to gather requirements. Make sure you develop in short iterations, that way people can change their mind about the software and you don't loose a lot of time.

How can you do group development without source control? Do you have bug tracking? Automated builds? A deployment policy / methodology / sign-off (or just someone who is responsible for it)?

It sounds like you've got a group of undisciplined cowboys. Good like imposing structure on them.

Source control, and comments are absolutely required. The only reason not to do them is due to personalities, and if you have that problem, you don't have good devs.

Where is the team lead / project manager in all this? Start there. This is a leadership problem that is causing business problems (bad releases, poor quality control, poor communication, no reuse, no reproducibility, no records).

Look into sucking down some things from XP. Daily stand-up meetings, unit testing, and continuous integration would be a good start. They sound bad to cowboys, but they solve these exact problems.

I used to run a "Software Quality Assurance Workshop" at Tektronix - I was an SQA engineer at the time, so I know a little bit about the topic. In researching this subject and also over time since then, I learned some interesting facts, which should be enough to scare the Vista SQA team.

1. There are strong mathematical reasons why it is near-to-impossible to find more than about 20% of the bugs in a system (of any significant size) using black box testing.

I don't recall the proof. As I recall the most important factor is algorithmic complexity - every additional two-way branch doubles the number of possible paths through the control flow. For perspective, a program with just ten branches requires 1024 different tests, for EACH grouping of input data.

Data issues provide more complexity. Heuristics may help discover as many of the pathological cases as possible. For example, every input data element (variable) must be checked at the 'fenceposts' (ends of the range), inside the range, and outside the range. Inside the range, there may be regions or single values that can affect the usage of other variables (e.g., angles might be defined in [0,2Pi] but tan (pi/2) is pathological), so those are another kind of fenceposts that must be discovered and tested for.

(There are many resources online. Wikipedia/Software Quality is a reasonable place to start.

2. Given a 'good quality' development system using techniques such as structured programming, code walkthroughs, manual and automated code analysis, and some other things, about 80% of the bugs will be in the original design document. (Another justification for Extreme Programming?)

Interestingly, something like 50% of these may be arguments regarding usage. "It's not a bug, it's a feature!" is often a valid argument - a 'screwed up menu' for one user may be just perfect for another. Of course, providing options to the user as X11 does, is often itself considered a 'misfeature' for the general public, if not an outright bug.

3. Given the same system, only about 20% of the total resources (time, budget) will be spent in the development phase. As I recall, about 20% -> planning and design phases, 20% to development, 40% during SQA, and the last 20% after release.

4. Again with the same system, the designed, QA'd, tested, and released code will have approximately 1 bug every 200 lines of code (while there are arguments about using Source Lines of Code as a programmer performance metric, it can be more easily justified for this purpose, as we can assume that most languages will have about the same level of ambiguity regarding what is a line of code.) This ratio has been empirically shown to run true across all types of programming, from assembler to 4G database code. I recall reading a couple of years ago that Microsoft admitted a rate of one bug per 80 lines of code, but I don't have a citation, so I can't say for sure.

All modern OS have about the same number of lines (according to the above), using the same metrics - about 30 million. This is apparently true for XP and for various recent distributions of Linux - Redhat, Debian, and others, including the applications that came with the distributions. Therefore, every OS ships to the customer containing something on the order of 150,000 bugs. I once listened to a presentation by the then-head of IBM's OS software support group - I think for OS/360, but it might have been a later product. They released a new version every three months, and customers found another 2000 bugs every time.

A probable advantage of Unix-like systems is the relative independence of different applications and components. Each application presumes less about its environment, and so can be less susceptible to problems caused by interactions within the environment. This helps to break the algori

This is common to all methodologies. There's nothing in XP that is more likely to get individuals to follow the rules than there is in any other approach.

That's a reasonable thing to think, but it's incorrect. In fact, it's the thing that makes XP different from almost any other method.

Pairing is one obvious thing: for a pair to slack requires a conspiracy rather than an accident or a moment of weakeness. Common code ownership is a second: if you are working as a team and truly share the code base, you will have plenty of incentive to get your colleagues to do things right. Retrospectives are another; if the team continuously adjusts the process to improve things and be useful, people are more likely to follow it. And short iteration and frequent releases keep people honest by exposing the work often to managerial evaluation and real-world conditions.

Basically, XP closes and tightens a lot of feedback loops that get left open or are too long in other processes. This gives you the incentive to do great work.

requirements analysis, specification development ... if you get that stuff done, the actual coding ought to be an academic exercise

If only it were that easy. Here is what I have found.

• The company selects certain employees as the Subject Matter Experts.
• Those employees are good at their jobs so they have demonstrated success in the very positions that the proposed software will serve.
• Just because you are good at what you do doesn't neccessarily mean that you are good at specifying software features and requirements.
• These people spend a lot of company resources doing the business modeling, requirements, and analysis up front and developing possibly CMM-I level 5 compliant documentation only to find that the application still doesn't add a lot of value for its intended audience.

That is why ITG is starting to take off. They recognize that just empowering the SMEs isn't going to bring the neccessary product and project management experience to the decision maker's table for a successful launch.

This I believe. It is always a good idea to continue to refine whatever processes, methodologies, and tools you use in the production of quality software. However, no amount of process, methodology, or tool upgrades are a satistactory replacement for human ingenuity in the solution of the very compelling problems that software development faces today.

Extreme Programming. http://www.extremeprogramming.org/
One of its basic tenets is pair-programming: http://www.extremeprogramming.org/rules/pair.html

Of course, if your partner is way below your level, every session would end up being a tutorial, very counter-productive. In which case, he should either step-up by practicing in his spare time, or worse comes to worst, get a new partner.

Extreme Programming. http://www.extremeprogramming.org/
One of its basic tenets is pair-programming: http://www.extremeprogramming.org/rules/pair.html

Of course, if your partner is way below your level, every session would end up being a tutorial, very counter-productive. In which case, he should either step-up by practicing in his spare time, or worse comes to worst, get a new partner.

I Am Extreme
Yesterday at work I drank an Extreme Gulp while doing some Extreme Programming, and then I went home and ate Extreme Duritos while watching Extreme Sports on cable.

Today every muscle in my body aches.

Posted on May 01, 2002
http://www.defectiveyeti.com/archives/000192.html

Check out Microsoft Takes it on the Chin Over Test-Driven Development. For comparison, check out Wikipedia on Test-Driven Development. This is particularly ironic given the recent Slashdot article about Microsoft adopting Scrum, one of the agile methodologies which, along with Extreme Programming, is instrumental in promoting Test-Driven Development as a core software engineering practice. I've also got a very brief article on my blog about the Qualities of an Ideal Test.

http://www.extremeprogramming.org/
http://www.extremeprogramming.org/rules.html

Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes

Teacher, if your students do not excel you then you have failed.

http://www.extremeprogramming.org/
http://www.extremeprogramming.org/rules.html

Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes

Teacher, if your students do not excel you then you have failed.

Actually, one of the tenants of Extreme Programming is to not work crazy hours:
http://www.extremeprogramming.org/rules/overtime.h tml

http://www.extremeprogramming.org/ :-P

Yes, you are correct, if you are still writing the software, and you notice the security and correctness are being compromised.

If you're doing final testing (say, 3 weeks before gold cd goes out), or if you've already sent the software out, you can't just rush out a fix, especially without seriously sitting down and thinking things through.

Part of these kinds of priorities is that you need to weigh the cost benefit of each change. You are suggesting that the size of the change has some kind of weight in this equation. My claim is that it does not. The customer doesn't care about how many lines you have to change, they care about if your software is safe, correct, secure and fast.

Using pithy excuses like, "I know it doesn't do what we said it would, but we only caught the bug 3 weeks before shipping," is an excellent way to show your customer how incompetant you are at software engineering and project management.

Far better to take the honest route, give them what they paid for, and not ship a bogus version. Unless, of course, your customer decides otherwise.

That's pretty much what I've been saying. Linus is doing the correct thing and Colin Percival is being too hasty with things.

Better yet, the whole thing needs a good dose of refactor mercilessly, similar to what X.org has been doing.

Spoken like an experienced Extreme Programmer.

This is why I like XP (Extreme Programming, the good development process with the dumb name). One of its rules is to involve the customer every step of the way. If the customer can see how the project is developing, they are less likely to expect an unreasonable deadline. If they can give you constant input, you're less likely to waste time coding stuff they don't want.

I'm ambivalent about the pair programming aspect, but the rest of XP tends to work really well.

Why have people started calling it eXtreme Programming? This seems about as lame as referring to Micro$oft. Have a look at the Extreme Programming website. Nowhere is the cheesy capitalization used, unless you count some graphic design on the book's cover.

perhaps their way of doing XP was flawed

That's a reasonable theory. It sure doesn't sound like my XP experiences. Perhaps you can tell me more about how they did XP.

felt like I was often having to interpret and 'guess-timate' a lot.

Extreme Programming requires an on-site product manager. Why would you have to guess if the guy who can decide is ten feet away? And if the product manager was, as XP recommends, defining the acceptance tests, where was the room for mystery?

the apps tended to have a lot of bugs

Extreme Programming requires two levels of testing (acceptance tests and unit tests) and continuous code review (via pair programming and collective code ownership). Further, with weekly iterations and frequent releases, both the product manager and the end users should be seeing running code on a regular basis. My last few XP projects have all been under one bug per developer-month.

At your shop, how do you feel those bugs slipped past all those safeguards?

things always went late

In XP the project is generally time-boxed, and data from early iterations is used to come up with the final plan. Thus, features get added or removed to make a date. On the projects I've been on, velocity has generally plateaued in the first 6-8 weeks, which gives you good data to predict the rest of the schedule. How was your project different?

And it's frustrating for a team to be in the hotseat when there's no document saying 'it says right here, you promised X by date Y.'

Take a look at some XP team rooms. As you can see, the plan in these is on the wall for everybody to inspect. And the plan should be updated every week through a joint effort by the product manager and the rest of the team.

I'm curious is XP 'sold' as working on large apps, or is it really most suited to smaller projects, and/or minor enhancements to existing applications ?

It's sold as working for teams of up to 12 for both new and old development for projects of indefinite duration (but generally a minimum of a couple of weeks). Some people have it working with many more people, either through larger teams or through many collaborating teams.

But really, it sounds like the places you describe weren't doing XP. Perhaps you could look through a list of XP practices and tell us how many were used on the projects you saw?

Focus on launch from the start. Launch all the time, incrementally. Here's a few other nice pieces of advice. Read it, and then, well forgetaboutit... just do it.

It seems like you're implying that the 'generic white box PCs from China' are inferior to IBM-supplied boxes. That may be true, but need not necessarily so.

I think you could read IBM's move as: "we just can't/won't keep up with the price/performance of generic white boxes coming from China, so therefore there's no point in continuing to produce our own line". And there's also their customers, who may just be saying to IBM: "look, we're sorry, but we'll be getting our generic desktops from China now on, they're cheaper, but good enough to do the job".

That wouldn't stop IBM from cutting a deal with a quality supplier, put "IBM" labels on the boxes, and offer those to their customers. It seems IBM just feels it isn't worth it anymore to produce those desktops themselves. Makes sense, if you ask me. Plenty suppliers out there to choose from.

eXtreme Programming: Comment early, read often, reply frequently, moderate mercilessly.

Aging is a built-in process, but what is a useful lifespan? Darwin's 'survival of the fittest' hints at it. For a single creature it might help to live 1000 years, but not for a species as a group. The core of the matter: adaptation to the environment.

With each generation, genes are remixed, and that gives an opportunity to adjust those genes to better match requirements. If creatures live short & reproduce quickly, then there are frequent opportunities to remix those genes, and the genetic package can quickly adapt to a changing environment (like in the case of bacteria). But if an environment is very static or isolated, it makes sense to remix the genes not too often, and have (or evolve towards) a long lifespan.

So what's a useful lifespan? A period that is long enough to reproduce, and short enough, so that the re-mixing of genes can keep pace with the changing environment.

If people would live 1000 years, it would also mean that human kind as a species would evolve at a much slower pace. That may not be a good idea. That is, if we disregard the option of genetic engineering to speed up the process...

eXtreme Programming: comment early, read often, reply frequently, moderate mercilessly.

I guess they aren't doing eXtreme Programming. I've worked overtime and most of the time the only "bonus" was more crappy code. A rested mind can produce A LOT more then a caffeine drawn one.

I've sat in front of my source code knowing that not only could it be made better, but that there is probably a better way to do it. Unfortunately, the reason old code stays around hobbling around the system with plaster casts around its legs and band aids covering its heads, yes more than one head because at some point I figured that it would be better to stick a brand new head on there rather than refactor the functionality out and create a brand new program.

Old code has much embedded wisdom. Lots of little bug fixes, solutions thought out, methods applied and debugged. Usually it's a really bad idea to scrap it.

If you apply proper refactoring techniques and some underlying method to allow the code to evolve, and you'll find that most cases of code rot are really just code neglect.

Of course, there may be licensing, or other reasons (designed for an environment that no longer exists) why it's best to scrap a particular codebase, but as a general rule, only drop software that's actually unsuccessful in the marketplace.

If it sells, update/extend/refactor rather than rewrite.

1. Strict adherence to the test first methodology (JUnit). It isn't enough to just write test cases, without nightly (or frequent) builds JUnits loose a lot of their effectiveness - especially in large groups. In addition, having regular code reviews to make sure people aren't just blowing smoke is essential.

2. Early and often QA cycles. Not only will the development team love this, so will your product owners. Here's a good starter for the http://www.extremeprogramming.org/rules/releaseoft en.html release often concept. Doing this will make your QA cycles much more effective and manageable.

3. Don't over automate. Automation can be a very effective tool; however, there must balance.

As for tools (sorry pretty Java centric here), I'd suggest starting with:
- http://htmlunit.sourceforge.net/
- http://jakarta.apache.org/cactus
- http://httpunit.sourceforge.net/

1. Strict adherence to the test first methodology (JUnit). It isn't enough to just write test cases, without nightly (or frequent) builds JUnits loose a lot of their effectiveness - especially in large groups. In addition, having regular code reviews to make sure people aren't just blowing smoke is essential.

2. Early and often QA cycles. Not only will the development team love this, so will your product owners. Here's a good starter for the http://www.extremeprogramming.org/rules/releaseoft en.html release often concept. Doing this will make your QA cycles much more effective and manageable.

3. Don't over automate. Automation can be a very effective tool; however, there must balance.

As for tools (sorry pretty Java centric here), I'd suggest starting with:
- http://htmlunit.sourceforge.net/
- http://jakarta.apache.org/cactus
- http://httpunit.sourceforge.net/

XP rules will guarantee you a 40 hours week and I think that should take your worries away

Again, let them know your priorities up front, and if they respect your time (which is what you're looking for) then it won't count against you.

Again, let them know your priorities up front, and if they respect your time (which is what you're looking for) then it won't count against you.

Sorry, that would violate the tenets of XP;^)

I've worked with Thoughtworks on a few projects and they looove XP. They also love the idea of refactoring and used to keep a project wiki for each project - similar to what is being described here, except without the historical info.
Martin Fowler, owner of Thoughtworks and XP evangelist, keeps a Bliki (his name for a cross between a Blog & a Wiki)

Maybe someone is actually using Evolutionary Programming (not)?

Sounds quite a lot like what's behind Extreme programming rationale to me.
Do what the users want, show them what you do often so they can change it as it goes, and don't try to do more than they need, and, well xp recommends you try to keep it clean nonetheless so you can extend it if need be.
However this is pretty hard to apply in real life,. Lots of people who are oblivious to both usability and technical constraints come in the loop and kill it all. They require plannings and time estimation to be able to satisfy their political agendas. They will first ask you to validate technical choices, only to later force them onto you when you tell them that the features sold to them are not present.

The key to efficient software design is flexibility. Designing for the current problem while allowing the easy migration to more complicated issues (such has massive scaling up).

I think the XP guys outline this particulally well.

Design for today, allow for tomorrow. Too much software is designed with only one of points in mind. The great software covers both.

Although I think that XP has some valuable ways of bugs to be found. My link should have been "more information".
The ore of bad programming can be probably found elsewere.

Is Junit any way linked with extreme programming? It sound that their goals are quite identical. However their ore informationmore informationsection doesn't mention JUnit anywhere.

Is Junit any way linked with extreme programming? It sound that their goals are quite identical. However their ore informationmore informationsection doesn't mention JUnit anywhere.

XP would have saved it

> I agree with the whole fail fast notion. Try
> stuff as fast as possible to see if it will
> work. I think we see this philosophy played out
> in things like RUP and Extreme Programming.

er..not quite, with XP at least. They do test first - the complete opposite of fail first.

You write the unit test before the code, allowing 'immediate feedback while you work.'

It might not pass the unit test, but at least you know it hasn't passed, thus it isn't finished

Could you explain the meaning of "agile process like XP"? (I really do not understand what you mean.)

The poster is referring to eXtreme Programming, a 'new age development methodology'. It has a lot of good points that I use even in my project-driven method, but has been criticized because of some of the dogma involved.

If you have a good logical design that compartmentalizes each functional unit of your code (what I'll call "well-factored"), how long should it take to fix any one bug? For a typical app, even of pretty hefty size, you should, in theory, be able to run to the exact object, swap out what's broken, and *poof*, every place that functionality is needed is good to go. XP et al really do lose a lot of time in the overhead it takes to keep two people on any programming task, unit test, and the rest. You might be nearly guaranteed nice code, but what's your opportunity cost? In short, it's having two coders hacking about twice as much on what, if they're mature enough, should be well-documented, modular code!

Now we all know *poof* is not the case, and we all know that a well-factored system is about as hard to come by as nirvana (which means each fix requires ripping out a chunk of code), but the argument is still a valid one. Unless you have a huge system, where perhaps someone's "fixed" a bug by hack on top of hack ("Hrm, Bob's addFunction always returns a number one too low. Instead of bugging Bob, I'll just add one to the result in my function."), bugs today aren't like bugs in pre-object oriented days. If coders in the 80's had the debug tools and langauges we have today... Let's face it, it's much easier to create an Atari 2600 game today than it was when you had to burn to an EPROM to test on hardware each time and print out your code to review it.

The bottom line is whether it's more cost-effective to prevent 99.44% of bugs up front than it is to fix the extra 10% that slip through. I believe the original post is simply suggesting that the cost of fixing on the backside is dropping considerably, especially compared to what the same results would've required decades ago, and that is, honestly, a good point.

(Remember, this isn't upgrading code -- might be awfully tough to make code that's slapped together change backends from, say, flat files to an RDBMS; this is just bug fixing to make what you've got work *now*. But XP tells us not to program thinking that far down the road anyhow, so future scalibility is another topic altogether.)