Code And Fix

-- ChristopheThibaut

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...


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 ;-)

-- PhilipCraigPlumlee

View edit of November 9, 2014 or FindPage with title or text search