Deploying Productivity Tools …a killer silver bullet

1. Deploying Productivity Tools…a killer silver bullet 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. Instructor: Mike O’Dell

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

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

4. 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?

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

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

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

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

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

10. Just remember… There is no Silver Bullet!

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

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

13. 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”

14. 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 force-fit? • 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?

15. When to Deploy a New Tool Length of Project B Length of Project A Nominal productivity, or level before new tool is introduced Productivity gained Productivity lost PRODUCTIVITY Initial productivity after new tool was introduced (drop due to learning curve) TIME

16. Training for a New Tool • Rule of Thumb: the more powerful a new tool, the more difficult and time-consuming 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

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

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

19. 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!

20. 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!

21. 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?

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