Hi,
When there is no explict rules about something , I ofter hear the words "use your engineering judgement to make the decision". How do you understand "engineering judgement"? What are the things we shared or believed in in common as an (software) engineer when we make decision? What is your personal "checklist" when you are making a engineering judgement?
I see engineering as being about resolving tensions between different requirements, trading -off.
For example we might trade-off code complexity agaist flexibility.
So there are two parts to this.
1). We understand the forces. We understand the implications of the design alternatives. Note for example that the GOF Design Patterns explicitly have a consequences section.
2). We make tough decisions - here's where the judgement comes into play.
As for specific check-lists, often it's the non-functional requirements that come in to play: scalability, mainatainability, operability, performance ...
Make a nice scalable architecture, but it's more complex to operate. Is that appropriate? It becomes a judgement call. Experienced engineers make such calls, but it's extremeky difficult to codify the weightings they are applying when making such calls.
First of all, Djna provided a great glass-half-full answer.
There's also a half-glass-empty answer :-)
Too often, "Engineering Judgement" is another way for a manager to say he has no idea how to do something right, or how long it will take. In this case, this term means "I don't want to, or don't know how to, decompose this problem into pieces we can analyze. Use your gut instead."
Not sure what context you hear that expression in, but to me, the "engineering judgement" would be to always assume the worst case and always assume that things will go wrong - in the worst possible way they can.
So it's a mindset of always making sure that even in the worst of cases, your system doesn't crash and burn horribly, but still manages to save itself or at least shut down in a decent manner.
While many manager always like to think in terms of opportunities and the rosy outlook, the engineers know about the horrible truth of catastrophic failures and plan for it :-)
Marc
Good judgement is the fruit of much experience.
Much experience is the fruit of bad judgement.
When a manager tells you to use your judgement, it's because he has insufficient detailed contact with the immediate problem (not necessarily a bad thing if he is doing his job of keeping the team shielded from unproductive outside distraction), so cannot advise. It's shorthand for saying "You (should) have done the similar sort of thing often enough in the past to know what is the likely best choice in the circumstances."
I mostly agree with djna's answer: In any project, there comes a point when a decision is needed between two opposite principles.
The most obvious example is speed vs. quality: I can either hack out a fast solution that works (maybe), but is a nightmare to maintain, or I can take more time to produce a solution that works (most probably) and is easy to maintain.
I know, many people will say that the decision should always be in favour of quality. Well folks, if something in the production system in my company breaks, and every hour we have to stop production costs several thousand Euros, you better solve it fast, any other decision is wrong.
Clearly, this decision has to be made by someone who understands all the issues at hand and has the necessary information (or the ability to retrieve it). In technical projects, this person will (well, should) be an engineer. Applying his trained, professional judgement on those matters is the most important contribution that person will make to the whole project.
And all you software developers who think of themselves as craftsmen as opposed to engineers (yes Mr. Atwood, I'm talking to you): If you ever made such a decision in a software project, you are software engineers. Sorry.