Slashdot Mirror

only one person should be writing it

Which works well, unless you subscribe to the extreme programming paradigm. In that case, you're never supposed to have a single programmer working on the code - always two there are...

People

Richard Stallman -
Eric S. Raymond -
Larry Wall

Linux Programming

Unix

Programming Methodologies

C Programming

C++ Programming

Perl Programming

Network Programming

Open Source

In order to complete this, a set of regression tests were written. For example, if the amount of money collected doesn't match up to our order table, we get notified via our cellphone's text messaging as soon as the cronjob picks it up.

What you describe isn't regression testing. Regression testing "is a quality control measure to ensure that the newly-modified code still complies with its specified requirements and that unmodified code has not been affected by the maintenance activity." More accurately what you've done is paranoid programming. Really, these two things are orthogonal.

My question is, how common is this for the software industry? My company had never heard of this before I came along. Is it the norm? (When you answer, also say whether or not your company does risk management.)

This depends. Every company I've worked for has claimed to be concerned with mitigating risks both in the testing phases and post-release phases of the software development lifecycle. However, the amount and kind of testing and programming actually done have varied wildly and always ends up being determined by the industry for which the software is being built. In your case, money is the biggest factor. Organizations such as banks and other financial institutions are highly risk-averse due to the responsibilities and legal concerns related to handling others' money. It follows that these organizations regularly conduct formal testing of their code as well as "program paranoid" to mitigate screw-ups. In start-up's I've worked at in the past, this wasn't nearly the case since it was more important to get a product out the door and this sort of testing/coding always went out the window with looming deadlines.

So to answer your question, yes, regression testing (and paranoid programming) are highly common in the IT industry and their respective importance is a function of the risk aversion of the intended users/customers. My advice is to always practice good, paranoid, professional programming augmented by formal testing procedures. Vary the time spent on each to achieve the appropriate balance.

Frankly, the best way to enlighten yourself on this matter is to educate yourself in the ways of Extreme Programming. The horribly trendy name aside, this is the truly the only management fad I've seen in 10+ years that holds any merit.

• The Rules
• The Wiki Roadmap

First you should understand the difference between testing and verification. With testing, you rule out a certain number of bugs, but you can never guarantee the absence of bugs. The latter is only possible with software verification, where you prove that the software contains no bugs and fulfills its specification.

Unfortunately, software verification is very expensive. Also, software verification is still a subject of research, and AFAIK it has not been tried for large software projects so far. (My current research project aims at verifying a complete operating-system kernel -- check out the VFiasco project.)

So in most cases, verification is too expensive, and you need to ensure robustness by other means like a good programming standard and testing. (I believe that is what you are looking for, despite the title of your question including the word ``verification.'')

If your shop uses C, I recommend the following book: Les Hatton, Safer C . It explains what a good programming standard should contain, and advocates automatic enforcability. (It also explains what the standard should not contain -- in particular, issues of style such as indentation and variable naming.) One example of such a programming standard for C are the Guidelines for the Use of the C Language in Vehicle Based Software, which should be particularly relevant to you as you also work in the automotive industry.

Testing is another important aspect. In safety-related environments such as yours, a high test coverage for your code is desirable. This requirements suggests automated testing on the unit level. Automated unit testing is practical only if the code is designed to be testable, and there are a number of strategies which provide this property, such as avoiding dependency cycles (for C and C++, John Lakos' Large-Scale C++ Software Design still is the ultimate guide), or creating the unit test before the program (the Extreme Programming way). I also liked Testing Object-Oriented Systems: Models, Patterns, and Tools by Robert Binder - a huge and thorough guide to all imaginable kinds of testing, especially for object-oriented systems.

Extreme Programming (XP) is a very simple and effective discipline of software development based on values of simplicity, communication, feedback, and courage. It includes techniques for programming, and techniques for planning and working with the "customer", the individual or group that has responsibility for making business decisions about the program that is to be written.

Read more about XP at extremeprogramming.org, or on my site, XProgramming.com.

This isn't a flame, it's a standard old fashioned rebuttal.

Your point about pair programming is completely groundless.

Scenario 1 - no pair programming
Two bad programmers, bad code
One good programmer, one bad programmer, some bad code, some good code.

Scenario 2 - pair programming
Two bad programmers, bad code but any mistake either of them see will be removed, improving the quality of the code.
One good programmer, one bad programmer, code up to the standard of the good programmer, and the bad programmer learns, hopefully becoming better.

XP does not say 'don't design the overall system' - you are misrepresenting it. A look at this talks about the plan for each release. Sure, bad developers = bad unit tests, but bad developers = bad product, nothing will guard you against that. Nobody said 'Extreme Programming will mean you have no bad developers.'

thenerd.

A quick warning... I consider myself a relative newborn in the world of software development. I present these opinions under the consideration that my opinions can change at any moment. =]

