I come from an engineering background and "right" is the only way to do it.
I come from an engineering background and "right" is the only way to do it.
Contrast this with physical-stuff engineering (which I think is what you're referring to by saying "engineering background"), where the requirements tend to be better-defined and the cost of experimentation/refactoring is a lot higher.
IMO its best to think about a problem for a little while until you come up with some reasonable solution, then hack it up, then revisit your original decisions and see if you can do it better.
In 04/05, I single-handedly wrote a large Windows Mobile (.Net CF) and SOA platform for managing proof of delivery across 5000 devices which used server-push messaging over semi-persistent GPRS links. This required about 6 months of work after 3 months of R&D. It was delivered on time, with zero defects, worked perfectly on low bandwidth connections and required no training for the user (less than 5% of the userbase had problems using it with no training).
It was fast, even over low bandwidth connections. Virtually real time when a link was up.
It was beautiful because it was easy to use and abstracted the messaging system and connection availability entirely.
It was possible because it worked first time with no regressions or defects in the field reported in over 6 years. It had to work first time as there was no upgrade channel for the users.