Seymour Cray, the designer of the Cray supercomputers, says that he does not attempt to exceed engineering limits in more than two areas at a time because the risk of failure is too high (Gilb 1988). Many software projects could learn a lesson from Cray. If your project strains the limits of computer science by requiring the creation of new algorithms or new computing practices, you’re not doing software development; you’re doing software research. Software-development schedules are reasonably predictable; software research schedules are not even theoretically predictable.\r\n\r\nIf you have product goals that push the state of the art–algorithms, speed, memory usage, and so on–you should expect great uncertainty in your scheduling. If you’re pushing the state of the art and you have any other weaknesses in your project–personnel shortages, personnel weaknesses, vague requirements, unstable interfaces with outside contractors–you can throw predictable scheduling out the window. If you want to advance the state of the art, by all means, do it. But don’t expect to do it rapidly!\”\r\n\r\nThe author Steven C. McConnell’s book points a fact that lot’s of developers fall into, when a specific project does not care for true innovation. I see this quest for innovation achievement sometimes a consequence of need for extra motivation. A bit like development gold-plating. Clients do not understand it, even more when that makes failing schedules. Most of the times the subject is so tech, that the developer just won’t waste time explaining it to the project manager or the client. Worst when the client does see no visual or procedural impact on the final result.\r\n\r\nGoogle (to name a known one) has a nice approach, allowing developers to dedicate attention to personal projects, on a percentage of work time a week.\r\n\r\nBack to #32, in fact in true innovation projects, scheduling, that clients and managers like and need, can be hard to define and gather consensus.