A lot of the dire predictions of software atrophy and such are a result of applying the wrong methodology to a project. Yes there are uses for Software engineering, but I think this approach is overkill for even large scale projects. Check out Software Craftsmanship: The New Imperative for a different perspective. A perspective I think is in need of serious consideration. The gist is returning to the days of master craftsman and apprenticeships. This focuses a bit more on the learning aspect than actual development methodologies, but you can always go to The Pragmatic Programmer to fill in that gap.

"As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress."

This is where "refactoring" (see Fowler's Refactoring) really shines. I find it difficult to believe that refining the software base is not progress. An initial revision where the code functions by its contract (if your into designing by contract), then you refactor the body of the function/method for speed / elegance. Then you can run your unit tests on the function / method to test that the refactoring session did not break any of the design contracts (whew).

I think they may be trying to restate the broken window theory (see Pragmatic Programmer), were a broken window (or bug) in a building (or system) leads to delapidation elsewhere in the building (or system).

And then there are the agile methods, including XP. I think these answer a lot of the limitations and issues with Software Engineering practices. Interacting with clients (having a client there during each iteration) gives you the benefit of almost real-time feedback so that you can update your user stories on the fly, etc.

Without rambling on any farther, my point is not too spend too much time looking for a specific unified theory. Read up about all the ideas, methods, and theories. Take the best parts from each, then crank the knob all the way up (if I may borrow that from XP =] ). Don't let anyone tell you there is a science to software development that is easy to reproduce, and that you are just a link in the overall chain. You practice and perform a craft. Enjoy it!

With the "pair programming" the XP guys recommend, this isn't much of a problem.

But in lots of web-systems-development contexts the emphasis is on getting new sets of features built as quickly as possible, and there's a strong pressure to be in "permanent protyping" mode.

Prototyping is where you intentionally ignore a lot of the factors important in the real world, so that you can quickly bring some desired aspect to apparent completion. A great example is building a movie set: you only build the walls and finish the surfaces that the camera sees, but the sink doesn't have plumbing and there's no glass in the windows.

On a project of any size, the notion of "permanent prototyping" is a dangerous myth. If you're building for long-term quality and flexibility, you can't cut corners; they always come back to bite you. Trying to turn a movie set into a real house is much more painful than just building a real house, especially if there are people living in it already.

A better solution is to pick one of the various agile methodologies, like Extreme Programming, Feature-Driven Development, or Scrum. All of these methods focus on building very high quality software in a way that's amenable to change.

XP, for example, lets the biz folks change the spec every week or two if they want. (Which sounds like disaster, but smart people quickly realize that making random turns every few blocks is not the best way to get somewhere.) That gives you all the benefits of "permanent prototyping" without getting it's biggest drawback: the speed with which you reach critial mass.

You're certainly right that expert programmers don't absolutely need static typing. But for experts, static typing isn't that much of a burden, and even us geniuses have those occasional Friday afternoons where our brains go to the bar two hours before our bodies.

I remember taking a class (I think in BASIC) at a community college. I already new BASIC, had been programming in it for several years. (I was only taking the class for the easy credits.)

After a test was turned in, the teacher called me over. He showed me a code fragment submitted by another student. It was practically identical, even to the variable names. (Of course, in this old dialect of BASIC, variables were single letters.)

How did this happen? Outside this class, the other student and I were collaborating on an astrophysics simulator (also in BASIC) for another class. Today, our style of coding is called Extreme Programming. In the course of this we had tacitly developed common coding conventions and styles.

Even so, I was surprised how similar our independent output was.

Fortunately for me, the teacher was a friend of mine and he believed my explanation. Even so, I sensed some doubt on his part. Were he a relative stranger, things might have gotten messy.

Have you even looked at extremeprogramming.org?

XP is divided into four major areas of activity: Planning, Designing, Coding, Testing. The project starts with requirements analysis and an architecture or framework for the entire system. Emphasis is placed on simplicity and preventing feature creep. Then it goes into an iterative development phase in which the emphasis is on rigerous unit testing and feedback, ensuring that code works, and problems are detected early.

The value proposition of XP is risk control: feedback provides a good idea of problem areas and allows for handling them when they arise, and iterative development ensures that feature creep and miscommunicated requirements cause limited damage.

You are correct that XP is not that new. It bears many similarities to the Rational Unified Process, but is in no way related to RAD. XP stresses the importance of an underlying architecture and extensible design, before coding is started.

Would you care to expand on what you mean by "REAL Software Engineering texts"? Most people seem to believe that scientifically provable methodoligies are the only option for software engineering ... how unfortunately that it was recently proved that it is impossible to reliably estimate software complexity, which is a core requirement for software engineering.

