My last job evaluation included just one weak point: timeliness. I'm already aware of some things I can do to improve this but what I'm looking for are some more.

Does anyone have tips or advice on what they do to increase the speed of their output without sacrificing its quality?

How do you estimate timelines and stick to them? What do you do to get more done in shorter time periods?

Any feedback is greatly appreciated, thanks,

  • 96
    Spend less time on SO at work, if you do so. – San Jacinto Sep 11 '09 at 15:16
  • 52
    If you are reading this, it's already too late – OMG Ponies Sep 11 '09 at 16:28
  • 32
    I read "How to become a fatter programmer". Made me laught – marcgg Sep 11 '09 at 16:39
  • 13
    I would ask you a follow-up question. Is your desire to be a "faster programmer" a result of your own poor performance (AKA, you need to hone your skills, you need to focus and eliminate distractions (such as SO), etc), or is poor planning from a development standpoint (AKA, you were given 1 week to do something that any sane person would have known would take 1 month). Each item has very different solutions. – JasCav Sep 11 '09 at 20:21
  • 3
    There's no single right answer possible, so make it into a community wiki question or have the question closed on you. – Donal Fellows May 30 '10 at 15:42

87 Answers 87


Turn off the computer. Grab a pencil and some paper. Sketch out your design. Review it with your peers. Then write the code.

  • 9
    OR you could keep your computer on, and open i.e. MS Visio – sshow Sep 11 '09 at 15:02
  • 208
    Pencil and paper or a whiteboard is faster than most applications that I've used. – Thomas Owens Sep 11 '09 at 15:03
  • 24
    Doing it on paper focuses the mind. – pjc50 Sep 11 '09 at 15:10
  • 100
    why can't i downvote the visio comment? Not using visio is a certain way of speeding up development! – darasd Sep 11 '09 at 15:32
  • 52
    Ugh.... Visio. Every time I'm asked to "use Visio in your design document", I first sketch it out on paper, then spend the next two days fighting to get all the lines in Visio correct. – Robert Fraser Sep 11 '09 at 21:03

Some ideas...

  • Avoid gold plating - do only what is asked of you (in terms of requirements)
  • Understand business requirements and do it right the first time
  • Thoroughly understand your environment and tools
  • Become a fantastic typist, use keyboard shortcuts instead of the mouse
  • Take an iterative approach and build in sanity checks to ensure you are on the right path
  • Don't reinvent the wheel, consider reusing past work and the work of others
  • Eliminate distractions, don't keep checking email, looking outside, talking to coworkers, etc.
  • Don't overwork yourself - recognize when you need to take breaks
  • 7
    +1 for not reinventing the wheel. Learn to produce reusable code, that can bu plugged in another code and work with none to small re-write. (ex.: functions with parameters, instead of hard-coding) – Jay Sep 11 '09 at 16:04
  • 34
    +1 for "avoid gold plating" -- this has been the cause of me missing way too many deadlines because of my perfectionist/anal-retentive tendencies. – Dinah Sep 11 '09 at 17:05
  • 7
    Typing - important point. Always amazed at the number of coders I meet who haven't learned to type... – Paddy Sep 11 '09 at 17:21
  • 2
    +1 eliminating distractions. As I see it, they are the major time eaters. – Umer Azaz Sep 12 '09 at 11:28
  • 2
    +1 for the tips to micro-improve (instead of macro-improvements in terms of planning projects). – MP24 Sep 30 '09 at 8:30

Your desire to be a "faster" programmer by itself is laudable. However, not delivering on time does not mean you are slow, it means the project was planned poorly. Being a "faster" programmer will not help; it just means you'll whoosh past the deadline faster.

You (and your team) are doing one of the following mistakes (or all of them):

  • underestimating the work that needs to be done;
  • missing a big requirement or architecture piece during planning;
  • confusing work estimates with calendar estimates and not accounting for things like meetings/phone/other overhead;

There are multiple ways you can address any of the three above. But before you can improve on any of them, you need to know why things are going the way they are. Do a postmortem on the last two or three projects estimates vs. actual time taken and figure out where the extra time went.

