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 46682
To view parent comment, click here.
To read all comments associated with this story, please click here.
corentin
Member since:
2005-08-08

> ...and I will tell you that the best code I ever wrote was for DEC because we had rules to follow. Coding standards, review processes in place, documentation throughout the life cycle, etc.

That is funny, because I just thought of DEC yesterday when reading this thread ;)

You did not wrote the best code ever because you followed rule X or Y; you wrote the best code ever because everyone at Digital (including the managers) cared about, *and was proud of*, the quality of their products (and as a direct result, you used the right tools to obtain quality).

Reply Parent Score: 1

Tuishimi Member since:
2005-07-06

Yes... and because of that processes and procedures were followed/enforced. ;) Let me give you an example: 2 years ago I and a several others were asked to come up with a design and based on requirements (this was not at DEC). We designed it, then provided them with estimates for man hours and also cautioned them that just throwing people at it would not get it done faster, yadda yadda.
They did not like our answer and trimmed their requirements. We like-wise spent another few weeks coming back to them with the revised estimate of (roughly here) 10 months from start to user test (not QA - a sort of Beta version). They said "we'll go with that but you only have 6 months!"

I mean what is that?!?! Talk about cutting corners here and there. And frankly, developers are notoriously optimistic about their estimates (forgetting about the daily interruptions and such).

I don't know. I mean, I understand that it is important to get products out the door... new and improved! Make more $$$... but it seems like they would rather send something out buggy than send it out done right.

Reply Parent Score: 1

Member since:

The old Rule #1 of product development was: There is never enough time to do it right, but there is always enough time to do it over.

And now, with accelerated release schedules and people working on more than one product at the same time, there is rarely enough time to do it over. Just fix the bugs.

So the new Rule #1 is: ./configure, make, make install, release.

Reply Parent Score: 0

Tuishimi Member since:
2005-07-06

Btw... I guess I don't disagree with you. ;)

Reply Parent Score: 1