Quote:
Originally Posted by sobecash
In my experience, those who are currently programmers who had no prior corporate training and experience, or who did not go through programming courses, have problems with documentation.
On the other hand, I remember the time when IBM was pushing their standards on every big project, where 80% of the time is spent on design and validation, prior to coding.
The fine line right now in webdev is that of getting the project running online, and fixing it as it goes. Kind of like the Yorktown getting fixed at sea while en route from the Battle of the Coral Sea right to the Battle of Midway.
|
Prototyping is not the most efficient way to program, it is the fastest way to show results though, so 'cause of pressure from anybody that doesn't know programming it's often used as the way to go. Admitted: I also prototype a lot. I'd like to know at an early point whether something works or not, so I make a proof-of-concept to play around with before I build. Not really prototyping, but the next bad thing
...
It works though. Although fixing one thing might mean you're breaking something else. That's why I'm all for documenting right, create API's to enable different programmers can work on the same thing and not mess with the lower layers when they don't have to. Data abstraction is a good thing! It might cause some overhead (and I hate wasting resources usually), but there is the law of diminishing returns which means that it's good to have some overhead if that overhead will be made back by maintainability. Well, actually the law describes the opposite where you shouldn't put more effort in something than it makes back, but it comes down to the same thing...