I'll repeat it again - being slow at writing code won't cause missing the deadline, if you've planned it properly to account for that fact.

  • 47
    Some devs really are too slow though. It can be a problem. – Brian MacKay Sep 11 '09 at 19:57
  • 12
    Yes, this can be a problem, but it's a personal problem. It should never become a project or a team problem. In other words, it can impact one's carreer, but it should never impact the project schedule. – Franci Penov Sep 11 '09 at 20:31
  • 12
    'not delivering on time does not mean you are slow, it means the project was planned poorly' - that's a textbox description of an invalid argument. there are many other reasons why you mightn't deliver on time, one of which may well be because you are slow. – flesh Sep 11 '09 at 21:30
  • 15
    @flesh - if you know you are slow, why wouldn't you plan your schedule to account for that fact? In other words, if you know you can't run as fast as Usain Bolt, would you plan to run 100m in 9.7s? – Franci Penov Sep 11 '09 at 22:46
  • 5
    @Kibbee - in this situation you cut features. you can't promise to do certain work in certain time when you know it can't be done and hope for a miracle. – Franci Penov Sep 13 '09 at 3:16

Really, really learn your editor. If you use an IDE make sure you're using all the features it offers. Get a cheat sheet to learn the keyboard shortcuts for your editor of choice. If you're using a shell set up shortcuts for commonly used directories

  • 3
    This can indeed sometimes increase productivity drastically – sshow Sep 11 '09 at 15:05
  • 6
    Writing actual code is just part of a dev's work. Spending time to learn the IDE to perfection is a point optimization; and you know what they say about optimizations, don't you? - "Measure first and then optimize the bottlenecks". – Franci Penov Sep 11 '09 at 20:35
  • 1
    I don't see this at all. If I knock 50% off my typing time, how much time is that going to save me in a day? In my experience, I'm spending most of time thinkingabout/testing/evaluating/slightlymodifying/etc code, as compared to actually writing it, I think this would end up being not much of a win at all. – Beska Sep 11 '09 at 20:52
  • 4
    It makes navigating the IDE something you do without thought. Anything that requires any concious effort, like moving to the little grey button marked something or other next to all the other little grey buttons slows you down by interrupting your thinking. Having ctrl-n under my fingertips without any motion is a major net win. – Paul McMillan Sep 11 '09 at 21:08
  • 5
    Along same lines: learn general 'hot' keys. E.g., in many Windows programs... Copy: Ctrl + c Cut: Ctrl + x (the 'x' looks like an open pair of scissors) Paste: Ctrl + v (right next to 'c' and 'x' above) Go to start of line: Home Go to End of line: End Move cursor by word (not character): [Shift] + Ctrl + left or right Go to top of doc: Ctrl + Home Go to end of doc: Ctrl + End etc. – steamer25 Sep 11 '09 at 22:01

"Does anyone have tips or advice on what they do to increase the speed of their output without sacrificing its quality?"

Many, many people strive for "ultimate" quality at the expense of something that is (a) simple, (b) reliable and (c) correct.

The most important way to speed up your development is to simplify what you are doing so that it is absolutely as simple as possible.

Most folks that have problems with delivering on time are delivering way, way too much. And the reasons given are often silly. They're often just perceived requirements, not actual requirements.

I've heard a lot of people tell me what the customer "expects". This is a bad policy.

Build the simplest possible thing. If the customer requires more, build more. But build the simplest possible thing first.

  • "Many, many people strive for "ultimate" quality at the expense of something that is (a) simple, (b) reliable and (c) correct." You could have left it at that and I would have voted for it. – corymathews Sep 11 '09 at 17:01
  • "Simplify, simplify." ~ Henry David Thoreau – Gordon Potter Sep 11 '09 at 17:08
  • 2
    Yup... this means premature abstraction, too. If something is only going to have one implementation, don't make it an interface. – Robert Fraser Sep 11 '09 at 21:09
  • 3
    One of my favorite quotes is appropriate in this situation "make something as simple as possible, but no simpler" ~ paraphrase, Albert Einstein – Nemi Sep 16 '09 at 14:00
  • Keep it simple is what even many programmers do not get properly: they fall into the "premature optimization is the root of all evil" trap to easily. Normally the simplest program is the fastest or the one of highest quality. – MP24 Sep 30 '09 at 8:32

Avoid polishing your code to the perfection, just make it work. That's what the business expects.

