Welcome to this issue of the Process Edition of the Coad Letter. In this issue, I will explore where I think tools can be useful in support of Agile Methodologies -- in particular, eXtreme Programming (XP [1]). With special thanks to the XP folks, I show points in the XP process where various tool features can be employed. (Also, thanks to the client who asked for some information on how a tool might be able to support XP, thus the impetus for this reply.)

While following a process is a good thing, being efficient while following a process is even better!

-- Jon

Jon Kern (jon@TheCoadLetter.com)
Editor of The Coad Letter: Process Edition

PS: Important: this issue is not a commercial pitch. Far from it. Please note that that although I worked several years at TogetherSoft, I am now working as an independent consultant (let's work together; drop me a note at jon@thecoadletter.com). Although I am no longer an employee of TogetherSoft, I advocate its products—and in fact, have owned and used Together since 1994, even before TogetherSoft became TogetherSoft. I am fond of using effective products to accelerate my agile development efforts. Some of my ideas have been born out in tools like Together; others are yet to be implemented.

PS#2. Another independent opinion: get this free report by Hurwitz Group and see how Together ControlCenter helps you improve your application-development processes while building higher quality applications. Find out how to control costs and make the most of your infrastructure assets.

Can Tools Support an Agile Process like XP?

In the world of agile methodologies, some of the most common process issues center around the following:7

• Using very lightweight, dynamic, adaptive, methods
• Challenging all forms of documentation to ensure they have a good return on their investment
• Not being beholden to tools for tools' sake
• Encouraging use of simple household appliances, like index cards

Well, I have been a practitioner of agile methodologies since developing a simple process in the early- to mid-90s (Phased, Incremental Development). I like up-front modeling to a reasonable extent -- but not to the point of analysis paralysis. I believe in planning and reporting progress on a feature (story) basis, I do not believe in traditional project planning tools (MS Project). And, I love tools that automate as much of the tediousness as possible. I have even coined a term that combines doing tedious tasks that are of mediocre worth:

TEDIOCRITY.

te7di7oc7ri7ty (Te`di*oc"ri*ty)
n. pl. te7di7oc7ri7ties

1. The state or quality of doing tedious things that are of mediocre value.
2. Ability to do, achieve, or perform in a tedious, mediocre manner.

Call me what you will, but I like tools that make me more efficient and keep me from doing things manually over and over.

In general, tools that you might choose should support all software development methodologies and should be basically process neutral. I like to be able to use an integrated application development environment to model classes (and other UML diagrams that seem helpful), write code, build the apps, and deploy. Tools that allow you to perform UML modeling must have class diagrams always in sync with source code. That is:

• Create or edit classes via the class diagram (or sequence diagram) and the code is immediately generated/updated.
• Update the source (either within the tool or not), and the diagrams immediately reflect the changes.
• Or, add new classes (again, does not have to be from within the tool), and the diagrams reveal them.
• Point the tool to pre-existing source and generate class diagrams with ease

One should even be able to do analysis-only modeling and then decide to convert to source code later (via XMI export of design model and XMI import to projects in different languages).

For an agile methodology like XP (Extreme Programming), a tool like Together ControlCenter has a great deal of support. Lets assume the process is something like the following (with express appreciation to www.extremeprogramming.org for the graphic):

Typical objections of some in the XP community to the use of tools:

• We don't need no stinkin' tools
• We like ANT, e-macs, and JUnit
• We like eclipse or IntelliJ
• Real programmers don't use UI Builders

I can appreciate those sentiments. Folks often get very passionate about their favorite little text editor, for example. I remember doing C++ development on a big IBM manufacturing project in 1997. Though most of us used Visual C++, some of the developers could be found with dozens of "vi" editor DOS windows opened up. (Ahh, too bad more apps don't use intuitive commands like Shift-ZZ!)

I tend to revel in getting things done in the fastest manner possible. And for me, speed comes from the judicious application of creativity, ingenuity, experience, and helpful tools. Oh, and an espresso machine.

General features needed on an ideal tool:

• Speed up development by reducing the tedious and mediocre tasks associated with cobbling together a bunch of manual tools
• Simultaneous round-trip -- can work in model or code and both are kept accurate. This supports those who like to work in code and those who are more visually oriented (me :=).
• Always know what your code is shaping up to be (diagrams, metrics and audits, sequence diagrams generated from code)
• The class view shows some "smells" that aren't apparent just in the code
  • Okay, maybe it is just me. But I used to collect "birdseye" snapshots of class model shapes when I was doing consulting with organizations across the globe.
  • Almost as a kind of "inkblot" psychological profile of the source code. Long, skinny blots; wide, shallow blots; blots that had many disconnected classes; and then blots that just looked good.
• Package views that can show interdependencies
  • A few in the proper direction are good
  • Lots of dependencies going every which way and bidirectional is cause for concern
• Can run metrics and audits to help "smell" trouble
• Integrated with JUnit as part of an entire test framework
• Support of javadoc entries in code or change your standard patterns for default classes, operations, attributes
• Documentation generation
• Add your own javadoc of your own APIs to the context-sensitive help system
• Can kick-start method implementation from a sequence diagram
• Could use the Use Case diagram to reflect simple user stories (or build a quick custom diagram).
  • Can tie stories to URLs (files),
  • Can tie to test cases (optional)
  • Can use custom property to indicate state of story (scheduled, in progress, complete, etc.)
  • Can build simple report to show progress/iteration plans
• Super easy to create class models
  • Manually
  • From a pattern
• Super easy to optionally create stories as diagram entities (like use cases)

Supporting the Architectural spike

Here, we need tools that make it easy to quickly produce some tangible portions of the application.

• By allowing modeling to quickly translate into real code
• Making the build/debug cycle simple
• Allowing one to create patterns discovered in the spike (or at any time) to be available to the rest of the team
• A UI Builder can also help get some visual components quickly prototyped

Supporting Iteration Development

Modern agile methodologies deliver applications in an incremental manner through a number of small-duration iterations. Tool support should be something like:

• Pair programming (of course)
  • The simultaneity of model and code allows visually- and textually-centric developers to work together as pairs.
  • Good programming "habits" should be instilled in tools via
    • Consistent source code formatting settings
    • Code snippets for commonly-used program fragments
    • Patterns
• Programming in a few different ways
  • Traditional text editing with more powerful editor features:
    • syntax highlighting
    • code sense
    • error highlighting
    • import assistant
    • collapsing regions/types of code blocks
    • etc.
  • Via class diagrams when it makes sense
    • during initial design
    • when refactoring at the class level
    • when evaluating concepts that go across classes/packages
    • when interested in dragging and dropping in and out of packages
  • Via a sequence diagram
    • when exploring design from the perspective of implementing a method
    • when doing Test First style of development.
      • That is, write your unit tests visually using a sequence diagram. As you discover the need for new classes and methods (so the tests pass), the sequence diagram will let you create these classes and add new methods instantly. Then, you can tell the tool to generate the implementation and it should even stub out the code for you. Fill in details, hit the "run test" button, and keep on plugging away.
• Support of version control makes it easy to move people around to different areas of the project
• Powerful refactorings (class level + plus deep extract method level) should exist
• Can publish documents to the team's intranet
  • Up-to-date documentation (all UML diagrams plus javadoc)
  • Audits
  • Metrics
  • JUnit test results
  • Acceptance Test Results
• Add your javadoc'd APIs to the tool's help system
  • Say you're building a component that others need to code against and rely on. Each build, you can automatically generate documentation on each API. The help system can be informed of each documentation set. Then, if another developer needs "help" on a given method, the javadoc can be visualized.

Supporting Code Ownership

• It should be easy to move people around. The tool should always reflects the latest changes to the code (assuming people are properly checking their work into VCS.)
• Continuous integration is made easy, just press the build button, or run the tests
• You could even generate Ant build scripts if this was useful for your team
• Continuous testing by simply running the test suites of the entire team
• Note: tests are also versionable items, so it is easy for the entire team (and the build machine) to always have the latest tests
• Refactoring is supported by audits and metrics (help spot huge complexity, for example, or poor design) as a detector ("sniffer?"), and refactorings as a cure

Supporting Continuous Integration

• The tool should support local builds with the team's latest source, and local tests.
• You should be able to configure the projects to point to jar files that contain the results for other parts of the application that you need to work with (so you don't have to compile entire source code tree)
• If the tool has command line access, it should fit well into projects to check in, build, and test frequently, using tools like Cruise Control.
• The formatting, tests, audits, metrics, and documentation can be run and updated with each intra-day or end of day build.

Hope this spurs a different attitude towards using tools in an agile manner! Let me know of your success stories at using various tools for various aspects of agile methods.

Jon (jon@thecoadletter.com)

References

 

Ref #1

See the following sites
http://www.extremeprogramming.org/map/project.html
http://www.xprogramming.com/

The Coad Letter is a service provided by Peter Coad and colleagues.
Feel free to share this issue with others.

Server Response from: BDN10A