Or perhaps you have forgotten that software engineering, not other engineering disciplines, does not concern itself solely with technical aspects of the software, but business aspects as well: resources, deliverables and schedules.

XP is significant in being one of the least presumption of design methodologies. It does not require any knowledge, on the part of the programmer, of the business processes of the end user. Many software engineers think this is wrong, without realising that business process engineering is a sector-specific activity and an entire field of study; not something a software developer can pick up in a few weeks in order to do requirements analysis.

Cooper gives an example of a building architect interacting with the customer and the engineer to determine all of the building requirements before building starts. What he fails to take into account is that the building is a framework - as long as it has the right size, foundations and number of floors and elevator shafts, it is going to support a huge variety of functions.

Once the shell is complete, other teams move in to customize bits within the building. You can vary the number of elevators available within the limits; make them faster or slower, or only stop on certain floors. Each floor can be divided up with hardboard walls, plumbing and electricity get installed into ducts, aircon is added, carpetting, and finally furniture and fixtures. These don't need to be designed up front.

XP, unlike non-iterative methodologies, happily delays these details until later. RAD, by comparison, starts with the wall art and curtains, adds some furniture and walls, and then falls flat because it doesn't have a building.

we practise extreme programming (XP). To give you some context - we break software development down into 1 or 2 week iterations and break the work down into stories. These stories are written by people like myself, customers, and are estimated and by developers/engineers. Estimates range from half a day to about 8 days for the work. The benefit to the customer is in XP is visibility. Doing these small chunks of work we are always able to have a snapshot of the project and can massage it into place if things are looking bad.

so now to the point...
we are still finding that estimates, even though in bite/byte-size chunks, can be inaccurate. what we are looking at making the programmers do is give us a high and a low estimate for the work. We then roll a dice. If you roll a 1, you take the lower limit, a 6 the upper and so on.

this may sound totally crazy, but - i dunno - i've seen people spend months analysing a workschedule and still be MILES off the mark in terms of an estimate.

I was referring to this code:
MakeNotAccidentallyClickable(widget);
That's what I meant by "example".

Yes, I wrote that -- but it's a direct translation of the comment someone else told me couldn't be replaced with a function name.

Ok, perhaps I made a straw man. The point I was trying to make is that there must be more details to the situation, whatever they are; and because your code didn't specify them, the problems you found in my commented version of the code may or may not exist in yours. One can't know without more information.

You're absolutely correct. However, this situation MUST be left to the wisdom of the programmer. There's simply nobody else to trust! If the programmer's wrong, he'll write wrong comments as well as wrong function names, and most likely wrong code as well. (See "peer review" and "pair programming" for some solutions to this.)

Perhaps I can sum up my thoughts this way. Programmers make mistakes.

