Fog Creek Software
Discussion Board

What design methodology(TM) do you use?

Hi Joel.
I know that you have the functional specs part quite nailed, but what about the design?

Do you use some mammoth RUP-kind of thing, with all the design up front, or a more XP-kind of approach? Or maybe just prototype and then flesh it up?

Also, which tools? Pen and paper, Visio, Rational Rose etc? Or just Excel for everything? ;-)

Also, do you design and document all the use cases, or only overall used architectural mechanisms, and then code away?

Thanks in advance

Gabriel Lima
Wednesday, February 25, 2004

A google search for "Joel methodology" reveals that I am not a big fan of the M word.

We don't use a methodology, we use our brains and a collection of methods that have worked in the past and which are amply documented on the web (Google Search for "Joel")


More seriously, things like RUP and XP are designed for line of business applications with big databases. Really big databases. We develop shrinkwrap commercial software and that's a completely different proposition.

Everything about RUP, for example, is obsessed with figuriing out what the business objects and business rules are so you can do a payroll system. We do things like add spell checkers to an editor window.

Joel Spolsky
Fog Creek Software
Thursday, February 26, 2004

I have evolved a "methodology" based loosely on the RUP. We use Use cases, Sequence diagrams and activity diagrams. I find this is sufficient to put together a Customer Requirements Specification.
As far as the package I use to handle the tool, I use word and Visio. We did go out and spend millions on Rational Rose licenses and the associated clear case SoDA etc etc and further millions training everyone, but as soon as the dust settled NO ONE in the company used it because it was just too complicated. Many companies feel they can run before they can walk. i.e. "We don't spec our systems at present, but we should. Instead of taking small easy to follow steps, let’s take the big leap and go from zero to hero" It didn't work here and I don't believe it will ever work.
As Joel says, as long as you write down what you want and think through all the processes, it doesn't matter what you use. Just as long as it is clear and unambiguous.

Thursday, February 26, 2004

Wow.  It has been a few years since Joel wrote one of those things I so agree with.  This is the sort of thing that first got me coming to this web site.  This is entirely my problem with RUP.  It assumes way too much about the sort of application you are developing.  If you are developing an application for which it is not ideal, the process itself could prevent a team from developing the best solution.

name withheld out of cowardice
Thursday, February 26, 2004

Agree - use your brains and manage changes.

Alan Bekoev
Friday, February 27, 2004

Thanks for the info about RUP

Developer struggling to become a P
Friday, February 27, 2004

Even Martin Fowler laments at the regard in which UML is held in some quarters "The unwanted modelling language" : see

All of these things come back to a few golden rules.

1. Use methods if they are useful to you. If it is not useful, don't do it, even if you feel guilty about not "doing it properly" (if you want to feel guilty about something, feel guilty about not flossing). RUP high priests have perfected the art of being sniffy about how everything MUST be done. Bully for Grady Booch, but I gotta ship some software.

2. UML is pretty helpful - but don't feel you have to model everything in it.

3. Do have something that tracks initial ideas/features into design. Build up the picture as you go along. One paragraph turns into many etc. Use Access or RequisitePro or a Lotus Notes database or anything that helps you do it. You could almost use CityDesk, but it is a few features short of doing the job. A few tweaks, Joel, would deliver a fantastic spec-developing system and another line of product (might do a sep post on that one).

4. There are good products such as Sparx Systems Enterprise Architect that do the job pretty well without the Rational Rose price tag (and a far sight more usable).

5. Your documentation is simply a memo of understanding between developer, analyst and customer/sales manager. Just put whatever in it so that all 3 can say "Yes, this is what we are doing". Is it enough to make it clear to the client what you are doing? Is it enough for a developer to get on with it?

6. Nothing replaces communication between analyst and developers. Spend a lot of time together talking about how you do stuff, what is useful, what is not. Get to know each other's game well. A lot of what goes into RUP is based on the premise that "what gets document is the full picture and will not need any conversation between analyst and developer". Might be necessary for outsourcing something to India, but needless and perhaps a harmful approach if you are sitting close to eachother.

7. Try and make it change once-and-everywhere. If something changes and you have to change six documents, you are going to get out of synch pretty quick.

