In standard component development, the job of the framework developer is
just to provide a set of components for the developers to use as they see ?¬?t. Picture a
na?±??ve??”or progressive??”coach offering his team a selection of balls, goalposts, and a
goodly supply of the apparently indispensable traf?¬?c cones, and letting them get on
with things. When a new, more experienced??”or authoritarian??”coach appears, she
runs things very differently: she leads the players through a series of drills, setting out
the equipment to be used for each. In other words, she is saying to them, ???I don??™t just
have the stuff you need; I really know how you should use it to get the best results???.
Obviously, this approach demands less intelligence of the team members, but more
obedience. This perhaps explains why it is not a universally popular approach among
framework users: we developers are not exactly renowned for our subservience, or for
taking lightly any perceived slights on our ability. It is, in fact, an approach better
suited for use by factory workers, drones, machines??”or generators.Agood generator
might at best be described as smart, but it could never be accused of intelligence: the
ability to come up with good, new, solutions to new classes of problems. It is however
totally obedient and predictable, and copes remarkably well with the lack of
intellectual stimulus in its working day.
Pages:
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609