Semergence

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.