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 46674
To read all comments associated with this story, please click here.
Tuishimi
Member since:
2005-07-06

...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.

Every where else I have been they have tried to do it. Not with a ton of success. But these new trends... I just don't know. I guess I am old fashioned where I believe 90% of the code is written in the requirements and the functional specification before the actual coding ever begins. By that, I mean the requirements have to be good, the functional design has to be good, THEN the basic functional test plan should be in place and THEN begin with the design specifications.

But these days it goes like this: You have 2 months to do X Y Z. Now get to it and DO IT RIGHT! Well, the battle is already lost at this point. Software engineers are no longer allowed to "engineer". That's why we are all becoming "programmers" and "developers".

:(

Reply Score: 5

Tuishimi Member since:
2005-07-06

And when I say "90% of the code is already written" I meant it figuratively. It is done on paper or in your head because if you have all the data and the processes defined well, that is more than half the battle.

Reply Parent Score: 1

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

Tuishimi Member since:
2005-07-06

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

Reply Parent Score: 1