>Highly skilled development talent takes performance and resource >utilization into consideration during design, development, turning and >testing.
Agreed, but only to the degree merited in the circumstances. Highly skilled development talent and management also know where best to allocate their precious efforts, in business priority order, and when to stop (or at least pause) in their efforts lest they incur costs without adequate returns. >Based on what was described, 0c4 and 0c7 abends were eliminated by grossly >over allocating tables to eliminate memory overlay. >By my experience, this does not sound like highly skilled talent, >regardless of expense. Quite possibly! But that only reinforces my point. Perhaps the organization underpaid (in the circumstances) for talent and thus obtained a level of talent highly correlated to that underpayment. There's also often some degree of functional risk in performance optimization efforts regardless of expertise, and that risk has a cost, too. Anyway, I have no clue what the "best" answer is from afar in these particular circumstances, and no one else afar should either. :-) Maybe this organization's development management made exactly the correct call in their particular circumstances, and maybe they didn't. The former is at least plausible, and we cannot and should not reflexively assume the latter. By the way, the fact you're paying $X million per year for anything in IT now doesn't mean that you'll pay twice $X million if this particular development team doesn't do what you think they ought to do and what you think they could do, even if they caused a doubling of peak "MIPS." Isn't *anybody* familiar with basic cost concepts such as fixed costs and marginal costs? Those concepts shouldn't be too hard to grasp. Airlines, for example, certainly understand those concepts. That's why they generally push as hard as they can to *increase* fleet utilization and passenger load factors, to keep their airplanes moving and carrying as many fare-paying passengers as possible every possible minute they can as long as they can generate a profit on each trip. Will payroll for the operations team increase if the development team doesn't (or cannot) reduce peak 4HRA "MIPS" by XX? That'd be nice if you're part of the operations team, but sadly, no. Generally speaking that particular part of the IT budget won't change. The development team cannot materially affect those fixed costs, in general, as an example. These really aren't hard concepts to grasp, I hope. Some of us occasionally go buy a beer. Others of us spend 10 hours per bar outing searching for coupons to get a 10% discount on the same beers, perhaps in vain. Which approach is best if you want a beer? I don't know, and you don't know either. "It depends." How valuable is your time? How valuable is that hypothetical 10% discount to you? Do you derive value from the discount hunt itself, and the longer the hunt the more value you derive? If your date sees you present a coupon for your beer, do you scare your date off, and what's that cost? Does that 10% discount require adding your name to a mailing list, adding more junk mail to your inbox? What's that cost? Should you buy your beer at a bar at all? Perhaps the best answer in your circumstances is you should never end up at the bar -- you should just keep hunting for coupons. :-) Or perhaps you should just go have a beer, at a bar, and enjoy yourself in your profligacy. Allegedly there was a certain IT multi-billionaire who was/is rather infamously well known for spending a considerable amount of time in the supermarket checkout line digging through his wallet for a couple 20 cent off coupons to present to the cashier, considerably delaying those behind him in line. The people waiting for him to dig out his coupons thought he was nuts. They were probably right. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