8. Don't be obsessed about "there must only be one place for everything" (this does not contradict the previous point). You might have a special feature in your product that needs a pretty detailed explanation. Give it its own document/spec, and just lightly describe it in your master document. Just make sure that you do not have to update more than one document when a change is made.

9. There is no other test for efficiency, sufficiency and correctness of development methodology than "Does it allow us to get the job done".

10. Develop standard ways of doing things, so you don't need to cover it in each spec. By this, I do not mean a 100-page web development standards document (developers NEVER read them). An example of what I mean is - unless specified otherwise, if you are creating a business object in the system (e.g. customer, order, journal etc) it must come with its own create, read and edit forms and a listing (or view or index) of the records created with it sorted in x order etc. The idea here is that you don't launch without someone saying "umm, how do I edit that?"

That's all I could think of ... back to work for me.

Patrick FitzGerald
Friday, February 27, 2004

Well, I've never formally used the RUP (the license fees are a bit of a deterrent), but I think the basic principles are pretty sound, and can be applied reasonably well to most circumstances. There's notable overlap with the Joel Test  in the best practices list :
(RUP) Manage requirements - (JT) Do you have a spec?
(RUP)Continuously Verify Quality - (JT) Do you make daily builds?
(RUP)Buy lots of Rational licenses - (JT) Do you use the best tools money can buy ? Do you use source control?  Do you have a bug database?
RUP emphasizes "iterative, incremental" development as a core strategy -  which from all I've read about Microsoft's development practices is what they practice, although they clearly can't release every increment. It recommends up-front phases (relatively short) for sorting out the architecture and project plan - surely you can't complain about that ?
The RUP is supposed to be configurable for your project- so if you don't need to do database design, you can get rid of that stage. If you need to do some additional work in your project, you can add an additional stage.  The main reason I guess it doesn't necessarily work for FogCreek is that it introduces a level of ceremony into the development process, which is appropriate if you have a large team, complex/risky domain (predictable "aircraft control systems" mention), regulatory requirements, or contractual obligations. If, on the other hand, you have a small, inhouse, co-located team working on a well-understood problem domain without significant risk to life & limb, or pesky 3rd-party customers with pitbull lawyers, that ceremony imposes cost without offering much benefit. 

Neville Kuyt
Friday, February 27, 2004


I think you are using "features of RUP" as equivalent to Rup itself.  It does not follow that if someone doesn't use RUP he must therefore not like any of the parts of RUP.  Consider the concept of iterative develoment.  Just because I don't want to use RUP for a particular project doesn't mean I am against iterative development.  IN fact I dare assert that it is impossible to develop software non-iteratively (unless you are the Mozart of software).  Someone just made up a word for it and put it in a "process" and then managers think it's okay- "What, the first version isn't perfect and in coding it you learned some stuff that has to be fed back in to the design?  What are you, incompetent?  Oh- it's called 'iterative development'?  Well okay then!"

Yes RUP definitely says that you only have to use the aspects of RUP that you find helpful to your project but, not to be a bay here, at some point you are using aspects of RUP that are so generally applicable that it isn't fair to have to call it RUP anymore.

To me RUP intrinsically involves this idea that there is an almost mechanical method for going from use cases to objects to code.  If you aren't using this aspect of RUP (i.e. elaborating your use cases with sequence diagrams and activity diagrams and so forth to get to object diagrams and then generating code from those etc) you aren't really doing RUP.

I like use cases for some types of projects.  I like UML object diagrams for almost all my projects.  I think it is impossible to develop software without iterating (no matter what you choose to call it).  This, to me, does not equal RUP.

name withheld out of cowardice
Friday, February 27, 2004

I'm not a big fan of "high-ceremony" methodologies, and have had good success running projects using a customized agile process (which blends elements of XP, Scrum, Agile, RUP, etc.).  Like Joel, every project that I have headed up had a slightly different process/methodology, since you have to account for the culture, personalities, intrinsic corporate processes and more.

With regards to RUP, it does not have to be a heavyweight Big-M ethododology.  RUP, like many methodologies, can be as light or as heavy as you want it to be.  Unfortunately, most PHM's seem to drive it towards the latter, and have thus stigmatized it to the point of seeing threads like this one on the subject.

A tongue-in-cheek article, though one which illustrates that RUP is not necessarily Big-M, called:  "How to Fail with the RUP: 7 Steps to Pain and Suffering".  It  is definitely worth a read, especially if you have to use RUP but want to retain agility, and can be found at:


