" It is time to grow out of the craftsman era of programming. Construction-engineering design is based on form and function, using details like strength of materials, cost, and availability for selection of components. Programming construction should move toward the engineering concepts of form and function and away from the hand design and building each piece of code. Craftsmanship belongs in the artistic endeavors of design, not in the detail work of joining bricks with mortar, or lines of instructions. "
From: http://www.byte.com/column/infielder/BYT20000322S0001
An idea whose time has come again and again and again...
For some reason it has always seemed to me that the term software engineering contains some very optimistic assumptions about the nature of reality. Engineering moves forward on the analysis and prevention of failure, very few segments of the software industry follow this metaphor. In fact software systems in general seem to work on a satisficing basis, where speed and ability to exploit new niches count more than correctness and perfection.
SoftwareEngineeringIsaVeryOptimisticTerm?
Of course there are some situations where you want the most detail-oriented anal-retentive white-shirt and pocket protector takes-himself-very-seriously and truly professional attitude Engineer with a capital E working on the software and the hardware for the system.
see TheracTwentyFive for one example or SelfDrivingCars? for another.
But those are niche products, and could be regarded as components of products that are already heavily regulated (or should be).
The vast majority of software practice falls into three main camps,
Note:these are soft setsNone of which place a premium on correctness, the latter two do emphasize style.
Actually I'm rather interested in having my checkbook numbers be correct. And the payroll people at Chrysler are VERY paranoid about ever sending out a bad check.
It's not that correctness doesn't matter, in any of the above listed domains, but that it is constrained by other considerations, in a life-critical application it does make sense to multiply the engineering costs of the project by whatever factor necessary. In a business application there are other considerations.
I think the list above misses out massive segments of the software industry.So add to it! It seems to cover only user-visible software. Although you mention games, and this seems largely to do with the games themselves, there is a whole other industry of video device drivers, embedded OS, and so on, which are not necessarily specific to games machines. And I can't see where things like metal die press controllers and telephone switching software would fit (and telecomms/networking are massive employers in the software market.). To take the telecoms example, the ErlangLanguage was created to meet the need for correctness and robustness in the software used.