But often, increasing speed implies sacrificing quality.

  • 10
    I would suggest "making it work" and if time permits getting around to perfecting it ! – Preets Sep 11 '09 at 15:04
  • 28
    -1: There is no reason to sacrifice quality. You can always sacrifice features. – S.Lott Sep 11 '09 at 15:06
  • 6
    I've seen it happen repeatedly. Developers get hung up on the last 1% of a given feature and then play catch-up and fall behind when attempting to complete the remaining features. Complete what is expected of you first, then go back and polish it. – Mayo Sep 11 '09 at 15:06
  • 3
    Often, increasing quality implies increasing speed. If you take a little time to get it right in the first place, you might save more time in testing and debugging. – David Thornley Sep 11 '09 at 17:14
  • 2
    If you're stuck at one feature, work on something different. – mrueg Sep 11 '09 at 21:07

Re-use - I try to factor out any clever bits from previous projects, so I can use them again in future ventures. It's always worth asking yourself "could I use this again someday?"

  • Perfect mind state for faster programming in the long run, although at first it might take more time. – Jay Sep 11 '09 at 16:07
  • 8
    +1: Beware though, I've caught myself generalizing and abstracting something so that I could use it again another day... and missed that day's deadline or doubled the time the bug should have taken to fix... so that I could "maybe" save time later on. – Steven Evers Sep 15 '09 at 5:30
  • 2
    Having a "bag of tricks" is key. If this is becoming a job issue for you, it would be worth putting some of your own time into developing reusable pieces (assuming the domain you work in is amenable to code reuse). – Larry Lustig Oct 9 '09 at 22:06

Keep it simple.

If you use TDD, you should follow "red, green, refactor":

  1. Write a failing test (red). (Often for functionality your code does not yet have.)
  2. Commit horrible coding crimes to get your tests to pass (green). Hardcode if necessary.
  3. Refactor, probably breaking tests for a short while, but overall improving the design.
  • 3
    When doing TDD, you have a test runner that produces a red/green report per test to indicate if they pass. – Frank Schwieterman Sep 11 '09 at 16:22
  • 2
    @Konstantin: Writing some code using TDD might take take 20% longer, but it also yields better code and in the long run, when the system grows, the speed of making changes stays about the same. TDD helps you to avoid technical debt which slows you down. – Esko Luontola Sep 12 '09 at 18:51
  • 3
    Typing has never been the slow part of programming. Even though you need to type more with TDD, it does not slow you down. It might even speed you up, because writing a test first helps you to focus on what is needed before thinking about how to implement it. – Esko Luontola Sep 12 '09 at 18:53
  • 1
    If the management does not understand some key concept, you should explain it to them. For example martinfowler.com/bliki/TechnicalDebt.html – Esko Luontola Sep 12 '09 at 18:54
  • 3
    @Konstantin, if you consider "development" to be the act of writing the code statement, I would agree with you. However, if you consider "development" to include packaging, preparing build notes, deploying, testing, producing defect reports, reviewing and prioritizing defects, task assignment, investigation, debugging and fixing and starting the process over again -- then the 15 minutes to write the unit test outweighs the days and loss of customer confidence 1000x over. – bryanbcook Sep 12 '09 at 19:07

Download all your languages/libraries documentation locally to your computer, then unplug your network cable/turn off Wi-Fi.

Not trying to be funny here. This really helps me!

  • I do the same. – Uri Sep 11 '09 at 15:52
  • Online documentation and troubleshooting searches are so overrated anyway. – Kieveli Sep 12 '09 at 1:32
  • Install a firewall and configure it to block nearly all web access (I have exceptions for a few domains, e.g. MSDN) – finnw Oct 1 '09 at 14:15
  • I'm really considering doing this (the fact that I leave this comment proofs enough) – Ikke Nov 30 '09 at 9:08
  • And lose SO? hell no – ohadsc Jan 5 '10 at 11:53

Notice when you have been reading Stack Overflow for too long. The "Compiling" excuse only works for so long. :)

  • 15
    Depends on how fast your compiler is. So maybe the "solution" is to find slower compiler and run it on Pentium 2 w/ 128MB memory? :-) – Franci Penov Sep 11 '09 at 16:26
  • @Franci, perhaps even putting swap space on a floppy disk. Or two in RAID. – user1249 Dec 27 '10 at 22:52

Avoid switching tasks too often. Distractions and task switching can kill a day, even if you use tools like Mylyn to manage your tasks.

