Interview with Randy Miller by Clay Shannon

By: Clay Shannon

Abstract: Borland's agile modeling guru Randy Miller describes what AM is, how you can tell whether you and your team are agile, discusses degrees of agility, Pokemon tournaments, and compares software development projects to jigsaw puzzles.

Randy Miller thinking agile[ly]


Randy, is Agile Modeling (hereafter "A.M.") a completely new paradigm, or is it an amalgamation of existing software development practices?

Agile Modeling is a new way of thinking about things that we have actually been doing for quite a while. Scott Ambler, the inventor of A.M., puts it this way, "Agile Modeling is an attitude, not a prescriptive process." There is a huge disparity in the levels of understanding of modeling in the software community. There are folks on one end of the spectrum that look at modeling as a separate activity from coding. There are folks at the other end who see the integral relationship between models and their code.

Moving folks from one end of the spectrum to the other was the whole purpose of Together. Together brought modeling to everyone. Suddenly it became possible to build a system quickly while building it elegantly. It was no longer necessary to make a tradeoff because Together visually portrayed the system that you were building, as you were building it. Today, this is the direction that the modeling tool market is moving.

Agile Modeling is about changing the culture of modeling from an isolated activity that generates a lot of paper, to one that transitions business requirements into working code. This was always the intent of modeling but most people didn't understand how to "get there from here". Many important advances have occurred to make it much easier today to achieve this goal. Some of these advances include a single modeling language, the Unified Modeling Language (UML). There are now modeling tools that draw beautiful pictures while keeping synchronized with the code.

Our understanding of how to make sure that the stakeholders (customers, managers, developers, analysts, architects, and testers) are involved is much more thorough. Education is the final piece. The UML is appearing in many mainstream magazine articles and books to show the world how easy it is to use the latest complex libraries and frameworks.

In your article "Becoming Agile" (,1410,29712,00.html), you state: "Agile software development processes such as Extreme Programming, Feature Driven Development, Crystal, and SCRUM are on their way to becoming more or less household names." I must, albeit a bit red in the face, admit that I know the first two "from afar" and as for the last two, I'm only vaguely aware that you're not talking about a report writing tool and a British or Australian (?) sports play. In a nutshell, can you fill in some of these gaps in my knowledge?

Absolutely. You are quite correct that Extreme Programming (XP) and Feature Driven Development (FDD) seem to be the more popular of the Agile Software Development Processes. The goal of these processes was to challenge the traditional ideas behind software development. Kent Beck and Ward Cunningham "turned the dials to ten" on certain principles such as unit testing. I believe that they felt if unit testing was a good thing, then let's make it an integral part of what we are doing. I don't think that there will be an Integrated Development Tool that won't have xUnit support within the next year.

FDD combined project management concepts with some very innovative modeling techniques. Peter Coad and Jeff deLuca felt that understanding the true progress behind a project was integral to keeping it going and understanding when it could be released. This isn't a "big brother" approach but rather a common sense one. I think that this raises the next frontier for software development.

SCRUM and Crystal are relatively new in the world of Agile Software Development Process. Actually, SCRUM has been around for a while but information about it has come out more slowly than XP. I think that you will be hearing more about these software processes in the future. Ken Schwaber and Alistair Cockburn will be talking about them at the Agile Conference in Salt Lake City this year and at other conferences as well.

One of the things that strikes me about A.M. is its "honesty". For example, one of the tenets of A.M. is iterative development, of which you stated: "Iterative development acknowledges that we probably will not build the system exactly as the user wants it initially. Therefore, we plan to rework a part of a system to remove mistakes or to make improvements based on user feedback. The philosophy of iterative development is that we tend to get things wrong before we get them right." I agree that this is the case (software projects usually follow the needle only erratically at their outset), but it raises the question: How do clients normally respond to this "defeatist" or "pessimistic" (as they might see it) attitude? Do many of them tend to seek out ear-ticklers who tell them all will go well, ("don't worry, be happy")?

I think that building a system of any significant size is like putting together a large puzzle. As you put in another puzzle piece, the puzzle becomes easier to build. One reason for this is because you have fewer pieces. But more importantly, the puzzle moves from one giant hole to smaller and smaller holes. Now, with software, you do not have the benefit of being able to look at the picture on the puzzle box. An individual tells you what the picture on the box looks like, and then it is your job to turn that information into the "puzzle". This is how requirements work. If you're lucky, the requirement may have been written down for you.

The idea of picking up a puzzle piece and placing it in the exact right place has a low probability. Unless, of course, you have put this exact puzzle together before. One more thing, not knowing the domain is equivalent to never having seen the thing on the puzzle top, like an abstract design. "It's a swirly thing with red and green swirls." There is a lot of vagueness in most requirements documents. The agile movement is about interacting directly with the users to remove any fuzziness.

Good software development mangers understand this idea. They plan for the rework. They approach the project with a set of tactics that have worked before. For example, they might collect the border pieces and put those together first. If a set of pieces was put together in the box (components), they will be careful taking those out and using them in the puzzle.

For a fixed price contract, they'll budget the "finishing" in. Those that do not budget this work will end up with "slips", bugs, overtime, heavy change request management, or rigid acceptance tests (it passes the acceptance tests but otherwise does not work). If the system is shipped without the rework, the users have to adapt to a system that is not necessarily ideal. Users are, however, often remarkably adaptive. But the adaptation comes at a price, which is lost productivity.

The software development process does not have to be ideal. You can try a puzzle piece and not have it fit. Software development is not like manufacturing; it is like craftsmanship. The better the craftsman, the more the process looks like "magic" from the outside. But it is still hard. Buy a 2500 piece puzzle of a picture that is one solid color. You'll get the idea!

