RailsConf / RubyConf / AgileConf / EclipseCon / EclipseWorld Speaker. OSS Author of Glimmer. MS in SE DePaul (Chicago) and BS in CS McGill (Mtl). Rock Drummer / Snowboarder.
Location
Montreal, QC, Canada
Education
MS in Software Engineering, DePaul University (Chicago, IL, USA)
The article "Why writing software is not like engineering" seems to misunderstand what engineering is by getting too attached to its classical incarnations in other fields as opposed to freeing understanding from how it was executed and focusing instead on its essence; that is producing consumer-satisfying useful products within time, quality and budget constraints.
As such, there are no implications of "how" things are done in engineering, yet only "what". People who get caught up in the "how" dig themselves a big hole of wasted time pondering senseless matters instead of simply engineering successful outcomes for their customers. The latter is done without wasting time on the "how" yet focusing on the "what" (goals) above all else and freeing the "how" to happen in the best way possible (which can always evolve with the times and within different applications).
Everyone who is building something within quality, time, and budget constraints is engineering whether they admit it or not. Better master engineering then instead of trying to pretend it is not there.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for sharing.
The article "Why writing software is not like engineering" seems to misunderstand what engineering is by getting too attached to its classical incarnations in other fields as opposed to freeing understanding from how it was executed and focusing instead on its essence; that is producing consumer-satisfying useful products within time, quality and budget constraints.
As such, there are no implications of "how" things are done in engineering, yet only "what". People who get caught up in the "how" dig themselves a big hole of wasted time pondering senseless matters instead of simply engineering successful outcomes for their customers. The latter is done without wasting time on the "how" yet focusing on the "what" (goals) above all else and freeing the "how" to happen in the best way possible (which can always evolve with the times and within different applications).
Everyone who is building something within quality, time, and budget constraints is engineering whether they admit it or not. Better master engineering then instead of trying to pretend it is not there.