Just a quick interruption: so do maintainers. The programmers shouldn't assume the maintainers are going to make all the mistakes in the book, and neither should the maintainers assume that about the programmers. A lot of common programming practice seems to assume that a horde of idiots are going to take over the code tomorrow, so anything I don't finish today will get destroyed and perverted. This results in late hours, aggressive comments (like "DON'T TOUCH THIS!"), a lack of tests (because you don't think the later programmers will have the wisdom to improve you code), and so on. Some cynicism is appropriate; after all, the later programmers will have at best a foggy memory of what you were thinking when you wrote it; however, at the same time, it's just as likely that the later programmers will understand the overall problem BETTER than you do.

It's hard to tell mistakes apart from deliberate decisions without some indication of the programmer's frame of mind.

This is true, and it's why I want code to be self-documenting. The code has to wisely and correctly make comments unneeded; you can't just delete the information contained in a comment. The advantage is huge: you go from *two* sources if information which may contradict each other (don't tell me that you've never seen out-of-sync comments ;-) to one source which is automatically tested.

Thus, comments are only unnecessary in perfect code.

Not really true. There's no such thing as perfect code; comments are unneeded in code which tells the same story as the comments would. And such code (unlike perfect code) is not overly hard to construct.

If you choose to encode your comments using function names, rather than the features provided by the language specifically for the purpose, that's your choice;

Pardon, but function names are usually more of a language feature than comments; they're checked by the language, they're part of the syntax... Comments are just bolt-ons. And this IS the purpose of function names; but most people don't use them wisely.

but it's not yet clear to me that it is a beneficial one.

Well, I've given some reasons above. To me, the biggest two are as follows:

1. information can't get out of sync.
2. all information appears in two contexts: actual use (in the code), and prototypical use (in a unit test). Function names will look dramatically bad if they're chosen inappropriately. Comments can be ignored.

Comments can get out of sync with the code, in which case all of their "benefits" go to waste; and they can appear in only one place, and aren't checked there.

Have you ever come across (or written) any material that discuss the pros and cons of your approach?

It's a critical component of Extreme Programming, which is being discussed pro and con in a lot of places. I can also link to a few semi-balanced discussions (good paper, but biased toward the rather management-heavier SEI CMM model, which is needed for some projects). BTW, I was going to provide a con link, but the one I found is BAD -- hasty generalizations are just FLYING. Every single "danger" he cites is completely unjustified by experience and study, and many of the quotes he makes are out of context. It looks more like a Usenet post than a web article.

Oh, here's dmoz's directory page.

Anyhow, to implement what I'm describing you'll need at least Refactoring and Unit Testing from XP's arsenal. There's no reason you should have to adopt more, although once you have those in the others usually can be added at will. You also have to practice egoless programming -- don't be offended if someone changes the name of one of your functions; instead, make sure that the name is still appropriate to the use (if it's not, we have a bug being formed, since the person misunderstood the purpose of the function; you should show him a unit test in which the old name makes sense but the new one doesn't).

To me, function decomposition already serves three purposes: information hiding, code reuse, and divide-and-conquer problem solving. Adding a fourth criterion--of allowing comments to be encoded as function names--seems to raise the possibility that the criteria may conflict, and one may have to be sacrificed for another. Looking at the list, I know which is first on my chopping block.

Information hiding: true, but part of the purpose of IH is exposing only the correct information. That's part of the job of the function's name. So really, these two work together.

Code reuse: how can you reuse code if you don't know what it does? By choosing a good name, you are able to tell when things are being reused, and how appropriate they are to the situation. Note that the first time you extract a function, it'll have a very specific name (because you probably took it from a comment). The first time you reuse that function, you'll probably want to think of a little better name, and you'll probably also make some code changes -- the code worked in the one special case before, but now it has to work in two cases. As you keep reusing, your code keeps becoming easier to reuse; the name and the code keep becoming more general. So those two work together as well.

Divide-and-conquer: indeed, this is important -- but it's hard to argue that bad naming will help your strategy here.

-Billy

About over design in OO - check out YAGNI (You Ain't Gonna Need It) and other XP principles here. Or, take a look at this article, Is Design Dead?.

Some here are warning you that major changes always require a total rewrite; yet in real life, total rewrites result in inability to compete (look how long the Netscape rewrite paralysed Netscape, unable to meet Microsoft's challenge!). There's some good discussion of the danger of rewriting at a former MS software engineer's site, and some limited advice about how to get away without doing it.

But you've decided to rework rather than rewrite, you say, so I have no doubt you'll ignore the naysayers here. So what CAN you do? After all, as you recognise, reworking is dangerous!

The following rules have worked for me; I've refined my own experience with advice from Fowler's Refactoring, a book as useful as Design Patterns, and with study of Extreme Programming, a design methodology forged in the traditions of Smalltalk, and in the knowledge that maintainance, the most important and expensive part of software engineering, is also the least studied.

First, do the simplest thing that could possibly work. Don't EVER take your program out of commission for more than a day; make sure it runs at the end of each day. If you're doing something and at the end of the day your code base is broken, STRONGLY consider throwing away your changes and going back to the design stages.

Second, rely on unit tests extensively. Start every change by writing as extensive of a unit test as possible. Unit test every function you touch, BEFORE you touch it, and after. Unit test every change you make, and run the unit test BEFORE you make the change to ensure that it fails (i.e. it detects the change). Write your unit tests BEFORE you write code, whenever possible; you'll objectively know your code is done when your unit tests pass.

Third, don't design too far ahead; you don't know what tricks the old code is going to throw at you. Implement one feature at a time, bringing the code into compliance. Once everything has a unit test (thanks to your following the above principles), THEN you can safely embark on larger design changes -- and in the meantime, you have working code with new features, a win even if your customer/boss/manager decides not to continue.

Fourth, don't be afraid to redesign your own code. The stuff you wrote has more tests, so it's safer to change, but it's more likely than the old code to lack some critical understanding only age can give.

Fifth, use the principles of refactoring. Whenever possible split each code change into two parts: first, a part which changes the structure of the code without changing its function (and which therefore allows you to run the same unit tests); and second, a part which uses the new structure to perform a new function (thereby requiring new unit tests).

Good luck. If you want more advice, read up on Extreme Programming.

-Billy

You should read up on Extreme Programming, in particular Code Refactoring. It's a method of cleaning up old code. A very well written book, as well as an excellent code-housekeeping method.

You should read up on Extreme Programming, in particular Code Refactoring. It's a method of cleaning up old code. A very well written book, as well as an excellent code-housekeeping method.

Honestly, I was starting to feel the same way in the work world. I've been a software engineer professionally for about 10 years. Extreme Programming (XP) is the twitch in your fingers when the meetings get long, it is the surge of pride when software works first time round. Check it out: http://www.extremeprogramming.org or for a business-level summary: executive summary of XP. Good luck! Don't give up just yet. School can be stultifying, and so can work. But if you are talented, there will always be good opportunities. Also consider starting your own business. There are lots of programs for supporting small business in most countries - it is very exciting and great experience. Or work for a startup doing cool stuff (not many of those around anymore, but still).

XP is actually notable for its lack of "mumbo-jumbo CS-degree bullshit" -- it was developed and refined by development teams in the field (of industry and cosumer-related IT, not building space shuttles or cruise missiles, like so many other methodologies).

XP is one of a series of methodologies called "lightweight," or, more recently, "agile." A good starting point for reading about it would be the book Extreme Programming Explained by Kent Beck. (Sorry, no ISBN, look it up somewhere.) You will find it much smaller, simpler, and more informative than most books on the subject. You can also check out their website)

There are actually a lot of other methodologies besides XP that are taking this approach -- you can find a lot of links and a statement of shared values at the Agile Alliance website.

phil

Manufacturing is more akin to installation of software, than creations of it. Creation of software is more like the engineering of the thing to be manufactured (design) and it's manufacturing process (implemenation).

When creating a new piece of software, there is a very large amount of discovery. It is impossible to estimate how long discovery will take, it would be akin to setting deadline for the cure for cancer. It is even impossible to know between two people which will get it done faster.

In addition, it is almost certain the case that somewhere in the design or implementation phases, a conflict in requirements is found or requirements are found to be incomplete. Because of this, the requirements must change. A change in requirements becomes a change in estimation.

Then there are people details, such as burnout, roll over, yank factor, procrastination, and dicipline. These things happen with different people at different times. The result is more uncertainty.

Personally, I like XP's method of handling estimation: the user stories (requirements from the customer) are broken into tasks by the developers working on the story. The tasks are estimated in the best possible scenario by the developers working on the task. No task should be longer than 3 days (if it is break it up). Then you use a previous measurement of how quickly you finished tasks to limit how many ideal days there are in a time frame.

The cental thoughts to this method is that A) only the people doing the work can estimate for themselves; B) the accuracy of estimation is inversely proportional to the length estimated. If a developer says something will take 6 weeks, they likely don't actually know how long it will take, but are picking a seemingly large number to give them wiggle (I call it "Scotty padding", refering to how Scotty would overestimate the time to repair the Enterprise so that he looked like a miracle worker); and C) using precious measurements adds a reality factor to how off your estimates are.

