- one year of slamming code, five years of debugging.
A table contrasting them:
- "Do not mistake a CodeAndFix effort for a LightweightMethodologies effort."
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...
FrequentReleases We can't show them that!
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
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
This page seems heavy on attitude and light on information. I understand the attitude on this page - I HaveThisAttitude?
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?
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
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.
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
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?
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 ;-)