Figure out a granularity (e.g., 30 minutes) and only work on things related to the task at hand. Anything else (new bug reports, emails about other issues, procedural matters that are unrelated) is delayed at least until the "next checkpoint". Make sure to disable popping up email notifications so you won't get sucked in.

It's especially effective if you have a buddy on your team who will let you know if things really melt down and require your immediate attention.

  • This won't work if you have a boss who expects responses to e-mails within 10 minutes. – finnw Oct 1 '09 at 14:16
  • This is actually very relevant. As far as is reasonably possible, do not allow yourself to fall victim to selfish attention-grabbers and stick to your original task. If you allow yourself to become pulled in different directions, the end result is that you achieve nothing instead of something. – AndyUK Nov 15 '10 at 13:28

Do it right, the best way, first time. If that means you have to stop and think about it for a while before you start, then do it. Works 90% of the time.

  • 2
    +1 This is so true. It doesn't mean you have to be "perfect"; all of us will make mistakes. But if we do things the best way possible the first time, the consequence of those mistakes will be much smaller. – James Schek Sep 11 '09 at 16:21
  • +1 - I seem to recall reading somewhere that the difference between good programmers and bad programmers isn't in speed. The difference is that good programmers will keep more of their code. – Jason Baker Sep 30 '09 at 14:03
  • That's my motto, do it the right way, the first time. Don't get in the habit of having to always go back and fix your code, because you didn't do it correctly according to specs. – crosenblum Jul 2 '10 at 19:58
  • "If you don't have time to do it right, how are you going to have time to do it over?" – Alex Feinman Dec 27 '10 at 18:49
  • You may need experiences from the actual software to be able to determine what is the best way. In that case you cannot get it right the first time. – user1249 Sep 9 '11 at 4:09

