3 ms·
Is it though? Is it trivial to write, and maintain, over-engineered code that actually accomplish its business goals ?
by cafebabbe 9y ago
Is it though? Is it trivial to write, and maintain, over-engineered code that actually accomplish its business goals ?
- minikites 9y agoYou don't think it's trivial to write GOTOs everywhere and paint yourself into a corner? Of course it's difficult to maintain, that's why it's considered "an engineering flaw" like you said.
- cr0sh 9y agoCompared to a physical device, I would surmise it is. Consider this - you can write code in any manner you want, starting anywhere you want. You can build it from the inside out, or top-down, or bottom-up. You can make it monolithic, or modularize it. You can do all of these things at once, if you want! There was a commercial more than a few years back that illustrated something about "how clients want things done" vs "how things are done" - I think it was for insurance, IIRC. Basically, they showed a "modern construction of a pyramid" in some "city". It was a complicated construct; but apparently the client wanted it constructed from the top down! So there was this huge gantry crane like system, hanging the apex of the pyramid, and other stuff going on with workers and machines gradually building downward to the base... You can't do this physically, of course (though I am aware of people who try to get engineers to do this - it's actually a common thing in custom home building for a client to change their mind in the middle of a project and want a window or door moved a few feet over - and trying to get them to understand what that would change in the already-in-place infrastructure of wiring, plumbing, etc - not to mention demolition, re-engineering, permits, inspections, etc - but some clients have enough money and clout and hubris to insist on it). But you can do this with software. When it's done in the middle of a project (because of design changes, or to fix issues), we call it refactoring. It is this malleability of software that makes it easier to work with to express complicated constructs; there isn't any comparison to physical mechanical systems. Such systems, as exemplified by horological mechanisms, require careful planning of where parts are put for their relative functions, and in relationship to the rest of the device, and how those parts are put together, what order, layers, etc. Not to mention the various calculations and allowances needed for tolerances, forces, friction, lubrication, as well as simply the fasteners and framework holding the whole thing together! We haven't even considered taking into account external forces, and how they relate to the accuracy and/or longevity of the system. All of these things, and many more, apply to all mechanical systems, and require careful planning and execution. Fortunately (especially for many of these complex timepieces of today, as I am led to believe by the reading of a few of these kinds of articles), master watchmakers like these have at their disposal modern CAD/CAM systems to aid them in planning and designing these complex works of art, as well as to guide them in assembly of them. Even with such help, though, I imagine that the process is still a very consuming and maddening one (this is evidenced by the fact of how long it takes for these craftspeople to build only a few of these timepieces). Now imagine having to do this without such help! Not as complex (but still pretty insane given the time period) timepieces (and other mechanical clockwork devices and automata) were planned, design, calculated, drawn, and constructed by hand in the past, long before computers were available - some of which contained thousands of carefully crafted and assembled parts; many of these devices still exist and operate today. Interestingly - very little of our software that we construct today is likely to still be operating 100 or more years from now (though there are a few examples that are working their way to that point)...