If you walked into a software project "blind", how long would it take you to know whether they were using an Agile Software Development Process or not? Is Agile a "binary" thing (either you're using it or you're not), or can a shop be "semi-Agile"? What questions would you ask, or what specifically would you investigate to determine whether and Agile Software Development Process or Agile Modeling was being employed?

Fortunately, there are a lot of ways to be agile. I think that if you asked most people, they could tell you whether their project is agile or not. It's a matter of asking the right questions. Are they responding to the customer needs with your software? If you decided to ship the next build, could you do it with whatever features were in at the time? Are you treated as a valuable contributor to the project that you are working on? What happens when change happens?

Now, I am not advocating actually shipping every build. In some domains, this is not only possible but necessary. In others, it is foolishness. But does the system "work" after every build? Do you build every day? Many folks use "smoke tests" to determine if a build can be promoted or rolled back. Does your project have them?

These are a few of the questions that I would ask of a software development team. There are many, many more. These would include the use of software development best practices. They would also include management styles. The answer would probably not be "yes" or "no" to the question of being agile. Many companies are a shade of gray. Unfortunately, there are some companies that have few redeeming agile properties. To quote a friend, "Some companies should not be in the software business."

Agility is determined by the leaders of the project. Each leader must empower his or her people to be as agile as possible. The more agile a team is, the more likely they are to be successful. It doesn't take very long to see if the team stops at the roadblocks or jumps over these hurtles. Agility varies by company, project, and team.

An agile team will perform best when using an agile software development process. This process could include Agile Modeling. One of the project leads for a large insurance company using FDD said, "I am finally enjoying building software again". I think there are a lot of software developers being "held back" from achieving their full potential.

Do you spend time "in the trenches" programming, or is all your time spent consulting and writing? IOW, are you a software practitioner, theorist, or both?

I definitely spend a lot of time in the trenches! I have held about every software development/management/architect position that you can. I am proud to have been part of many excellent teams that have delivered some state-of-the-art products. It's mostly commercial stuff in software development tools and networking.

Where do you live, exactly? If you are not native to that area, where are you originally from?

I am from the infamous RTP area. I was recruited from Rutgers University by IBM in the late 1980s. My first project at IBM was writing OS/370 assembler. The folks who write mainframe assembler are pretty hardcore. I learned a lot doing that. Two years later, I was writing Smalltalk and C++. I came to Cary, North Carolina sixteen years ago. It was a very small, lovely area. However, it grew rapidly and was voted "The Best Place To Live" by Money magazine in 1995. Amazing how the old tobacco shacks gave way to housing complexes.

Note: For those unfamiliar with the Raleigh*/Triangle Park area, that is what Randy refers to as RTP.

* Made famous, along with Mt. Pilot and the fictional Mayberry, in the television shows "The Andy Griffith Show" and "Mayberry R.F.D".

How did you get started in the software development world (How were you introduced to it, when did you realize you wanted to pursue it as a profession)?

I had an uncle who worked for Princeton University. I was in fifth or sixth grade and he taught me to play "Adventure" on the computer. It was a unique experience. I was immediately hooked and it was just a matter of time before I starting writing these sorts of games myself. I lived in Morristown, NJ and the magazine, "Creative Computing" was published there. I bought every issue that I could get my hands on.

My first language was Basic and by high school, I was writing assembler, PL/1, and Fortran as well. Microcomputers were just getting off the ground. It was exciting times. I worked for Rutgers University in the IS group while I was going to school. I wrote "Pro-Nurse", a system for testing nursing students, in Turbo Pascal. I also wrote an inventory system and worked on the Thomas Edison Papers project.

What software languages do you know? Which ones do you currently utilize?

The Unified Modeling language (UML), HTML, XML. But seriously, I wrote C++ last night and Java today. I also do a lot of C#. Borland is a place where you use a fair number of programming languages. I have done some Delphi. I spend a fair amount of time writing software. I think that programming is very important. It keeps the synapses firing.

Do you have a personal web site? If so, what is the URL?

I have a site for my first book, Advanced Use Case Modeling ( It is actually software related. To me, that's personal.

If you weren't involved with software development, what do you think you'd be doing for a living?

I'd probably stay home and play with my kids. My family is very important to me. My daughter plays the Pokemon card game. She has thousands of cards. She beats me all of the time and loves to compete in tournaments all over the country. My six year old son is now playing the game as well. My wife will tell you that I love these sorts of things. I think that if I were not building software, I might be spending a whole lot of time working on inventing my own type of Pokemon game or some other creative video game! My wife would have to be the sole provider of the family bacon!

If you could live anywhere on earth at any time, when and where would it be, and why?

There are a lot of places where I could live quite happily. I like RTP very much. I also love Prague, Sardinia, Singapore (and the Cayman Islands come to mind as well)! I think the last three are all islands so I shouldn't have to justify them. I have spent quite a bit of time working with our development team in Prague, and have traveled there with my family in the past year. We all fell in love with the gorgeous city and the lovely people.

This interview was conducted via email June 2003.


Clay Shannon is a Borland and PDA-certified Delphi developer and the author of "Tomes of Delphi: Developer's Guide to Troubleshooting" (Wordware, 2001) as well as the novel he claims is the strangest one ever written, "the Wacky Misadventures of Warble McGorkle" (see Wacky Warble, etc. for more information on the 4 Novels application, which contains this and three other novels he has penned).

You can find out more about Clay at:
You can look into Clay's shareware and determine his current availability at:
You can contact him at:

Server Response from: ETNASC03