development
Conference Presentations
|
Applying Lean Production to Software Development: A Worldview Lean production has made it possible for many industries to develop products faster and more profitably, building a loyal customer base while lowering business risk. Now, Lean has proven it can do the same for software development-and do so better than any development approach to date. Lean is more than a management system, method, tool, or environment; the areas where software methodologies normally focus. Lean is a worldview-a way of thinking that fundamentally changes and humanizes industry. The power of Lean is in the goals it leads us to pursue and the ways in which we coordinate our work. Therefore, Lean allows us to continue using many of our current software techniques. James Sutton returns to the beginnings of Lean, as conceived in the mind of W. Edwards Deming, and moves forward in time to compare and contrast Lean with agile development. |
James Sutton, Lockheed Martin
|
|
|
Creating Habitable Code A major challenge for software organizations is to create software that can continue to adapt and change over time-a codebase the team can live with "forever." Jeffrey Fredrick and Paul Julius review the concepts and features of CruiseControl, a popular continuous integration tool that provides an architecture for habitable code. CruiseControl is an open source success story, contributed to by more than 200 different developers and downloaded more than 400,000 times. For developers who are tired of brittle code that often must be discarded and rewritten instead of reused, CruiseControl provides valuable lessons and a design that encourages reuse. Jeffrey and Paul discuss inversion of control, dependency injection, separation of concerns, and the role of a project architect in creating habitable code. Although the code examples will be in Java, the principles are language independent. |
Jeffrey Fredrick, Independent Consultant
|
|
|
Successful Teams are TDD Teams Test-Driven Development (TDD) is the practice of writing a test before writing code that implements the tested behavior, thus finding defects earlier. Rob Myers explains the two basic types of TDD: the original unit-level approach used mostly by developers, and the agile-inspired Acceptance-Test Driven Development (ATDD) which involves the entire team. Rob has experienced various difficulties in adopting TDD: developers who don't spend a few extra moments to look for and clean up a new bit of code duplication; inexperienced coaches who confuse the developer-style TDD with the team ATDD; and waffling over the use of TDD, which limits its effectiveness. The resistance (overt or subtle) to these practices that can help developers' succeed is deeply rooted in our brains and our cultures. |
Rob Myers, Agile Institute
|
|
|
The Many Styles of Pair Programming Joining an agile team can be very challenging-new programming styles, new coding standards, new check-in requirements, new leadership styles, and more. Adding pair programming to the mix can be "the straw that broke the camel's back" or it can be key to team empowerment. Paul Julius has been a dedicated pair programmer since 1999, working on many projects with 100 percent pairing. Paul has distilled a set of positive and negative patterns that can develop when teams attempt pair programming. He begins by discussing the most frequent objections to pairing and then outlines why pair programmers deliver better applications. Paul demonstrates the techniques and skills you-or members of your team-need to become a successful pair programmer. |
Paul Julius, Willowbark Consulting
|
|
|
Defining Software Quality "Quality" is one of the most misunderstood and elusive aspects of system development. Ask five people to define quality and you'll probably get five different answers. Although everyone thinks he knows what it is, very few can really define it in context. High quality software doesn't just happen-quality must be built in from the start. In this highly interactive presentation, Tom Staab defines quality and explains why quality planning is important. Join in the discussion about where most defects are injected into software, how to establish meaningful quality metrics, ways to communicate results to management in language they understand, and how to calculate the return-on-investment that can be expected from quality improvement activities. Quality must be defined in a project's specific context, quantified at the beginning of the project, and measured throughout the development lifecycle. |
Thomas Staab, Windridge International LLC
|
|
|
How to Survive a Software Rewrite Beware of the hidden sirens in your rewrite project. They will sing the words you want to hear--that the project is easy to complete. Don't be fooled: Sirens are mythological, but the lure of rewrite projects can be quite real. Rewrite may seem a simple task, but it isn't until you're deep into it that you'll start to realize the true nature of the project. In this article, James Shore offers some words of wisdom (and warning) to help guide your rewrite project in the right direction. |
James Shore
July 31, 2009 |
|
 |
Avoiding Half-baked Discovery It can be difficult to explain to your customer why cutting half of the features doesn't cut half of the time and cost. Every software project has fixed costs that often get overlooked in project planning—setting up development environments, ramp-up, building frameworks, and setting up configuration management to name a few. Read on for some ideas on how you can position this with your customer. |
|
 |
The Ghost of a Codebase Past Revisiting your old code can be an enlightening experience. Pete Goodliffe encourages us to look back at our old code to see how our technique has improved, how our programming skills have progressed, and what we can learn from it. |
|
 |
Encapsulation and Vampires Encapsulation is more than just using the "private" keyword when defining a class. You need a boundary that keeps the vampires out. |
|
|
A Gram of Prevention Following an "I-click-therefore-I-Program" methodology does not lead to quality software. Good code can and should evolve from clear, up-front descriptions of the solution to the problem at hand. |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.