OK, for all you Nerd Girls out there who know what its like to have a tight timeframe on a project that you are trying to get out the door, lets talk about the first thing that gets cut every time something slips in your schedule because, Murphy’s Law, something’s inevitably goes wrong. QA - or Quality Assurance. How do you deal with having to cut down on your QA time, which ultimately puts the quality of your project in jeopardy?

I think of the KISS principle, Keep It Simple, Stupid.  I always try to make sure the basics work and have been tested before we add the extras. This is hard to do because engineers like to perfect everything, but if things are too complicated and the schedule is tight (like it always is), nothing is complete if the system is too complicated :-) .  We got a car to the DARPA grand challenge qualifying trials in 9 months starting from zero by keeping everything as simple as we could, and focuses on the basics, not the frills.

I think the first thing that goes is documentation with the promise that I will go back later and take care of it.

I would agree that both the documentation and QA are first to go. There are many development plans- such as Agile or RUP which work on the concept of a redundant and repetitive life cycle. This is something I try to keep in mind as I plan out projects. First prove the small architecture, then go back and add to it, and so on and so forth. 

Another problem I have found is that I will insist on getting the work done, even if the inputs have changed, the result ends up being less free time.  I do this less now then I used to however!

I would agree that documentation falls under QA. As time goes on you should record everything so if something goes wrong you can check the records and fix the problem. Therfore placing it under QA.

Interestingly, when I worked as a technical writer/trainer I found that I ended up doing broader QA then the actual QA department.  This was particularly due to trying to learn how to run the new software functionalities in the bigger picture.  Most small software companies I know don’t even have technical writing.  Many that do, the writing is so vague that you need to be a psychoc to understand it. :)

I agree, documenting as you go along is very important! 

I need to remember to include more time in my project estimates for documentation.

I’m that odd programmer who loves to do the tech writing for the project I’m working on.

It’s just that I’m _never_ given the time I need within the project deadline to do that writing!

My approach to preventing QA time tends to be to reuse as much code as I can, and to design the architecture with future improvements in mind. That way when QA finds a break in a part of the code, I only have to fix it in one place. (Or if using a language that prevents me from modularizing at least the fix is the same in multiple places.) Further, when its found that something is broken (oops! I forgot to program for such and such screen resolution) I can just upgrade that architecture section to my newer version. I also try to be good about testing things as I go along.