This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Engineering
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
I would say that most people think "engineering" as designing using mathematical principles -- a [1] structural engineer who uses equations from handbooks to verify that the building the architect designed won't fall down. [2] Or a chemical engineer who uses equations from handbooks to verify that X amount of heat will be generated from a chemical process that takes in W and Z amounts of various chemicals that will be used in a factory to create certain plastics. [3] The "Army Corp of Engineers" is mostly seen as building dikes and bridges, not as designing solutions.
To argue that software development is engineering will result in arguing whether any mathematical principles apply to the design, to what extent, and also bring in confusion about manufacturing and construction, and reinforce waterfall notions of design, then implement, then test. While there certainly are some mathematical principles involved in computer science, that isn't the problem we have in developing software.
To instead argue that software development is a cooperative "game" in creating and deploying "knowledge" and various people-oriented practices help make that work (which allows talking about getting customers, testers, and developers talking instead of writing documents, and inverting design-implement-test waterfall to XP-style test, then implement, then design) gets the conversation away from arguing about definitions on "engineering" that neither participant really understands (and analogies to construction that really don't apply).
In my examples 1,2, and 3, the "engineer" doesn't need to talk to "customer" much at all. In [1], the architect talks to the customer so the structural engineer doesn't have to. In [2], there probably is some direct communication, but possibly not if a "plant process designer" has just delegated some work to the chemical engineer. In [3] the conversation is limited to "stop this river from flooding this subdivision" or "get those tanks across that river" -- the amount of "knowledge" to be generated is very limited compared to the literally millions of decisions necessary to have a team write a million lines of source code.
Previous Topic