But there are problems with this method. The main one is that tasks can be unrealized until implementation. No matter how well you plan, something will likely get left out. Another problem is that is doesn't work over a long period of time. This method is used for planning an iteration (about 1-2 months). Longer than that the estimations will go wonky because the estimations for an individual task will vary greatly as more work is done. At the start of a project, it is easy to add a feature, but later on it may be easier, because you have supporting classes in place, or harder, because you need to update a large part of the system.

So I'd say it more like the weather. You can estimate well up to a certain point, but after that, you're just throwing darts.

I can see where, if something breaks rather heinously and you're dealing with production system downtime, you would feel the need to stay late and get the job done. I've done it many times myself. And maybe it is while you're young and single, things like having a life outside of work don't matter so much.... I know I had a blast as a road warrior when I wore a younger man's clothes... but there comes a point in your life, if you bother to have one, where you need to slow down, get off the road, and devote some quality time outside of work. You need to start working smarter, not harder. Set your customer's expectations, secretly plan to exceed them, and make your business not on getting it out the door first, but on having a reputation for things that work right the first time. Grow organically. And stop pushing yourselves to the breaking point... because at some point you'll forget where that point is... and find yourself taking your vacation within reach of a nurse call button.

The insanity we call running a business these days has got to stop. The stock market and the VC's these days expect more and more out of less and less, and it's all a huge bet... not on whether your company can make a decent product, but on whether it can totally dominate the entire market... and if you can't do that, you lose. What is so bloody wrong with taking your time and making a quality product that people are willing to wait for? The world is filled these days with "extreme" this and "ultra" that and the idea that if you're not pushing body, mind, and soul to 115% of their ability, you're a loser and deserve to be tossed aside as a know-nothing.