Andrzej Jan Taramina
Friday, February 27, 2004

Too right, the RUP can be whatever you want it to. And that, I believe is what makes it next to useless.
All the RUP tells you is that you have to kind of do some Analysis, until you've done enough, then you do enough Design , then a bit of Code, maybe? Finally, we test. Oh, and don't forget to repeat that a few times.

Following the RUP is like trying to nail jelly to a wall!

Don't forget the 36 roles that are needed on the 'typical' project. Or maybe 1 person could do several. Or maybe you won't need all of them. Look, if you're confused, Rational consultants can offer training. And books. And videos.

Based on the RUP, I've got a foolproof method for writing a bestselling book:
1) Have an Idea
2) Elaborate the idea
3) Write it down
4) Read it back and fix the bits that don't work

I should be charging for this advice, you know.

Friday, February 27, 2004

Alastair Cockburn wrote an article back in 1999 entitled "A Methodology per Project", located at , which basically says much the same thing:  use what works for the project, discard what doesn't, and don't sweat it.  For that matter, that's the underlying philosophy of Bruce Lee's Jeet Kune Do...

Peter Herndon
Friday, February 27, 2004

Alistair Cockburn is also writing a book on his "Crystal Clear" methodology.  It makes great reading for anyone interested in making good software while avoiding excessively heavy processes.  His work:

(a) Is based on 10 years of research into what actually works.  (Based on extensive study of software teams around the world.)
(b) Results in a "minimal" process - i.e. it is designed to be light enough for people to actually follow, and yet still cover the key things that help projects to succeed.
(c) Is not dogmatic. There is a lot of room for adapting things to suit your particular team and project. Unlike RUP, which starts big and you tailor it to make it smaller, Crystal Clear starts small and, if you want, you can tailor it to make it bigger.


John Rusk
Friday, February 27, 2004

"More seriously, things like RUP and XP are designed for line of business applications with big databases. Really big databases."

This seems to indicate that you fundamentally misunderstand the XP Planning process. Here it is in a nutshell.


1. Every n weeks (where n is small, say 2 or 3), you have an "Iteration Planning meeting". The customer (who would be played by you, Joel) sets the direction for the iteration by drawing out the features they want in terms of short, simple to understand stories. "The user can print a bug report."

Developers take these stories and, with the guidance of the customer, help break them down into small technical tasks that take no more than a day or two. They choose which tasks they want for the iteration, and it's determined whether there is too little/too much work for the iteration. Give and take.

2. Every day, you have a "Stand Up meeting". It's short. Everybody stands up (hence the name) to make SURE it's short. Everybody mentions what they worked on yesterday, what they're working on today, and whether they're blocked. Don't find solutions, just get people together so they can find solutions off-line. You know right away when you're off track, because the team is spending 5 minutes every day talking about it.

3. End of the iteration, all new features are validated by the customer, and accepted or rejected. Acceptance doesn't necessarily mean the feature is complete; new stories can be put into place to modify the behavior during the next iteration.

Rinse, repeat.


Now tell me where anything there talked about or implied anything to do with "Big Databases"?