Learn to touch-type as quickly as possible.

  • 2
    This is a nice bonus...but I don't think it will have much impact overall. Typing code is probably the least time consuming part. (Yes, I followed and read the link. I just don't agree with him.) – Beska Sep 11 '09 at 20:56
  • If the limiting factor of your coding is how fast you type stuff in, you're probably working at the wrong level of abstraction. – Pete Kirkham Oct 2 '09 at 11:12
  • +1. A great link, a great article for those who read it to the end ;) I was typing well, but it inspired me to switch to Programmer Dvorak keyboard layout en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard (but I switched the '" and -_ keys with Microsoft Keyboard Layout Creator), and I'm sure that soon I'll be typing much faster :) See also: typematrix.com/dvorak – Roman Boiko Aug 1 '10 at 17:38

I do it tomorrow.

Getting Things Done is also immensely helpful.

I have a short attention span anyway, so these books help me keep my foc... what was I doing again?


Practice and hard work.

You need to put the time and effort in. As you become more comfortable and confident with whatever tools your using, speed and creativity should follow.

If you want to improve any particular skill, it may also help to design exercises which will let you work specifically on that. If your slowness is in the design phase, try to find design problems to work on online. Redoing the same exercise will let you complete it faster and practice speed. I personally like TopCoder's algorithm exercises for practising sheer programming speed. They have design challenges too, but I have not tried them.

  • Practice is often underestimated in programming. This should have been one of the top 5 answers. – Jørgen Fogh Sep 18 '09 at 13:48
  • Wow. Not sure why it's not higher either. I haven't really ever tried this. I'll give it a shot! – David Mar 29 '11 at 3:55

Learn about The Zone, learn how to get yourself into it, and learn how to recognize when you aren't in it.

Once I am "in the zone" I am extremely productive and code just flows out of me, often I can get 2 or 3 days coding done in 1 day. But I find that often its hard to get to that place, I find myself procrastinating, getting distracted by other things (Stack Overflow for example).

Quote from what-tricks-do-you-use-to-get-yourself-in-the-zone

  • And skip lunch if you're in the zone... or stay late... MMMmm the Zone. drool – Kieveli Sep 12 '09 at 1:33

Knowing your IDE and framework well. Having to turn to Google for every little thing takes time.

  • But also realizing when you do need to Google and being able to do it quickly is important. – statenjason Oct 7 '09 at 20:55


  • 1
    Please edit this so I can upvote it, it is currently "too old". – kmarsh Nov 25 '09 at 12:59
  • 1
    Strongly dependent on what you need to use it for though. – user1249 Dec 27 '10 at 22:54

Before you start developing:

  • Log out of your mailbox
  • Turn off any IM clients
  • Politely ask peers to give you time to concentrate
  • Of course, stop surfing the Internet

Every time you're interrupted, you'll slow down as it takes your mind time to get back on track with its thoughts. I've heard figures that for each interruption, it takes the human mind 5-10 minutes to reset back to the thought process it had before the interruption. With that much time per interruption, it doesn't take much to waste the whole day.

People in our company have actually taken to blocking off time in their calendars and then moving to an empty conference room for a couple of hours each day.


Learn your development IDE in and out. Learn the shortcut keys. Learn to use the mouse less. I find that this saves much time for me.


Are you slower than your colleagues, or are your estimates more overoptimistic?


To produce software faster, I've found the best thing to do is to learn your runtime API as best as possible. Don't type out list logic when a LINQ extension will do; don't build a bunch of event listeners when binding will work, etc.

As far as estimation, that comes with experience. You can make use of estimation software out there to help you figure out better estimates.

Personally, I found with junior level developers, take whatever their initial estimate is and multiply it by 2, then double it. This will account for all of the learning, meetings, wasted time, etc. The more senior level developers tend to work at a factor of 2 over their estimates.

Often times, the question is not if your estimate was wrong. It's did your estimate account for all the right things? Are you giving your estimates and timelines in terms of coding effort or in terms of calendar time? Think about all the time in your day and how much of it is actual, productive coding vs. meetings, learning, debugging, etc.

  • 3
    "...multiply it by 2, then double it." Since you're interested in saving time, I've got a math tip for you that you might be able to use... – Beska Sep 11 '09 at 17:31
  • LOL--I know what you're saying. But you'll be amazed by often this slips by unnoticed, as opposed to saying "multiply by 4". – James Schek Sep 15 '09 at 2:16

Two things that might be implied, but I haven't seen among the answers here yet that increases productivity are:

  • Use some sort of build and deployment scripts. Compiling, deploying, restarting app-server and such musn't suck up either time or focus, it should be a one-click kind of thing.

  • Have some sort of version control. Having to code without being able to roll back a change is like trying to walk on eggs


A couple of ideas come to mind:

  1. Get other opinions on your estimates - Are there other developers that you could ask something like "Hey, do you think you can get this kind of feature done in this timeframe?" The idea being that other people's input may help with accuracy in some cases as someone may note a bunch of things you missed in making the estimate.

  2. Hone your estimation skill - Start tracking how off you are on the estimates and why you are off: Are other work items causing deadlines to not be met? Are you consistently underestimating how complicated something is? Are you giving an entire timeline when it isn't practical,e.g. what is asked is vague enough that merely getting a prototype up will take weeks and then there should be a re-evaluation of what else is to be done? Doing this may help the most in building that skill so that if you say something will take x hours, you can have confidence in that because you have done it over and over and over again. An alternative way to state this is merely practice, practice, practice.

Granted you probably already considered these, but I just thought it worthwhile to state this for those others out there that may not have considered these ideas.

  1. Know the technology inside and out.
  2. Stop! Think! Go!
  3. Architect for whatever may arise, but implement only what is really asked for.
  4. KISS - Keep It Simple Stupid
  5. If it is getting too complex, probably, it is not well thought. (Go back to 2 and 4)
  6. Don't get stuck in 5. It often pays to start from scratch (Go back to 2 and 4)
  7. Go back to 1.

I think they key word here is "timeliness". They didn't say you were too slow, rather that you were not timely.

In project management, it is important for the manager to be able to estimate when your work items will be complete with accuracy. I suspect that the main reason why your efforts were not deemed to be timely is that you frequently had items that were not delivered on schedule, and were delivered much later than scheduled.

To improve your timeliness, you might want to spend more time understanding how long it will take you to complete a particular work item given your skills, experience, and the domain. This will allow you to give better estimates to your project manager. The key here is "better" ... you could deliver on time more frequently by padding everything with a fudge factor, but what you really want to strive for is a more accurate estimate.

I would discuss this with your manager to see if this is actually the issue. Otherwise, you might end up programming twice as fast, promising things in half the time you used to, and still getting criticized for your timeliness because your estimates will still have the same error factor.

  • "...Spend more time understanding how long it will take you to complete a particular work item given your skills, experience, and the domain." -> Right, and this will also help you to trim scope and save you even more time. – Jim G. Sep 12 '09 at 15:43
  • It will also help your manager look good to those around them - It also allows supporting materials such as marketing to be completed in sync with your project. – Tom leys Sep 29 '09 at 2:01

Get stable, stay stable.

Build something that implements a small bit of the functionality, and make sure it works, end-to-end. Then, keep it working as you add new bits of functionality. Yeah, this is partly a TDD practice, but it makes sense even if you don't do TDD.

The rationale is that every time I've seen someone with 2 weeks of code that had never been stable, it always takes another 2 weeks to get it stable.

If you stay stable, you remove that uncertainty, and also give yourself a way to scope down near the deadline if necessary.

The obvious counter-argument is that doing this will take more time than just writing it once, as you will do extra work be stabilizing non-final code. I don't buy this for a second. When you have code that works, you change 5 lines, and something breaks, you know exactly where the break must have happened.

If you have 10,000 lines of code that never worked, and you have to find a break, you have a ton of code to search through.

Small, incremental changes on a system that is consistently stable FTW. Go slow to go fast.


For me, getting good productivity is having a clear idea about what you are trying to achieve, and how you will get there.

  • 1
    My 30-minute cycle ride to work through the Norwegian countryside is also pretty good at clearing the mind and getting the creative processes going. – mdma May 30 '10 at 15:24

Pretty much all the answers have been said to death in numerous places here and elsewhere. Or, at least I've heard it to death. Learn your IDE, learn to type faster, use frameworks, use code generation, etc., etc. Yes of course these things will help and I doubt there are many programmers who are masters of them all. But being the type of programmer that asks these questions and frequents sites like Stack Overflow you knew these things already. Did you merely want to here them repeated or did you just want to vent a little?

But what if we were able to get to that state? I mean master all these suggestions? What would happen then? Well. I'd guess that time-lines will be reduced even further. And again, we'll revert to a perception of quality. I mean, our craft has definitely progressed and become more and more productive over the decades. But has quality increased during this time (excluding the very early years of course)?

My answer is simple: quality software takes time! You can only trade one for the other (quality/speed). But yes we all know that however we're not honest about the degree to which that trade-off often ends up on the speed end of the scale. And we are even greater liars early on in projects!

I say that you are not at fault here. The problem is the perception people have of how long quality software should take. We fool ourselves in believing we are capable of creating quality software with the types of time-lines our managers or even we guesstimate. We do not make quality software. We write software that works but sometimes with flashes of quality in certain corners of an application.

So what can we do about this? We can't just convince our bosses that we need to double or triple the investment in each of our projects. I say lead by example. Create a truly great piece of software as a side project. Put your own time into it and do not compromise. All the while pay attention to how you progress. Make note of the apparently unrelated tasks you've had to put an unexpected amount of time in and see if you can justify it. Contrast this with all the other projects you've worked. Be brutally honest with yourself and all aspects of this analysis. Can the extra things you did with your quality software be neglected in "real" projects at work? But maybe your attempt failed. What was the reason? Did you get bored and just rushed to get the core features done? I've yet to do something like this myself which is why I end off this thought with some doubt - but I intend to give it a real go. I'll keep you posted :).

Finally, I think most (if not all) performance evaluations are twisted and extraordinarily manipulative. You can't throttle quality and speed at 100%. Your boss should be scoring you against a standard that is set by the organization. The organization's standard on the trade-off between quality and speed. Lets imagine that OrangeSoft Inc. expects 33% quality and 66% speed. So if you're writing code that has maybe a third of the unit tests it should but making it up with speed and reduced delivery time you should score near 100% on your review! (These are pretty rough analogies but you get the point). But instead, what happens is that Bob writes code extremely fast but which is notoriously buggy. So on his performance review he'll score 3/5 for quality and 5/5 for speed. Carol on the other hand writes code much slower but produces significantly less bugs. She scores 5/5 for quality but 3/5 for speed. Either way Bob and Carol get docked on their raise. Is it possible for any employee to get a perfect score? Is this fair?


The technique that I use is evolutionary prototyping

You can google for more info - but if the need is to produce something quickly, it's about the only way to go. Plus, it has the benefit that when the users says that he likes it, your'e done (... and can start doing the documentation).

Not the answer you're looking for? Browse other questions tagged or ask your own question.