Dear fellow mongers. Please refer to perl in your response to this thread, with subject "maintenance of large perl code bases"
One ounce of perl specific advice, in this content, is worth a ton of generic software engineering, which we can all read in other forums. e.g. Does anyone have a useful "Perl coding standards" document they would be willing to share. I have seen a few, but they were not useful. Etc. Hopefully helpfully yours, Steve -- Steven Tolkin [EMAIL PROTECTED] 617-563-0516 Fidelity Investments 82 Devonshire St. V8D Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates. > -----Original Message----- > From: Charles Reitzel [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 13, 2002 1:20 PM > To: Joe Johnston > Cc: [EMAIL PROTECTED] > Subject: Re: [Boston.pm] maintenance of large perl code bases > > > Agreed, most professional and open source software is very > much a group > process. But, as J. Scott says, there often is a > communication gap between > engineers and management. I just wouldn't attribute it to > IQ. Nor would I > use it as an excuse for poor quality. The facts are a) it is > all about > economics (do you work for free?) and b) poor quality *costs* > time. It > doesn't save time in any project - large or small. Who hasn't seen a > project slip for weeks because a product won't stabilize in > QA? I call it > the death march. > > So, as you say Joe, process is important. Of course, the > product is *more* > important. So where do you draw the line? > > That's easy. If an "overhead" task doesn't show a benefit in > the current > or next development cycle. Don't do it. There is just too much > uncertainty in the business environment to plan any further out. But > coding is only 40% of the cycle, so everything I have > mentioned pays in the > *current* cycle, and pays big time. It is a 90/10 rule: 10% > overhead that > yields 90% productivity improvement for the group. > > The same rule applies to refactoring tasks and shared library > development. Often, these tasks can and should be done > without involving > anyone from the business. After all, you are just organizing > your own work > for near term requirements. That said, if you choose such > stealth projects > well, reuse can raise the productivity factor on subsequent releases. > > take it easy, > Charlie > > > At 12:13 PM 3/13/2002 -0500, Joe Johnston wrote: > >At the risk of beating a dead horse (South Park anyone?), I'd like > >to make two points about coding for large projects. > > > >1) Normally, lots of people are involved. The success of the project > > doesn't rest entirely on the coders, but management as > well. Software > > Engineer can't be done in a vacuum. Management must want > the results > > that come from managing the engineering process. You may > well ask does > > this happen in the "real world?" As a matter of fact it > does, but rarely. > > Check out this example: > > http://www.fastcompany.com/online/06/writestuff.html > > > > Like Grant, I don't buy the "l33t coder" argument. Sure, > some coders > > are faster and more productive than others -- I allow that. > > Unfortunately, > > engineering is a team effort. When coding is equated to a > > widget machine (e.g.. "the more widgets produced in less > time = more > >profit"), > > engineering practices are irrelevant. There is more to producing > > software than v1.0. Engineer is all about following the > > rules and getting there together as a team. The dividends > > for managing the SW engineering process come later in the product > > life cycle and aren't as visible during the initial build phase > > (as a counter-example, look at Netscape -- code so tangled that > > after v4.0, it had to be rebuilt from the ground up). Coders that > > need their egos stroked can surfer alt.binaries.*. The > more coding > > is treated like an industrial art, the better I'll like it. > > > >2) Small projects don't require the same amount of > attention, especially > > if the team consists only of one person. It this case, > the sky's the > > limit, Tex. If you don't want to eschew for() loops for > map and grep, > > go for it. If you want to use Acme::Bleach for > production code, Amen > > brother! Of course, I also assume you'll be doing the > maintenance too. :-) > > > > > >-- > >---------------- > >Joe Johnston - http://taskboy.com > >"A closed mouth gathers no feet." >
