3 ms·

No, precisely the opposite should be said of engineers. Engineering is about reusing well-known techniques to achieve repeatable, predictable results whose tim

No, precisely the opposite should be said of engineers. Engineering is about reusing well-known techniques to achieve repeatable, predictable results whose timelines can be estimated. Engineering is not art. When civil engineers build new buildings or bridges (and I'm talking about your common building or bridge, not some iconic project), do they try to innovate and undertake to do things in some new-fangled way every time? No, because this would be extremely costly and dangerous and would render useless much of the past work that's been done testing materials and loads and so forth. When a method is known of constructing a bridge or an overpass that is both safe and economical, a good engineer should just keep doing that, with perhaps some adaption as appropriate on a case-by-case basis. If software developers would stick with tried-and-true tools instead of inventing new frameworks to solve the same old problems and immediately obsoleting the "old" way of doing things each time, we'd have much less legacy code and likely would be much better at estimating software development tasks, and wouldn't have to solve the same problems over and over again.

joslin01 11y ago
You're right about traditional engineers whose work has been going on for quite some time now. We more-or-less figured out the "correct" way to build a bridge or an on-ramp or most anything physical and tangible. However, your last point is not valid because you're under the fallacy we ever got the framework problem "correct". Who is to say that Django is better than RoR or visa-versa? Software is still a very new craft; you can't say that about masonry. Actually your fallacy stems even further. You're assuming software is predictable. There's degrees of predictability, but most programming starts out as a trek into the unknown. Sure, you might grab a familiar lamp like [Framework X] to shed light along the way, but really you don't know for sure what you're in for. If you did (or do), then you probably spent an insane amount of time spec'ing everything out perfectly. I have no problem with this, but there's even some dissonance between spec & code and the further out that spec gets, the greater the dissonance. Software will always be kinda crazy in my opinion, but I reckon we're getting better with these agile approaches that embrace the unpredictability. In the TDD approach, you have to come up with tests first. This can usually give the programmer or architect a much clearer picture than "step 1: build web app" which will transfer over into their estimates.
coldcode 11y ago
If we stuck with tried and true we'd all be writing in assembly and Cobol. I remember what it was like in 1981, thankfully we continuously move forward. Building a bridge on the other hand is only barely different than the Romans in many ways.

joslin01 11y ago

You're right about traditional engineers whose work has been going on for quite some time now. We more-or-less figured out the "correct" way to build a bridge or an on-ramp or most anything physical and tangible. However, your last point is not valid because you're under the fallacy we ever got the framework problem "correct". Who is to say that Django is better than RoR or visa-versa? Software is still a very new craft; you can't say that about masonry. Actually your fallacy stems even further. You're assuming software is predictable. There's degrees of predictability, but most programming starts out as a trek into the unknown. Sure, you might grab a familiar lamp like [Framework X] to shed light along the way, but really you don't know for sure what you're in for. If you did (or do), then you probably spent an insane amount of time spec'ing everything out perfectly. I have no problem with this, but there's even some dissonance between spec & code and the further out that spec gets, the greater the dissonance. Software will always be kinda crazy in my opinion, but I reckon we're getting better with these agile approaches that embrace the unpredictability. In the TDD approach, you have to come up with tests first. This can usually give the programmer or architect a much clearer picture than "step 1: build web app" which will transfer over into their estimates.

coldcode 11y ago

If we stuck with tried and true we'd all be writing in assembly and Cobol. I remember what it was like in 1981, thankfully we continuously move forward. Building a bridge on the other hand is only barely different than the Romans in many ways.