begin quoting Chuck Esterbrook as of Mon, Dec 11, 2006 at 03:35:01PM -0800: > Shortly after learning about XP, I desired to start a movement called > MP for "Moderate Programming". > > At the very least, I could out-acronym my next interviewer. He says, > "Do you know XP?" and I say "Puh-lease. XP is so nine-months ago. > Everyone is doing MP. ... What? *You* don't know what MP is?" > (incredulous look on my face; uncomfortable look on his) > > LOL
/me laughs The logo could be a guy with a helmet and a truncheon.... > Another motivation is that--and I hesitate to say this because no one > has officially conferred authority to me nor did I collect hard, > scientific evidence (please don't burn me at the stake)--I don't think > extremes work well much of the time. When I find a solution to a real > life problem, that solution is usually a balancing act between > extremes. I've seen this in business, software and martial arts. > Ancient Greeks and Chinese used to write about this stuff--thousands > of years ago. When trying to transition from a bad habit to a good habit, extremes are often necessary... e.g., alcohol is fine, in moderation, but an alcoholic needs to go to the extreme of doing without. When learning to transition to "OOP", many procedural programmers need to go to the extreme of thinking of everything as an object; the real goal is to be able to adopt the moderate position, but there's a strong inclination to fall back to procedural -- or spaghetti -- habits. If they don't take the extreme approach, at least at first, they end up with code that is the worst of OO and procedural thinking. Then the OO people look at it and say "Oh, it sucks because it's basically procedural", and the procedural folks look at it and say "Oh, it sucks, because it has all that OO crap in it." > Getting back to software development, I want enough formalism to avoid > well known problems and enough flexibility to leverage my intelligence > and experience. Furthermore, that balance has to vary per project and > needs refinement over the course of the project. I know that's very > gray, but real projects are gray and vary immensely. Amen. > The processes that Gabe spelled out recently for code and design > reviews are good examples of MP. Amazon gets benefit with minimal > overhead and stress. If the processes start to fail in their purpose > for some reason, they can be adjusted. If developers feel burdened, > the processes can be streamlined. There's no sense in making them > anything other than "just right" for their set of variables. Flexibility as a watch-word? That's pretty extreme thinking, y'know. :) > Regarding unit tests, I have found them to be: > - great for standalone methods > - good for standalone classes > - not so great for OO frameworks.. When I start needing mock objects I > feel the ROI on writing test code plummets > > So I use them where I can get a good payoff and not elsewhere. That's MP. When the ROI on test code plummets, it's time to start writing (and running) the functional tests.... I find this increases the ROI on more automated testing/test code. When you have a situation where you *can't* (because of design, or schedule) use automated testing, it starts to look REALLY nice. And the more I run functional tests, the more I long for automated tests. The computer should do the tedious and boring tasks -- that's what it's best at! > So if MP becomes the next big thing, you heard it here first! > (Although more than likely, someone has already espoused this with > even the same term.) I'm told that the 2nd version of Beck's book on XP is far more relaxed; it has a more moderate tone. This sounds encouraging... > And now that I have branded common sense ideas already familiar to > many, it's time for me to cash in with some books and paid speaker > gigs! Early retirement, here I come! You need a movement. The MP movement. I should form a standards body to ratify your design to make it into a proper movement -- say, the CSPC (Common Sense Programming Consortium)? -- _ |\_ \| . o O ( Did I ever post project[-4]'s lessons learned to here? ) -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
