The axioms I run across are far more like one guy who believes "Software should be complete and should gracefully handle error conditions." versus a guy who really believes that 'Software should be written on time and should be clean and efficient code.'
Which axiom is 'right'? For me they both are, but to varying degrees at different times in the design process. And they come into conflict some of the time, but not all the time. Sometimes the decisions they make are the same. Sometimes they're wildly different because of the emphasis they have. That's when I hear one guy muttering about 'slack bastard' and the other muttering about 'turn a perfectly elegant solution that *works* from one page to twenty of illegible code.' Which is right? It may not matter when the real problem is 'what did will take care of the problems the user sees?'
Again, your 'if' makes for a particular kind of context. If it were in the medical equipment shop I once interviewed at the question of databases would never have come up because they only had one that was tested enough for FDA approval. If it were in another software shop I was working at, the real question would have been 'Process, WHAT process?' At yet another, where engineering was told, point-blank, "you do NOT figure out requirements or specifications you code what we tell you", then implementation is where they always started.
Sure. Given a context, there is usually a more efficient and better way to do anything, plus an answer that can be obviously correct to all involved. Given any group of engineers, we usually find something that satisfies the requirements and is sweet to build, that, for us, is 'right' and true. But to assume that it'll work everywhere leads to the engineer that tries using one technique on every problem they face.
no subject
The axioms I run across are far more like one guy who believes "Software should be complete and should gracefully handle error conditions." versus a guy who really believes that 'Software should be written on time and should be clean and efficient code.'
Which axiom is 'right'? For me they both are, but to varying degrees at different times in the design process. And they come into conflict some of the time, but not all the time. Sometimes the decisions they make are the same. Sometimes they're wildly different because of the emphasis they have. That's when I hear one guy muttering about 'slack bastard' and the other muttering about 'turn a perfectly elegant solution that *works* from one page to twenty of illegible code.' Which is right? It may not matter when the real problem is 'what did will take care of the problems the user sees?'
Again, your 'if' makes for a particular kind of context. If it were in the medical equipment shop I once interviewed at the question of databases would never have come up because they only had one that was tested enough for FDA approval. If it were in another software shop I was working at, the real question would have been 'Process, WHAT process?' At yet another, where engineering was told, point-blank, "you do NOT figure out requirements or specifications you code what we tell you", then implementation is where they always started.
Sure. Given a context, there is usually a more efficient and better way to do anything, plus an answer that can be obviously correct to all involved. Given any group of engineers, we usually find something that satisfies the requirements and is sweet to build, that, for us, is 'right' and true. But to assume that it'll work everywhere leads to the engineer that tries using one technique on every problem they face.