The first rule of optimisation is: don't do it. The second rule is: if you must do it, don't do it yet.
Premature optimisation is the root of all evil. Both of these maxims are attributable to Michael Jackson, I believe. https://en.m.wikipedia.org/wiki/Michael_A._Jackson B > On 6 Feb 2016, at 10:53, Boris Liberman <[email protected]> wrote: > > Ken, I am also an engineer. At least officially. Although if you were to > argue that "software engineering" has almost nothing with "true engineering", > you wouldn't encounter any opposition from me. > > I can give you an absolutely immediate example. The system that I am working > on right now has certain infrastructure layer. The engineer responsible for > that layer has decided that it has to be optimized for performance. And > optimized it was. Now, later after the most bulk of the code was written, it > became apparent that this code was better optimized for flexibility, > extensibility and maintainability. None of these concerned the said engineer. > The performance optimization was very low hanging fruit and it was a great > opportunity to do fun stuff... However, we now have fundamental (as in > building foundation that is called "fundament" in Russian) problem in our > system. > > It is hard to reason about network cables for me, but I was particularly > alarmed by your saying "I HAVE to look for ANY opportunity to optimize"... I > think of optimization as of extremely sharp razor. And the person who wields > that razor has to be extremely careful when they actually put the razor to > use. > > Nothing personal or nothing disrespectful intended here. As well, we can take > it off the list, as this is very much off topic. > > Boris > >> On 2/6/2016 12:29, Bruce Walker wrote: >> On Sat, Feb 6, 2016 at 2:21 AM, Ken Waller <[email protected]> wrote: >>>> "I'm an engineer, I have to look for any opportunity to optimize. " <-- >>>> that's fundamentally wrong. >>> >>> How's that Boris? >>> I'm also an engineer & while I might not act on those opportunities, I need >>> to at least be aware of them. >> Agreed, 110%. >> >> A very large part of my career was built on optimizing. Cost, size, >> weight, reliability, appearance, ... something. Especially cost. The >> fewer lines of code the better, since bugs increase exponentially with >> complexity. The fewer the components the better since that generally >> drops the cost and increases MTTF. >> > > > -- > PDML Pentax-Discuss Mail List > [email protected] > http://pdml.net/mailman/listinfo/pdml_pdml.net > to UNSUBSCRIBE from the PDML, please visit the link directly above and follow > the directions. -- PDML Pentax-Discuss Mail List [email protected] http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
