CSE Senior Design I Deploying Productivity Tools …a killer silver bullet Instructor: Mike O’Dell The slides in this presentation are derived from materials in the textbook used for CSE 4316/4317, Rapid Development: Taming Wild Software Schedules, by Steve McConnell. 1 What are Productivity Tools? Tools that you use in product development that can significantly change the way you work E.g., 4GLs, visual programming languages, code generators, advanced IDE’s, etc. Any tool/toolset that offers (claims) dramatic reductions in work and dramatic improvements in schedule NOT simply a specific brand of compiler, linker, editor, IDE, etc. that works better than another brand. 2 1 Deployment Considerations FACT: These tools are often “bleeding edge” technologies, and are fraught with risk! Successful deployment depends on recognizing 3 harsh realities: these tools seldom produce the schedule savings that are promised the learning curve lowers productivity tools that may be discredited as “old and tired” by “latest and greatest” proponents can often produce significant savings 3 1 Ineffective Tool Use (C.S. 15-1) What went wrong at the start? What were the “hopes” of the developers based on Blaze-O-Matic? What would you have done? What tools do you use in your job (if you have one)? Have you had any similar experiences with “latest and greatest” tools? 4 1 The Essence of Software Software programs are becoming more complex, more detailed, more precise… not less. The hard part of any programming effort is the process of thinking through the thousands of rules, procedures, etc. that the program must implement (Fred Brooks, 1987) The easy part of software development is implementing the rules, etc. in a programming language. Most productivity tools address this latter task, but not the former. 5 1 Tools and Paradigm Shifts To be effective, a productivity tool must strike at the essence of what makes software development difficult… the thought process of problem solving Examples: the change from low-level programming languages to high-level languages allowed us to conceptualize a solution at a higher (more human) level the use of visual-programming tools can help us simplify the thought processes associated with the details of developing GUI/windowing environments 6 1 Areas of Special Applicability Some kinds of software projects are better supported by good productivity tools than others DBMS-Oriented Apps: schema generators, report generators, query generators, etc. Small, Custom Apps: designs well-understood, limited functionality, “standard” features Rapid Prototyping: quick turn-around, throwaway, end user-oriented feature set (look and feel) 7 1 In general… Current productivity enhancement tools help most in the area of software construction The smaller and simpler a development project, the greater the percent of total lifecycle time spent in the construction phase Therefore: today’s productivity enhancement tools are most valuable on small, simple, clearly-defined products. 8 1 Overview Summary Small projects and specific types of products may benefit from the “latest and greatest, rev. 1, automated, year-saving, Blaze-O-Matic” tools Productivity enhancement tools are neither necessary or sufficient for achieving rapid development! (Glass, 1993) However, the best projects (Hertzel, 1993) all rely on basic principles, such as: strong teamwork good communications good organization and management solid and effective project controls 9 1 Just remember… There is no Silver Bullet! 10 1 Productivity Enhancement Tool Deployment Strategy Use them to achieve a long-term, strategic advantage… NOT to get a quick win on your schedule Your deployment strategy should include: early identification timely and accurate evaluation rapid deployment if tool is effective non-deployment if tool is ineffective continued reliance on older, proven tools 11 1 Tool Acquisition Plan If you wait until a tool/toolset is needed to acquire and deploy it, you’ve waited too long! Make tool acquisition an ongoing activity: set up a tools group in your organization stay up with what’s going on in tools technology, at your competition, etc. evaluate the tools that will benefit your project the most (consider a pilot project) coordinate and disseminate within your organization 12 1 Tool Selection Criteria Estimated Gain: develop your own conservative estimate for your project(s). Vendor Stability: how long have they been around? what do others say? will they be around next year? Quality: test it thoroughly during your evaluation Maturity: Version 1, or Version 1+? Consider the “version 3 rule” 13 1 Tool Selection Criteria Training Time: impact of learning curve? who in your organization can train others? Applicability: is this a “design-to-tools” effort, will it really help or is it a forcefit? Compatibility: does it work/work well with other tools/systems that you use? Growth Envelope: does the tool support the direction that expect, or might want, your product to go? 14 1 When to Deploy a New Tool Length of Project A Length of Project B PRODUCTIVITY Nominal productivity, or level before new tool is introduced Productivity gained Productivity lost Initial productivity after new tool was introduced (drop due to learning curve) TIME 15 1 Training for a New Tool Rule of Thumb: the more powerful a new tool, the more difficult and timeconsuming it will be to use effectively e.g., using a new, high-capacity backhoe for commuting to and from the ditch you’re digging with a shovel Don’t underestimate the difficulty of getting the real benefits of a new tool 16 1 Silver Bullets The biggest risk associated with deployment of new tools is the silver-bullet syndrome! we all really, really want to believe in magic! Hard, Cold Fact: we should dismiss most claims of massive productivity enhancements and schedule improvements out of hand. 17 1 Identifying Silver Bullets Fourth Generation Languages (4GLs) incremental gains, not revolutionary last really large gain was on move from assembler to 3GLs CASE Tools potentially valuable in database-intensive environments in most organizations, CASE tools are just used as high-end tools for creating design diagrams. 18 1 Identifying Silver Bullets Rapid Application Development (RAD) collection of IS-oriented practices can work well in some environments typically NOT good for any type of unique software (e.g., custom, system, shrink-wrap) Automatic Programming the real problem is not the programming, it’s the conceptualization of the problem and its solution a long-term promise… not kept! 19 1 Identifying Silver Bullets Object-Oriented Programming powerful, in terms of maintainability and reusability has fallen well short of the promises of naturalness and ease of use… and consequently the productivity gains in rapid development projects Bottom Line: there are no silver bullets! 20 1 Effective Tool Use (C.S. 15-2) What’s different about this approach, form that in C.S. 15-1? What are some of your personal experiences with use of effective and/or ineffective productivity enhancement tools? How can/will any of this be applied to your Superior Designs, Inc. projects? 21 1 Summary: Productivity Tools Productivity tools seldom produce the results claimed by their suppliers/vendors Learning to use a new productivity tool or practice initially lowers productivity Deployment of productivity tools should be part of long-term tools strategy, not quick fix or a solution to a short-term issue 22