|
|
Avoiding Over and Under Design The question of how much design to do up-front on a project is an engaging one. Too much design often results in overkill, complexity, and wasted work. Too little design results in insufficient system structures that require rework, additional complexity, and wasted effort. How can we know what the right balance is? Alan Shalloway shows how to use the advice from Design Patterns coupled with the attitude of not building what you don't need from Agile. The trick is in discovering what you don't know, how it may affect you, and then how to isolate these risks in your code in a simple manner. Alan describes the essence of emergent design–that is, starting with a simple design and letting it evolve as the requirements evolve. He also demonstrates how to refactor to better designs and how this is different from refactoring bad code.
|
Alan Shalloway, Net Objectives
|
|
|
Prefactoring: Extreme Abstraction, Extreme Separation, and Extreme Readability Developers often run into the same issues on every project. As the software is created, design problems start to creep in-causing maintenance releases with no new features, project delays, and worse. While some of these problems can be resolved by simple refactoring, others can be fixed only by a complex code restructuring effort. But you can avoid most these issues in the first place with prefactoring-using your experiences in previous projects and the experiences of others to help in early detection of common design errors and problems.
|
Ken Pugh, Net Objectives
|
|
|
Mobile App Development: It's Harder Than You Think You're thinking of creating a mobile application to take advantage of the sky-rocketing potential of mobile phones and other smart devices. Serious and critical choices must be made. Which platforms and technologies do you support? Are web-based applications the best approach? What sort of testing will you need-from whom, when, and how much will it cost? Do you want to create applications that take advantage of the mobile platforms’ capabilities such as location-aware features? Since there are at least fifteen major platforms, including several that use disparate semi-proprietary programming languages, making the right decisions early is critical. Wrong decisions will result in wasted time, effort, and money and increase the likelihood of failure.
|
Julian Harty, ebay, Inc.
|
|
|
Coding for Keeps: How to Write a Function Functions are the basic building blocks of computer systems. Object-oriented classes are a way of packaging functions with shared data. Inheritance and polymorphism essentially are all about finding the right function. It’s all about functions! Get the picture? Chuck Allison explains that functions come in many varieties: static functions, polymorphic functions, generic functions, nested functions, higher-order functions, generator (aka stream) functions, coroutines, function closures, delegates, etc. Functions can handle arguments in different ways: by value, by result, by reference, by sharing, and by need, to name a few. Do you know how and when to use which? Functions should also be resource-friendly and robust should something hit the proverbial fan. Are your functions error-safe? Reusable? Maintainable? Do you know-really know-how to write a function? Come join Chuck and find out.
|
Chuck Allison, Utah Valley University
|
|
|
Testing for Web Accessibility Because 10% to 20% of the general population has disabilities that can impact their ability to use software, systems should be developed to accommodate their needs. Even though web accessibility requirements are included in many development projects, they are often not fully understood and verified during testing. Join David Leistner as he examines the Web Accessibility Initiative and Section 508 of the Rehabilitation Act. First, David explains what web accessibility is, its importance, and who it affects. Next, he introduces the types of technology available for testing compliance and shows how to use analysis tools in testing for accessibility. Gain an understanding of the issues and alternatives with web accessibility development and ways that testers can ensure that people with disabilities can access the web and Internet-access they deserve and, in some cases, are entitled by law to have.
|
David Leistner, National Archives and Records Administration
|
|
|
Questioning Measurement When we consciously measure something, we try to measure precisely and often assume that our measurements are accurate and useful. However, software development and testing activities are not subject to the same kinds of quantitative measurements and precise predictions we find in physics. Instead, our work is like the social sciences, in which complex interactions between people and systems make measurement difficult and precise prediction impossible. Michael Bolton argues that all is not lost. It is possible and surprisingly straightforward to measure development and testing accurately and usefully–even if not precisely. You can measure how much time is spent on test design and execution compared with time spent on interruptions, track coverage obtained for each product area, and more.
|
Michael Bolton, DevelopSense
|
|
|
Refactoring: What You Need to Do It Right As certain as evolving requirements lead to code changes, code changes lead to code degradation. Therefore, code refactoring is critical to the long-term viability of all software products. Kevin Sawicki shares tips and tricks for refactoring to help developers identify code that needs refactoring, preserve the correct code history during refactoring sessions, and ensure that appropriate unit tests cover the refactored code. Kevin demonstrates the Eclipse open-source frameworks and Java-based tools, including EMMA for code coverage analysis and JUnit for unit testing. These tools not only make code refactoring less painful, they also empower developers to constantly improve their code through relentless refactoring. Kevin outlines a step-by-step process to find refactoring candidates, perform the refactorings in an isolated code branch, and collaborate with other developers to review the refactored code.
|
Kevin Sawicki, Perforce Software
|
|
|
Making Agile Work in Highly Regulated Environments Highly regulated industries-avionics suppliers, medical device companies, and pharmaceutical manufacturers-must meet rigorous quality standards to ensure their products are not a danger to the general public. Although compliance has traditionally been achieved with heavyweight waterfall or V-model development methodologies, you can implement agile-or lean-agile-development practices that adhere to standards-based regulations while reducing the risk and improving software quality and reliability. Colin Doyle identifies the constraints that agile and lean-agile software development approaches must address: traceability to clearly defined requirements, formal risk analysis and mitigation, and separation of roles between development and validation.
|
Colin Doyle, MKS, Inc.
|
|
|
Are You a Develoment Professional? The past decade brought the rise of the Agile movement, which split into two parts-Scrum, dominating the project management practices of agile; and XP, dominating its technical practices. Of the two, Scrum has had the greater impact as the industry quickly grasped its team-based benefits. During the rapid adoption of Scrum, technical practices were not being ignored. Programmers were gradually adopting XP and related development practices. In 2008, the Software Craftsmanship movement was founded as evidenced by the Manifesto for Software Craftsmanship. Driven by the tremendous improvement in programming accuracy and style that comes from agile principles and practices, this movement strives to "raise the bar" of professionalism and quality in the software industry. We can-and must-choose the disciplines, attitudes, and practices that comprise our profession, and then we must live within those bounds.
|
Robert Martin, Object Mentor
|
|
|
The Joy of Legacy Code Even though the code may have been written only five years ago, there it is-a sprawling unintelligible mess that nobody wants to touch. For most people and teams, this reality is a cause for fear and loathing-something we want to sweep under the rug. We can, however, choose to see “bad” code as a challenge to restructure and refactor into a maintainable design that serves the business for years to come. Although legacy code presents many constraints on design choices, it offers the opportunity for incremental improvement. Michael Feathers shows you how to practice design within the boundaries of what some see as unintelligible code and explains ways to make the improvement process manageable. See how you can escape the fear that holds you back from productive action. Find out how to start with what you have now and progress toward a structure that supports the work at hand and immediately adds value.
|
Michael Feathers, Object Mentor
|
