An Oo Magic Bullet

RefractingEmotions:

Let me throw out a question that has always bothered me. I've worked with several people who follow object oriented programming on an almost religious level. But I've noticed that few of these people have ever implemented large pieces of software (e.g., 20K to 50K lines of C++) on commercial project schedules. And in the case where the object zealots have implemented large pieces of software, they have tended to either be too slow or not work or both.

This happens when methods don't have a way to evaluate the performance and fitness of the software early on. XP tends to evaluate these on the fly as each user story is implemented. --DickBotting

So I keep being struck by the idea that there are lots of consultants and "teachers" and authors who push the methodology. But these same people are not really down in the trenches building software. I have to say that "Extreme Programming" strikes me as another example of people hyping yet another magic bullet.

People keep searching for a magic bullet. They want something that will make the construction of large correct and maintainable software systems easier. Ideally done by people they don't have to pay lots of money. But the truth is that there is no one answer or methodology that will deliver this. It takes years of experience writing software and perfecting the art. There is no shortcut. Smalltalk is largely a failure. C++ is not the magic bullet, Java is not the magic bullet and DesignPatterns are not the magic bullet. But, with the exception of Smalltalk, its possible that they may all be weapons in the arsenal.

What is an alternative?

This is bizarre. ExtremeProgramming was derived initially from real world experience with a large, successful, program written in Smalltalk, and initially promoted by KentBeck, someone with a wealth of "in the trenches" experience.

And yet from this you conclude ExtremeProgramming is a magic bullet and Smalltalk a failure?

I don't think this is bizarre. I've met practitioners who don't understand what OO is good for. They can indeed be religious, using OO as a kind of ObjectCargoCult. I think it's likely that XP will be similarly abused, on occasion, by people without an engineering mindset. Of course to do this they'd have to drop or very badly mangle one or another of the XP practices, but that will happen I betcha.

I can only reassure the original poster that I've seen several extremely large systems put together using OO, to multiple billions of dollars of good effect, by good OO programmers down in the trenches. I still occasionally encounter large developments that don't use OO, but they're rare and they're usually in deep, deep trouble. OO is just easier to maintain and so it lives longer and tends, as a codebase discipline, to scale better. You can still make disastrous messes using it - it ain't a magic bullet - but used appropriately it does make life a lot better. --PeterMerel

Whilst not agreeing entirely with your comments - I do know where you're coming from. A lot of people still push OO tools, and religious adherence to a methodology, drawing as many UML diagrams as possible. This does not work - or at least I've never seen it work (see BigDesignUpFront). See ExtremeProgramming for a more sensible approach, (although not the only approach).

Also, how OO works on a internet architecture is still largely unproven IMO. Certainly, Microsoft has not ventured down the OO route with its MTS/DNA technology. For good reasons? See DnaVsOo.

I have my doubts about the performance of 'distributed objects' in the real world.

What are your doubts? I confess I fail to understand how OO or the lack of it is relevant to the performance of distributed components. When you come down to it OO is simply good factoring - good for maintainability - and that has nothing to do one way or the other with performance. Or is there some kind of inobvious connection?

OO has its good and bad points, and many of its idioms do not work well over a network.

Note: I did not create this topic. -- top

Returning to the original question.....

Something I keyed on was the descriptions of the individuals involved. One group is 'zealots for approach _____' and the other group is 'delivering systems'. I'm firmly in the latter group most days (I realize that it takes a delivered system to pay the mortgage) but I've also learned that the lesson of SEI CMM is that the zealots are definitely right.

Contradictory? Only if you don't accept that there are natural limits of the problem space addressable by any given approach. Code generators were an early magic bullet that would make programmers obsolete - just answer a few simple questions and your programm will be automagically put together completely bug free!! We all know that the number of programmers in the world is increasing so that promise is proven vapour ware but code generators have made a permanent comeback although they are now masquarading under the name of 'Wizard' or 'Template File'. The promise is vapourware simply because there are limits to the amount of ability that can be put into a program - not because code generators aren't extremely valuable tools.

Seeing the limits of a code generator are easy, just try to imagine using a VisualStudio wizard to write an application which will be run on a Unix platform. (For the curious, I've written a VC++ wizard which generates code for Win, Unix, and VMS so it is possible!)

Seeing the limits of something more general like an approach to problem solving is much more difficult. The discussion above reflects the reality where many approachs (waterfall, procedural, MS, OO, XP, Rational, etc.) and many technologies (state machines, trasactional, event/messaging, etc.) all apply to most kinds of programs. The people who are good at delivering systems on time and on budget have learned to recognize the limitations of each technology, approach, and tool and can merge them into the appropriate mechanism for the project as required. They'll probably also have a relatively limited range of problems that they commonly address and may well have significant problems dealing with radically different types of problems IF those problems happen to be near or across the natural limits of the approach(es) used.

So that's my answer to the original question. There isn't a single magic bullet, there's many of them and it's up to the practictioner to decide which bullet to chamber when taking aim at any given problem. XP is another bullet to have handy when you need it so listen to the consultants and instructors who have never delivered a mjor system but know it inside and out. If you listen between the lines a bit, you'll start seeing what is required for it to be a success:

If project 'X' has intensely rigorous specs and/or a client who always wants more and/or many staff who are going to be learning the techniques or tools, the project may well be more successful with a different methodology. If it's a new package being created for a new customer by mainly junior staff, then XP is probably the wrong choice. If it's maintenance release 3 for a long-standing customer by staff who've been involved since day 1, XP will result in a client seeing things reach the test systems sooner and feedback from their reps modifying the designs in days rather then releases. -- KAS (18 May 2004)

I've also many times seen projects fail (partially or fully) due directly to a primary focus on methodologies -- exactly the opposite of the intention, of course, but it makes sense if you consider that such a focus means that the primary focus is no longer on the product under development.

Thus zealots can be very right in theory but wrong in practice, simply because it is inappropriate to have too much focus on any methodology, no matter what it is.

Under normal circumstances (SNAFU), with luck an organization can achieve the number one thing that it focuses on. For NASA, medical equipment manufacturers, etc, that'd better be a certain area of quality called "safety", and never mind how much the deadline slips as a result. For non-safety-critical commercial products, the focus better be on shipping, because otherwise it might not ship (marketplaces are often realtime: a significantly late product is a wrong product). Only companies/contractors selling the methology itself as a product can repeatedly get away with focusing on the methodology as the number one priority.

EditText of this page (last edited February 17, 2013) or FindPage with title or text search