Actually, there is one thing that is "extreme" that appears to be working. Extreme programming. For those who haven't read the link already, you work in pairs, one drives, one catches mistakes; stay in close contact with your customer; design using the KISS principle; keep your internal meetings to a minimum, and those short and informal; release daily; test constantly; if you don't know how to test it, don't write it; write only what you need, when you absolutely need it; and (with few exceptions) when 40 hours a week are up, GO HOME! This prevents programmer burnout, and enables you to write lots of good code fast. I know someone who is doing this now; I envy her greatly. She loves her job, because the method enables them to kick ass without wearing themselves out. I don't know whether they have nerf guns or ping-pong or video games or not... but I imagine they don't need them.

When you design quality and sanity into the process, you don't need this balls-to-the-wall mentality that seems to pervade the halls of high-tech these days. You can have a life. What's so wrong with having a life? I thought computers were supposed to make life easier, not harder.

--
If you're not having fun,
you're doing it wrong. -- me

A Second Look at the Cathedral and Bazaar

Try looking into "Extreme Programming" concepts.

www.extremeprogramming.org
www.xprogramming.com

He means "eXtreme Programming" (See this link.) It's the latest process trend (that is ... it's trendy --- like, sooo retro.)

Has anyone had any good experiences with ISO 9001?

Out of curiosity, tell me what you think of Extreme Programming. Design is not antithetical to Free Software or Extreme Programming; it just is often important for developers to get their feet wet and see what the problems are.

Knuth and Stroustrup have both argued that they have never seen any large, successful projects that haven't gone through some full revisions, where the design is cleaned out and built up again. Oftentimes, these large monoliths are really a composition of smaller objects, like Internet Explorer is. (It's a collection of COM objects.)

BTW, why do you care about getting modded down? Have some courage.

This must be XP for internet companies. I've always read that User Stories should be 1-3 weeks

Ever look into Extreme Programming? One of the aspects of XP is that all coding is done in pairs, know as pair programming. This type of programming creates better code in about haft the time and if any production code it not programmed with your partner it is thrown out.

I know the concept sounds very strange especially to people, like my self, who view code more as art the engineering. But it does work. Not all programs are cut out for XP but if all the shop does it. It can be very beneficial to all.

-Scott

My experience with code reviews is that they are helpful when people actually do them. But they've always felt very artificial to me; even though I know intellectually they pay off, they feel like they take me away from "real" work. And I've never done it in a context where all code is reviewed; I've only seen it done where a sample is taken and examined.

When I've done pair programming (in an Extreme Programming context) I feel like I get most of the benefits of a code review, but over 100% of my code. And since the reviewing is integrated into the coding process, I always feel like progress is being made. Indeed, now solo programming feels a little unsafe to me, like swimming in the ocean with nobody around to notice if I get sucked out to sea.

Code reviews are a terrible practice. They either turn into a week of web surfing and at the end everybody says all of the code is perfect or what's worse they are taken seriously and turn into a morale killer. People don't like having their competence questioned. Even if they are fairly junior they like to think their work is up to scratch. Senior people don't like being questioned about their particular programming style: they know they have a number of successful projects already behind them and don't want to be questioned on how they perform the work. If it does the job and is maintainable it should be good enough. Code reviews almost always end up turning into personal attacks. It's a sneaky management ploy to turn developers against one another. They cause harm, quarrel amongst seniors and intimidation for juniors. THEY SUCK!!!!!!

How to avoid the problems of lack of code reviews? Number one is have good comprehensive unit tests. They tell you a lot more about code's correctness than any amount of code reviews you can think of. Pair programming eliminates the issue of "lonely wolves" where individual programmers hoard a piece of application and don't let anyone else near it. These two suggestions are the fundamental blocks of extreme programming.

...it's a bad idea to let the unit tests drive the code instead of vice versa, though, for all the reasons I mentioned in my original post.

If I understand your objection, the XP methodology appears to define unit tests somewhat differently: Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.

A unit test would appear to be an especially rigorous form of specifications. Does this approach not meet your requirement that production code should be written to the requirements, not to the acceptance tests?

If its so common sense, then why do so few people do these things?

I don't have much XP experience, but *good*. You're supposed to think up the unit tests that break your code - then fix the code so that it isn't broken any more. When you can't think of any more tests, the code works.

I don't have much XP experience, but *good*. You're supposed to think up the unit tests that break your code - then fix the code so that it isn't broken any more. When you can't think of any more tests, the code works.

I don't have much XP experience, but *good*. You're supposed to think up the unit tests that break your code - then fix the code so that it isn't broken any more. When you can't think of any more tests, the code works.

The tests are also of central importance to the XP theme of refactoring mercilessly and having confidence that the code continues working as you add more features.

Read Code the unit test first for more details.

The tests are also of central importance to the XP theme of refactoring mercilessly and having confidence that the code continues working as you add more features.

Read Code the unit test first for more details.

