In the ten years or so I've been out of school, I've gotten to experience a handful of environments and styles. I started on a large development team in a huge organization and did some solo contracting work during that time. Once I transitioned to my current job, I developed solo for a while when the company was about half of the size it is now. As we've grown and I've grown my team, I've moved into managing a small group of developers on which my role is mostly advising and minimally developing.
Through those transitions, I've settled in on a few guiding principles that work for me. They might now work for everyone, but here goes:
Wiki Requirements: I like a living, breathing collection of requirements which my team and our end user or customer both have read / write access to. I also think it needs to have a single home instead of living in an office file which starts on a network drive and then gets duplicated into twenty different versions. It's best to keep it dead simple and in plain english. If everyone can read and understand it, it serves as an informal contract we can all refer back to. (This doesn't have to live on a wiki, but it's a pretty natural fit.)
Fast Iterations: The agile school definitely did get this one right. The faster we can put functionality in front of an end user and get their feedback on it, the faster we know if we got it right. It's almost impossible to hand over a product that doesn't meet your customers' needs if you work in short development cycles and constantly get feedback along the way.
Find the right users for beta testing: Anyone who's done software will understand this one. The wrong users will give you vague, generally not very useful feedback. You won't get much insight into how you can make your product better.
If you don't have the right users, design your software to tell you when it breaks: The original Pragmatic Programmer gets credit for this one. It's particularly useful when your portfolio of applications has a significant number of background tasks. Unless you have a reliable way of being notified when a process goes awry or encounters data that causes it to throw an exception, you won't know about it. Nobody I know is diligent enough to review logs everyday. Don't kid yourself.
Painless Documentation: I know plenty of developers who'll tell you that good code negates the need for heavy documentation or that good code is your documentation. In practice, particularly with a language like Ruby, this can be pretty close to the truth. However, it's usually not sufficient. Between tools like RDoc and JavaDoc, adding meaningful, high-level explanations inline with classes and methods is so easy that it's almost seamless. I like to explain the context or the thought process which led to a particular approach here, since that's usually the first thing I forget when moving on to another project. If you write clean code and abstract everything properly, your code can come pretty close to speaking for itself otherwise.
This is such a massive topic that I've only barely scratched the surface. I could probably write another 50 posts on it and still just cover only a fraction of the body of knowledge out there. But it's a start.
