Linked by Thom Holwerda on Mon 17th Oct 2005 20:27 UTC
Features, Office "No one makes bad software on purpose. No benevolent programmer has ever sat down, planning out weeks of work, with the intention of frustrating people and making them cry. Bad software, or bad anything, happens because making things is hard, making good things doubly so."
Thread beginning with comment 46501
To view parent comment, click here.
To read all comments associated with this story, please click here.

Member since:

Without the right tools, a good requirements spec, unit tests, acceptance tests, usability tests, smoke tests, a daily or continuous build, revision control, a change control plan, defect tracking software, code reviews, well-defined milestones, and a reasonable budget and timeline, I'm sure that writing good software would be very difficult.

It is indeed. My company has treated me (personally) extremely well. The biggest stress I have has been due to schedules that Development has to meet but has no input into. For example:

- I've added features days before official GM, and sent out products and updates with no testing AT ALL beyond a quick run through on my development machine.

- It's no joke to say that I spend more time on exotic new UI elements some suit envisions than on the functionality they control.

- I've had a salesman promise a product he'd never seen to a big account, say he'd have it for them in a month, then call and tell us the good news. This is where our schedules usually come from.

Of the list above, we do have decent tools, revision control, we do continuous builds, and Code Reviews (when debugging something somebody else wrote.) So far we've been very lucky with our products being reasonably stable once they hit market (never mind who this is or what we make, but if you've been in your local electronic retailer in the last few years, etc, you've probably seen it.)

Welcome to the real world!

Reply Parent Score: 2