Showing posts with label Theory. Show all posts
Showing posts with label Theory. Show all posts

Saturday, December 05, 2009

Who is your hero systems engineer?

These days, I‘m inquiring about engineering. I‘d like to know who your hero systems engineer was or is (or will be?). Please comment, or send me a twitter message. Thank you!

Thank you again for making it past the first paragraph. ;-) It all started when a couple of weeks ago I again was confronted with a colleague‘s opinion which said that I am a theorist. I refuse this opinion vehemently; quite the contrary, I believe my work, especially my work for the company, is a paragon of pragmatism. ;-)
So my argument against the opinion usually is ,no, I‘m not a theorist!', in a more or less agitated voice. Obviously, I need a better basis for making that point. Kurt Lewin said:
Nothing is a s practical as a good theory.
I used this sentence for a while as a footer for email that I suspected to raise the ,theorist‘ criticism again.
After all this sentence is only a claim as well, just like my stubborn phrase above. It may be stronger because it carries Lewin‘s weight. Unfortunately very few people instantly know who Kurt Lewin was, and that he most of all used experience - not theory - to advance humankind.

Then a friend of mine, a U. S. citizen who at some point in time chose to live in Norway (which is a very practical move in my eyes :-), pointed me to the work of Billy V. Koen, Professor for Mechanical Engineering at the University of Texas. You should watch this 1 hour movie if you are least interested in engineering, philosophy and art. Or in more mundane things like best practices, methods, techniques, recipes, and checklists, many of which concerning business analysis and project management can be found at Planet Project in case you don‘t know.

Here is Prof. Koen‘s definition of engineering from the movie:
The Engineering Method (Design) is the use of heuristics to cause the best change in an uncertain situation within the available resources.
Causing change in an uncertain situation within the available resources sounds a lot like project management to me. Like program or portfolio management, too. Maybe like management in general.

It is always when an improbable connection opens up between two different fields of my thinking when I find there is useful truth in it. Next, I want to learn about engineering and me, and one way to approach this is to find out who I admire for his or her engineering skills. I tried thinking of a couple of candidate names and found surprisingly few. I‘ve already identified Leonardo Da Vinci (who is not a Dan Brown invention like my nephew once suggested. :-) A quick request to the twitterverse offered nothing, no new name.

So this is my next take: I‘d like to know who your hero systems engineer was or is (or will be?), and why. Please comment, or send me a (twitter) message. Thank you!

Monday, July 13, 2009

Levels of Spec Principle, Non-Functional Requirements

Follow me on Twitter: @rolfgoetz

Just a quick remark: I added a grammar representation to the "levels of specification principle" on PlanetProject. For those of you who like precision. 
If my boss sees this, he again will call me a "theorist." :-)


Monday, October 13, 2008

How to Tell Principles from Paradigms

Name: How to Tell Principles from Paradigms
Type: Principles (or Paradigms :-?)
Status: final
Version: 2008-10-13
Source: Covey, 7 Habits of Highly Effective People

Gist: If you - like me - like to be picky with words sometimes, here's a nice explanation on two words we use over and over again. It started me thinking about what I give the 'principles' tag here on my blog. I will put more work on all the existing principles here, in order to better distinguish principles from other things.

Principles
Principles describe the way things are, like the law of gravity.
Principles represent natural laws, the reality
Principles are sustainable and timeless
Principles are self-evident & self-validating
Principles can't be faked, you're not in control of them
Principles will remain constant and universal
Principles ultimately govern

Paradigms
Paradigms are mental images of the way things are. ´Hence, a paradigm can be some one's mental image of a principle.
Paradigms represent implicit assumptions of our lives
Paradigms are projection of our background
Paradigms reveals my world view, my autobiography
Paradigms can change with my thinking

Thursday, July 26, 2007

Optimizing subsystems does not help optimizing IT costs

Title: Optimizing subsystems does not help optimizing IT costs
Type: theory
Status: final
Version. 2007-07-26
Source: Chris Matts, Gilb Seminar, London, 2007

The IT world is misperforming when trying to optimize IT costs, because when one subsystem is optimized normally the performance of the surrounding systems decreases.
We have to optimize the whole.
At Toyota, they even optimized their suppliers (and customers?).

Same thing with single projects. Most of the time it is easier to solve a problem by means of thinking out side the box of this praticular project.

Wednesday, April 18, 2007

Nonfunctional requirements and level of specification

Name: Nonfunctional requirements and level of specification
Type: Theory
Version: 2007-04-18
Source: My friend Sven

"The higher the level of a system's requirements specification, the greater the portion of non-functional requirements."

This is, because no computer system can directly realise a non-functional requirement; it has to be broken down to a set of functional requirements. This set interacts and thereby attains (or does not attain) a certain non-functional attribute.

Sven's sentence describes a necessary characteristic of good specifications. In other words if you find a high-level spec with few or no non-functional requirements, it does not mean it is not high-level. It probably means that the author forgot to include non-functional requirements.

Also, "portion" is maybe not the correct term (he used the German "Anteil"), but I think the idea is clear.