program selection system

The second great myth of software development training is the notion that most programming most of the time is on new code. In fact, most developers spend most of their time working on CRRAP: Code Requiring Remedial Attention Promptly. In this course, we’ll lay out the five basic patterns for bringing complex legacy code under perfectly tested control. If you’ve ever heard or said “Don’t touch that, you don’t know what it’s connected to,” this class is for you. Each pattern is illustrated with a complete real-world

This experience report outlines technical lessons learned over a several year period across several projects within an organisation which aggressively applied most of the agile practices with much success. The success, however, was not been achieved without challenges and lessons learned along the way. This paper outlines the interesting observations we made while trying to turn the agile dials to eleven. Our starting assumption when we began this journey several years ago was that productivity and quality were opposing forces; you had to trade one off against the other. However, after turning the dials to eleven, we now believe that you can much more of both than we previously thought possible. In fact, we believe that applying the practices outlined in this experience report allow both much higher quality and higher productivity than traditional development.

Abstract

Developer practices for traditional and agile Java development are well understood and documented. But dynamic languages—Groovy, Ruby, and others—change the ground rules. Many of the common practices, refactoring techniques, and design patterns we have been taught either no longer apply or should be applied differently and some new techniques also come into play. In this talk, techniques for agile development with dynamic languages are discussed. How should we apply design patterns? How should we better apply refactoring techniques? What new aspects do we need to think about?

What do masters of refactoring know that novices don’t?

In 2006 I stumbled upon an answer to that question. I was preparing numerous refactoring labs for use in Industrial Logic’s eLearning. Each lab features problem code and solution code. To produce the solution code, I’d refactor the problem code by applying sequences of low-level design transformations, like Extract Method, Move Method, Extract Class and Inline Method.

==== 90 words description - beginning =====

Using the analogy to code smells and their refactoring (Fowler, 2000), the tutorial introduces cultural smells, as well as refactoring activities, for cases in which agile software development is considered and adopted. The participants become familiar with patterns of cultural smells and appropriate refactoring activities, and are guided to check their fitness for their organizations as well as to develop new ones.

After 7 years of traditional IT delivery, Gap Inc. Direct decided to adopt Agile. This experience report discusses three key factors that contributed to our successful (and ongoing) Agile transformation: 1. Ambitious Pilot Project 2. Massive Investment in Continuous Integration 3. Rethinking our Assets

The instructors wish, when they were first learning test-driving, refactoring, and deep OO, that they had had a genuine side-by-side comparison between code Heaven and code Hell. Such an object lesson would have made the value and benefits of agile programming practices so much more plain, so much sooner. Alas for us, but hurray for you! In this clinic session you will be able to compare and work with two very different implementations of the same problem domain: one of them fabulously ugly, and the other of them — well — much closer to gorgeous.

Tale of Two Codebases

Success in object-oriented agile development is currently being achieved with a technique known as test driven development (TDD). In database development however, TDD practices are not wide-spread and development teams struggle with applying the TDD principles to the SQL language. This is a problem, because it leads to poorly tested code. In turn, not having the appropriate test cases, makes it difficult to improve your existing database design. Not implementing TDD practices in the database, overtime, leads to a decaying architecture and can hinder the evolution of the overall

We will present many hard-to-test c++ idioms and multiple refactorings for making the code testable. Students who need to test and refactor legacy C++ code as they transition to test-driven development, will learn techniques to help them do this work safely and with minimal changes in the performance. We’ll cover several legacy idioms in which code is initially not accessible by tests. We’ll fix these and other testability problems with refactorings like “Extract Method” or “Extract Class”, and C++-specific techniques involving the preprocessor, “friend”, and changing access Levels.

In this session of the TDD clinic, Ron and Chet will walk you through test-driven-development in Java. Participants will write a small program using a very short development cycle of design-test-code-release repeat.