Brad Wilson (
Sunday, February 29, 2004


How would that work for an application that would benefit from deep obscure domain knowledge?  I work on medical software and I find that one of the greta difficulties is that the programmers don't knwo the domain space.  Given that the domain experts don't really know anything about programming, someone with knowledge of both needs to ask the correct questions and produce a good design.

The process you describe seems to have programmers acting as analysts.  I don't see this as being aboe to produce anything more sophisticated than computerizing forms the domain experts are already using.

name withheld out of cowardice
Monday, March 1, 2004

I think most people take the wrong approach when dealing with the RUP (or any formal methology for that matter). RUP is really a repository of "best practices" accumulated by Rational by looking at successful software projects.

This being said, the first thing you should do is understand your current process (yes, even if informal and undocumented you _are_ following a process)! Once you know how you are currently doing your business (probably software development), you can start looking at how the practices described in the RUP can help improve your process.

Too many people go the other way and try to simply look at RUP and define what their process _should_ be. This is a recipe for disaster. It is difficult to get somewhere when you do not know where you are!

Process adoption should be dealt with in the same way as any quality improvement: iteratively and incrementally!

That being said, I think that anyone adopting RUP without going through these steps is doomed to fail. And anyone just adopting RUP without customisations is not only doomed to fail, but also doomed to hard labour!

In closing, we have been using a customised version of RUP for our own work (I'm in a large company) and it works fairly well. I think the best advantage is that everyone has web access to our customised process and any relevant artifacts (tool mentors being to most used).

Tuesday, March 2, 2004

"Deep domain knowledge" - Brad's description of XP focussed on addressing the "it only works for database-driven applications" concern.
In XP, one of the jobs of the customer is to define acceptance tests, ideally, by creating automated test scripts. That's exactly how your problem would get solved - the medical experts would define the tests which a "story" should be able to pass, and leave it to the developers to work out _how_ to pass those tests. In addition, XP emphasizes having an "onsite customer" - someone who is available for developers to ask questions of, informally, casually.
Having said all that - I think most XP advocates would recognize the process is _not_ optimized for critical problem domains such as medical software, aeronautical software etc. It's mainly used in "enterprise" software, using relatively small teams.

Neville Kuyt
Thursday, March 4, 2004

I concur with Neville's comment.

I just wanted to add that it's pretty common for the Customer to work with one or more developers to codify the acceptance tests. 

The developer plays an active role in drawing out details from the Customer, in that approach.

Jeremy Dunck
Friday, March 5, 2004

One of the most important, but overlooked, document in RUP is called the "development case." You actually have two, one for the organization and one for each project. Here you describe how you will actually use the process, tailored for your organization and process. Who fills what roles, which documents will be created or skipped over, and what level of detail to do the work at.

This is where you change from the "jelly on the wall" to something a little more stable. It gets everyone on the team set with expectations about how you're all going to proceed. Its especially important with contractors, because without this you will get into arguments later about "what is following RUP." Call it what you want, it should be a part of any process, involving a conscious thought about how it will or will not help the project, given the specific organization and team doing the work. "One size fits all" never does.

The development case, just like any other part of the project, needs to evolve. Nobody has perfect future vision; just agree up front that you all reserve the right to make intellegent course corrections as you discover more about the project. This is why change management is so important; not to stop change, but to make sure that everyone remains "on the same page."  Couple this with the iterations--short enough you don't go in the wrong direction too long, but long enough to avoid thrashing the water in place.

One problem many people have with RUP, XP and many other iterative/incremental methods, is that they need to look at Barry Bohme's "spiral model." to do it right. You don't come up with the entire system requirements and design up front, and then code in iterations. Also, you don't just forget the analysis and design and do iterations of coding based on customer feedback. Instead, each iteration you get collect some requirement, and do the analysis and design of the parts you're going to construct in that iteration, with enough extra to figure out what you will accomplish in the next iteration. XP is not just "hacking code" until you come up with something the customer stops complaining about.

On the expert knowledge based systems question: There are two types of actions, planned and situated actions. Planned actions involve conscious thought ahead of time, and these are easily captured in requirements meetings. Unfortunately, most of the work an "expert" does is situated: it is in response to some situation, where the exact conditions present will determine the response. These are the types of requirements that typically lead to the later "You didn't tell us about that!!!" "Any idiot knows that/Well you didn't ask!!!" exchanges. The iterative/ incremental helps to address these by allowing for a planned evolution (it wasn't a missing requirement, we just hadn't gotten there yet). As the user works with the (partially completed) system, they will get to experience the situations and feel that something is not quite right; this will lead them to bring their unconsious knowledge to the front of their mind, where they can communicate it as written requirements the programmer can add to the code (or expert system engine, or whatever).

Another aspect of RUP is an emphasis on risk-mitigation. You work on the riskiest part of the project first, to reduce that risk. Personally, I have very mixed feelings about this piece of advice.

One problem that I see in most methodologies, is that they will look at the "users" of the system in various ways. This could be use-case driven like RUP and many others, or "user-driven" or "usage-driven" (See Constantine's with some slightly different views of development. Unfortunately, what they need is Stakeholder Goal Driven development. In many cases, the real purpose of the software is to protect the interests of stakeholders who are not present during the use of the software. For example, the IRS will not be present when you run your payroll application, but it better take into account their intersets, or your company will get into a lot of trouble.

David Lathrop
Sunday, March 7, 2004

*  Recent Topics

*  Fog Creek Home