Code And Fix

CodeAndFix - one year of slamming code, five years of debugging.

: "Do not mistake a CodeAndFix effort for a LightweightMethodologies effort."

A table contrasting them:

LightweightMethodologies CodeAndFix AcceptanceTests BetaTesting CodingStandards Whatever each programmer preferred to use that day. CommitmentSchedule But that was working yesterday ContinuousIntegration IntegrationHell (or maybe just COM) DesignByContract We ain't using Eiffel here... DontRepeatYourself CopyAndPasteProgramming FrequentReleases We can't show them that! FortyHourWeeks Drugs CollectiveCodeOwnership I can't fix this until Frank fixes that OnsiteCustomer Get out of my cube I'm working! PeerReview Get out of my cube I'm working! PlanningGame Just e-mail us a requirements document. (We have a system for this...) ReFactoring Don't touch that you might break it! UnitTest There's NotEnoughTime for that YouArentGonnaNeedIt YouMightNeedIt (see GoldPlating) SystemMetaphor The AnalysisDocument

Contributors: (mostly) PhlIp, JeffGrigg (just a little)

Ron deserves props for identifying my true realm of expertise!!! -- PhlIp

The methodology of choice for a RealProgrammer.

I'll amen this, LightweightMethodologies are nothing like CodeAndFix. However, sometimes I wonder if I wouldn't prefer CodeAndFix to an OverweightMethodology?!! -- RobertDiFalco

But then you'd CodeUnitTestFirst. Then you'd order someone to prioritize your feature list. Then you'd apply OAOO and RefactorMercilessly. Then...

Yep!

This page seems heavy on attitude and light on information. I understand the attitude on this page - I HaveThisAttitude? (see HaveThisPattern).

I never heard of CodeAndFix before - I heard of CodeAndTest, which makes a bit more sense. After all, fixing is coding. CodeAndFix is indeed one of the LightweightMethodologies! It's so light that the entire method fits into its name.

How can we discuss the goodness or badness of something like this without some reference to the context in which it is used? CodeAndTest works well for most beginners crafting a small system for their own personal use.

Most of the stuff in the right hand column far above has nothing to do with the development kernel consisting only of coding and testing. It has to do with unhelpful attitudes. Is there some value in keeping the two separate, I wonder? To what extend does an unhelpful attitude push developers to eschew practices that are neither coding nor testing?

When CodeAndTest fails of its own accord (not just because it happens to be the method of choice of developers with bad attitude), why does it fail? -- WaldenMathews

This page follows the CodeAndFix definition from the book RapidDevelopment. It is simply the easiest, most neophytic "process" there is: No Process.

So many people do it (even when they say they are doing something else) that it must be documented and understood somewhere. -- PCP

CodeAndFix sounds like a term that was made up by a marketing person, perhaps one that was selling tools for BigDesignUpFront, who wanted something that every customer could recognize in themselves and also feel guilty about.

CodeAndFix is not a methodology that might someday make sense. It is defined (per RapidDevelopment) as the most primitive and least productive methodology possible. Therefore anything you, an engineer who knows how not to f*** up projects, can think to do will make sense, and won't be CodeAndFix. I really doubt you'd abandon UserStories, FrequentReleases or DesignByContract just because of the language or time frame involved.

Further, you should hope that your 1-week of effort might someday be reused or extended or versioned, in which case you'd want it to be presentable, right?

About AspUnit, following the rule "don't test getters and setters", I disregard testing the outermost "skin". I push all the biz logic up into a JavaScript* file, and then I include that into both the skin.asp file and the test.asp file. The latter just calls all the functions and streams each test's title out into the page. Come to think of it, the project I have in mind lasted about a week ;-)

This is server-side JavaScript. Don't gross me out.

-- PhilipCraigPlumlee