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