Seth Ladd's Blog

Waterfall 2006 - International Conference on Sequential Development > After years of being disparaged by some in the software development community, the waterfall process is back with a vengeance. You've always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project. Learn how slow, deliberate handoffs (with signatures!) between groups can slow the rate of change on any project so that development teams have more time to spend on anticipating user needs through big, upfront design. This is a must-attend conference. Don't miss sessions like wordUnit: A Document Testing Framework and Introduction to Dogmatic Programming .

An Introduction to Extreme Programming -- Application Development Programming Extreme Programming Learn the key practices of Extreme Programming and how this agile development methodology can improve the quality of your code and make your life as a developer more enjoyable.

To Plan or Not To Plan XP says to do a good job (tests, refactoring, communication) of solving today's job today and trust your ability to add complexity in the future where you need it." It has indeed been my experience that it's hard to predict the future. It's not necessarily just predicting the future that's hard, though, it's understanding the whole problem. At the beginning, you don't understand the problem enough to know what to design. You discover a lot about the problem space by implementing the code. Coding is almost like exploring the space. You discover more and more detailed information about the problem space as you explore it by coding.

Archive Refactoring is a powerful technique for improving existing software. Having source code that is understandable helps ensure a system is maintainable and extensible. This paper describes the refactoring process in general and some of the benefits of using automated tools to reliably enhance code quality by safely performing refactoring tasks.

Working the Program Traditionally, the cost of change curve said that if we detect the need for a change early, it costs less to make the change than if we detect the need late. I tackled that curve by saying, let's almost intentionally make mistakes so we can practice correcting them. That practice will help reduce the cost of making changes late.

Working smarter, not harder: An interview with Kent Beck Java is so pessimistic. You have this compiler saying, "I'm not sure this program isn't going to run so I won't run it." I find that attitude disturbing in a program. I notice that the safety in pessimistic languages is an illusion.

Mission-Critical Development with XP & Agile Processes Thanks to our process, we have complete confidence that we can fix bugs and add features without introducing new problems. This article is preaching to the choir, but still a good read.

Java(TM) Boutique - Using Mock Objects in Java A mock object is, as the name implies, a simulation of some real object. In Java, a mock object would typically be an implementation, with very limited functionality, of an Interface. Mock objects play a significant role in unit testing, for a number of reasons. You'd consider using a mock object for your unit test if the real object has a complex set-up, uses many system resources (like cpu power), or doesn't yet exist! If you're writing an application that uses a database, there's no need to wait for the team that develops the database modules before you start coding the rest of the application. What you need is a mock object that behaves like the database modules. If you have interfaces defined to the database modules you're ready to go. Coding with these interfaces might even bring some problems in the Interface design to the surface before the coding of the database modules has even started!

Bruce Eckel's MindView, Inc: 5-2-03 Strong Typing vs. Strong Testing In recent years my primary interest has become programmer productivity. Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. Ahh, Python: my new love affair. So easy to say what I want to say in that language. No long compilation steps. Easy to move from idea to code to execution. My vote for most productive language. Ruby is a close second, just doesn't have the mindshare yet.

Keeping the Code Clean at InformIT.com Keeping your code clean is just as important as getting it to work. Clean code allows you to extend and maintain your modules, whereas dirty code ties you in knots. I can't stress this enough: Software professionals don't leave their code in an unclean state. They don't tolerate sloppiness, wanton duplication, or messiness. Professionals take pride not only in getting their code to work, but also in keeping it simple, small, and easy to read. Good basic article on TDD. I wouldn't have chosen to make the FooToXML code a static class. Why not just place that functionality right into the Foo class? The way Martin has it, it reminds me too much of EJBs (not very object oriented). I like to place the methods that operate on my data in the class that holds the data. But when Martin speaks, you gotta listen. Good cooking analogy at the end.

AgileAlliance Articles Follow the Agile Alliance articles as they get published.

Principles of Extreme Programming Eliminate waste. Amplify learning. Decide as late as possible. Deliver as fast as possible. Empower the team. Build integrity in. See the whole Principles of XP outlined. People might not attack these as much as they attack the practices. I hope not, I find these principles a good reflection of what XP tries to teach us.

Wired 11.09: The New X-Men The Mountain Dew-fueled all-nighter is history. Today's supercoders work 40 hours a week. And two to a computer. It's called extreme programming - and it's revolutionizing the software world.

Object Mentor - xpepisode.htm In order to demonstrate XP (eXtreme Programming) practices, Bob Koss (RSK) and Bob Martin (RCM) will pair program a simple application while you watch like a fly on the wall. We will use test first design and a lot of refactoring to create our application. What follows is a faithful re-enactment of a programming episode that the two Bob's actually did.

XProgramming.com - an Extreme Programming Resource XProgramming.com is a resource for information about Extreme Programming (XP), the exciting new streamlined software development process originally described by Kent Beck. XProgramming.com is offered as a community resource for those interested in XP and related topics.

Specifically, it shows how unit tests and simple design work together while programming. Observe how the coding process occurs in small steps, just enough implementation to make each test run. There's a rhythm to it, like a pendulum of a clock: test a little, code a little, test a little, code a little. I'm a big fan of Test Driven Development (TDD). My favorite aspect is that it allows me to write the least amount of code possible. I spent time making tests pass, instead of coming up with the coolest way to do it.

Emergent Design vs. Early Prototyping - Software Reality However, early prototyping (used correctly) provides many of the benefits of an agile approach (for example early feedback), whilst retaining the more rigorous benefits gained from designing a system before coding it up. This article seems to forget all about XP's Spike Solution phase. In this phase, if the solution to a problem is unknown, it's OK to do a Spike Solution. This is a quick test of a small slice of an application to prove, or figure out, what and where the pieces of an application might be. For instance, if there is a new persistence layer that might be nice to use, test it out in a Spike Solution. This seems to be sort of the ideas behind the article. I disagree with the article on a few points. For example, time is always important on projects. You never have time enough. Why waste it on prototyping code to throw it out? By using XP's other tenets (unit testing, constant refactoring) the beginn...

Extreme Programming problems This is a long article, and I admit I had trouble getting through it. I believe the author has some points worth mentioning, but fails to really grasp a major aspect: That XP is not for every project or team or situation. I am a huge fan of XP for many reasons. Each methodology addresses a unique set of problems or issues. XP addresses two main issues: Change and the Risk associated with it. XP attempts to mitigate the risks of changing the system. If you are lucky enough to be on a project where the customer can clearly articulate their requirements once , then maybe XP isn't right for you. From experience, most customers in the e-business arena, don't know what they are building. Some don't even know the problem they are trying to solve. XP, then, is a great way to tackle the problem. Again, choosing the right methodology is not easy, but understanding the potential problems of the situation will help in picking the right one. Understa...

Fundamental Problem with Extreme Programming "XP requires too much of an investment from the business." I disagree with that statement completely. XP allows the business do what they do best: solve business problems and be in control of the software deliverable. If the business doesn't know enough about the problem they are trying to solve, then the project will never be correct. It doesn't matter how good the programmer is, if the customer doesn't know what they are trying to accomplish, then the project is doomed. Of course, the question of "How to technically solve the problem" is up to the programmer. XP is good because it acknowledges the customer is a participant in the process of developing software during the entire process .