in reply to Does anybody write tests first?
The trick is to truly design it, completely, first. Yes, all of it. (Oh yes, you can!)
As we all know, the hardest thing about computer programming, if there is a “hard part,” is deciding what to do; not the fairly-rote procedure of actually doing it. But people drop into this self-taught mentality of “just banging stuff out,” just like they first did when they were mastering the language. And then they get to be managers, or worse, and they're still doing it all the same way – they're “just banging stuff out.” Without management-skill (which generally has not too much to do with programming-skill), projects are always missing deadlines and expectations, which those people mistake for “gee, programming sure is hard work.” They vindicate their own actions to themselves, because it's always been this way (for them...), and they never realize that there could be a better way. So, some very smart, very sincere, very well-intentioned people can go an entire career and never bother to learn how the process works. (They think they know.)
You've heard it: “Don't just plan there! Do something!” :-/
When a project gets big or important, it's no longer adequate for “one person” to be making all of the decisions. Not only is this impractical from a timing standpoint, but the true complexity of the project reaches a point where a single individual is not likely to possess all of the essential experience. You need to have several active brains on the project, with eyes wide open and individual responsibilities, and with the sanction to disagree with one another... and with you. To make a project of any size really work, you must borrow from the greater field of engineering discipline and formalize the task of project management, as well as the programming, the documenting, the testing and all the other “technical” things. You can be responsible for a project, and be very pivotal in making it succeed, and not write a single line of the source-code yourself.
O'Reilly has recently published a definitive book (which doesn't have an animal on the cover...) called The Art of Project Management, by Scott Berkun, (ISBN-13: 978-0-596-00786-7) which should be required reading. In a similar vein is Debugging the Development Process, published by Microsoft Press. (It's part of their “Software Engineering Classics” boxed-set.)
I like to remind people that if you wanted to get a new addition built onto your house, and the first day the guy showed up with all his workmen and they started cutting boards and banging nails while the foreman went inside to ask you what you wanted ... if as the days went on they built something and tore it down and built something else, obviously “just making it up as they went along” ... why, you'd throw that guy out of what's left of your house and call your lawyer! So why this sort of nonsense is deemed to be de rigueur in a software project is quite beyond me. But it happens every day, and millions of dollars get blown that way.
You can do these things on a smaller scale too; make it part of your overall daily practice. First of all, you need to plan ahead so that you're not bumping into “crisis mode” and throwing every concern out-the-window. (Never agree to a “schedule” that you don't agree with. Never work to a “wiki” as a spec.) Instead of building a great-big thing only to discover that it doesn't work and have to scrap it, probe the entire project from a higher-level before you start ... looking everywhere the waters seem to be disturbed to explore what kind of rocks might be underneath that particular area. In the case of Perl, use CPAN (and this forum!) very aggressively so that you can take advantage of someone else's experiences (ka-whack! ouch!!) rather than repeating them.
Microsoft Project® can be your greatest ally: you can “work it out on paper!” If you can't say day-for-day what you're going to be doing and what milestones you will reach, you're not ready to start work. If you find that you're not hitting your deadlines squarely, you need to stop right away and fix your schedule: the schedule reflects the plan, so if the schedule's non-functional, so must be your plan... and the schedule is simply your bellwether; your canary.