In his book, Joel on Software, Joel Spolsky talks about many dynamics of the software development business. His unpretentious and engaging writing style is just a mild benefit compared to the enormous wealth of practical knowledge he imparts on his readers. From office space to writing functional specs and readable code, Joel writes about no-nonsense methods and practices that make the software development business a bit less painful.
A couple of the things he offers advice on that I’ve seen at the higher corporate level this summer are project scheduling and time estimation. Debugging and testing by the authoring programmer will take just as long as writing the code in the first place. This seems to be a common mistake among organizations, especially at the corporate level. When schedules are constructed, they’re based on number of days per feature to be written, tacking on a few days or less for random hindrances. This is simply not enough time to properly write and debug the new feature.
I’m a victim of the skewed mindset as well, though, so I need to factor in my debugging time when I give my estimates and explain that the first half of it is creation and the second verification. There are a few small things like this at the corporate level that may strike one as strange or lacking, but by and large, things are nice. One thing I highly recommend is finding a manager that is interested in your general well-being and the fact that you have a life outside of work. Having a normal and compassionate manager might be the deciding factor when it comes to balancing your job, your life, and your sanity.
That said, I strongly encourage every CS major to find a summer internship at the corporate level. If nothing else it will give a taste of what’s out there and might help shape post-graduation plans. Also, I highly recommend Joel on Software and his books, as they provide realistic and usable advice that will undoubtedly change your software-oriented life in some way.
[...] As with many other mistakes in the software industry, crunch time is a result of poor planning and a lack of understanding of the overall process. If your team has to spend two or three weeks at the end of every product cycle scrambling to get things done for the release, either there are too many features or the ship date wasn’t realistic for all of the standard parts of the development process that must be completed. Failing to schedule things like proper debugging time or details of necessary features lead to unrealistic ship dates and thus unrealistic demands from management to meet unrealistic ship dates. [...]