*Acceptance* tests are the ones that are implementation-independent, and XP has precious little to say about them.

Actually, it is fundamental to the methodology. According to extremeprogramming.org: Quality assurance (QA) is an essential part of the XP process. On some projects QA is done by a separate group, while on others QA will be an integrated into the development team itself. In either case XP requires development to have much closer relationship with QA.

There's a whole page on the subject here that suggest "precious little" isn't accurate.

*Acceptance* tests are the ones that are implementation-independent, and XP has precious little to say about them.

Actually, it is fundamental to the methodology. According to extremeprogramming.org: Quality assurance (QA) is an essential part of the XP process. On some projects QA is done by a separate group, while on others QA will be an integrated into the development team itself. In either case XP requires development to have much closer relationship with QA.

There's a whole page on the subject here that suggest "precious little" isn't accurate.

So, you're saying that in an instance where you are unsure of who your customer is, or what they want, then XP doesn't make sense, and traditional methodologies are more effective?

One of the requirements of XP is that the customer is on-site, so if you don't even know who the customer is you can't do XP. If you don't even know who your customer is no methodology will be effective.

What about instances where what the customer wants changes over time (new business strategy; new tactical goals; change in company emphasis) - how well does XP deal with those cases?

That's one of the main points of XP. What the customer wants always changes over time. XP deals with that by working in short (three-week) iterations instead of trying to figure the whole thing out up front. Every iteration the customer can completely change their mind about what they want.

Please check out XProgramming.com and ExtremeProgramming.org. You'll get a much better idea of what it's about from those sites than you will from me or from a short article.

Also get this book written by one of the pioneers of extreme programming (which has been around for 5 years BTW): Extreme Programming Explained: Embrace Change by Kent Beck.

• I read it, and it taught me:
• XP isn't prototyping. Its VERY disciplined.
• XP isn't any easier. Just more effective.
• XP is about keeping it as simple as necessary.
• XP still has requirements, unit tests and intregration tests. In fact they're essential.
• XP provides a framework to constantly learn, constantly change, constantly test... with confidence.
• XP appears to manage risk extremely well. Constant tracking, contant testing and always doing the most important things first make your software very close to releasable.

Actually, XP has a whole section on design. You can see in the rules that you do indead have design sessions and use CRC cards to actively communicate in them.

XP is a software development methodology. Check out XProgramming.com or ExtremeProgramming.org for more information.
j

"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."

Extreme Programming. The extreme programming (XP) methodology grew out of a Smalltalk project 3-4 years ago. The founder of extreme programming, Kent Beck, advocates Smalltalk as the most productive language for XP, as does Ron Jeffries, the author of the Extreme Programming Installed book.

Refactoring. The term "refactoring" has become popular in the last few years, due in large part to the work done on the Refactoring Browser for Smalltalk by John Brant and Don Roberts. (Martin Fowler's book on Refactoring includes a section on the Refactoring Browser.) The Refactoring Browser lets you perform automated behavior-preserving code refactorings, such as abstracting references to an instance variable, pushing a method up into its superclass, etc. (There have also been some refactoring tools written for Java, but the nature of the Java language will make it difficult to create a tool as powerful as the Refactoring Browser for Smalltalk.)

IDE's (Integrated Development Environments). Smalltalk has generally been considered a leader in this area, with its integrated code browsers, the ability to reliably look up all senders or implementors of a method, etc. (There is the occasional effort in other languages to catch up in this area, such as VisualAge Java with its integrated browsers, but VA/Java was also written in Smalltalk.) Also, to shamelessy toot my own horn for a minute, I've created an object-oriented "stacking" code browser for Squeak/Smalltalk called Whisker. I used Smalltalk to create this because the IDE supports this sort of experimentation well.

So, to claim that Smalltalk is somehow dead or obsolete is obviously false. True, it doesn't have the marketing hype (and market penetration) that Java does, but then, what else does? :-)

(Also, I still consider the language features of Smalltalk to be more technically "advanced" than those of Java. My personal hunch is that if you conducted a random poll of developers with *significant* experience with both languages (say, a minimum of 1 year full-time experience with each), probably 90-98% would agree with this. Of course, the same is probably true of Scheme vs. Java, or CLOS vs. Java, etc.)

Anyway, Smalltalk is obviously not the answer to all programming problems. (I wouldn't use it to write a device driver, for example.) But it is still one of the best (if not *the* best) options for many larger programming problems.

here and here

It is a combination of best practices, many of which will seem counterintutitive to we children of the "Mythical Man-Month," but which I have found to be remarkably powerful when used in combination.

Pair programming, combined with group ownership of code, combined with incremental design, combined with constant unit testing (writing tests hand-and-hand with code), combined with constant refactoring, combined with a 40-hour work week (really), and a host of other practices that, working together, seem to make a difference in significant development projects.

There is a wonderful series of books on this subject, authored by Kent Beck and others. You can find more at this web site.

It sounds like you now have a methodology that works for you (which is more important, IMHO, than using a community backed methodology), but have you tried XP? If it ends up being an iterative, feature diven development process, then you've succeeded.

However, pretty much every day, someone stupid would destroy her code under the guise of XP's constant state of refactoring.

Do you mean they broke its design, its style, or its functionality?

If you're referring to the design, then it is possible that your girlfriend is from the "old skool" of OOP -- overdesign everything and make everything conform to a particular arbitrary set of rules.

I don't mean that to sound insulting -- I used to be the same way. My coworkers changing my code was a constant annoyance because they would stomp all over my little flower garden. In retrospect, however, many of the changes that were made were good -- very simple, very clean. I was determined that good code should be uber general.

If you are referring to the coding styles and such -- that means that the team wasn't doing XP, because XP involves a coding standard. When I first saw that having a coding standard was one of the XP practices, I thought it odd and overly specific. But it is necessary to fit in with the XP practice of "collective ownership" of all code.

If they broke the functionality... well, then why wasn't there a unit test written? The avid unit testing of XP is one of the most visibly enjoyable aspects of the methodology. Traditionally, writing regression tests is a burden.

Beck and others have noticed how much better/faster/more confidently code can be developed if the unit tests are written before the units are implemented. You then implement until all the tests pass, and then you're done.

However, even if you're doing test-first programming like that, breakage will occasionally occur. But when things do break, you have to try to figure out (and write!) a test that could've ensured that the breakage wouldn't have happened. Eventually, (or so I've heard), you learn how to test well enough that you don't have this problem nearly ever.

Remember what ol' Kent Beck says about XP: "80% of the benefit comes from following the last 20% of the practices". In other words, if you are doing nine out of the twelve practices, you're probably only seeing 20% of the benefit. As soon as you plug in those last three is as soon as you'll see the biggest benefit of the methodology.

Of course, my diagnosis could've been completely wrong here -- I'm just taking some guesses.

- Dr. Foo Barson

I have to strongly disagree too. For the argument against commenting see Extreme Programming. If you can't understand your code without comments, REWRITE THE CODE AND ADD UNIT TESTS. I can't emphasise this enough. If the code is obscure the chances the code is bad or the variable names not descriptive or the design is poor. I'm not saying don't use comments. I'm just saying only comment what is necessary, but try fixing the code first instead of applying the band-aid of comments.

OK. With all due respect to its creators and proponents, I think this XP meme has just gotten out of hand. Even some of XP's most ardent supporters admit, in moments of much-appreciated honesty, that its value depends on a certain set of assumptions about project type, size and environment. Check out this article for an example.

XP uses iteration as a central theme. Iteration is great. I've hardly ever seen a program that wasn't significantly better on the second try than the first. Many older methodologies are based more on decomposition as a central theme...and you know what? Decomposition is great too! Divide and conquer, oh yeah. These are both incredibly useful tools which should be considered to complement rather than compete with one another. Any experienced programmer knows to use both, instead of being seduced by the abstract simplicity of methodologies based on only one.

I see it as an issue of "step size". XP and other iteration-oriented methodologies work best in systems where functionality can be added in small increments without requiring deep structural changes every time. A very large class of programming tasks, including GUIs, meets this requirement. XP tends to fall down, though, in cases where a huge number of things all have to work in concert to get any positive results at all. OS kernels come to mind. Decomposition should be the first tool you reach for in those cases. Maybe you can apply XP or other iteration techniques once you've broken things down, but there's no way around the fact that you have to break them down first.

Another difference is that XP is experiential and interactive, while other methodologies attempt to be more predictive. We all know the problem of trying to predict the unpredictable. However, prediction is not entirely without value. A thorough familiarity with the problem domain, combined with some elementary application of statistical principles, can yield predictions that are startlingly accurate for most projects. Those predictions can be used to achieve near-optimal resource allocations throughout the life of the project, instead of keeping "excess capacity" available for the project's peaks and troughs. Much of standard methodology is about making such predictions as accurate as possible. Nobody expects them to be perfect, but the better they are the saner life will be - not only for managers and customers but also for developers who won't have to put up with absurd expectations during an extended "crunch time" at the end of the project when everything they punted on comes back to haunt them.

I guess what I'm saying is that XP is half a solution. It's great, get the word out by all means, but adopting XP will not solve all "software sucks" problems and in some cases it will make things worse. If you know anything about horizon effects and hill-climbing problems from AI, you should know the dangers of incrementalism, and XP is an incremental approach.