Month: January 2013

  • Remodeling advice

    Not that I am remodeling, or anything that ambitious, but I have some advice nonetheless.  

    When you remodel say a bathroom, and there are two sinks (his/hers, very common), don’t buy just two sets of fixtures. Buy a spare.

    This is so that in 5/7/10 years when one dies a miserable death and can’t be resuscetated with part kits, you will not be pulling your hair out looking at fixtures that DO NOT MATCH. 

    (As you may have surmised, one of ours has died, and Delta has decided to no longer manufacture the style anymore. So I get to replace two sets of fixtures, and destroy my back doing it…)

     

  • Physicists = bad developers

    I was in a meeting yesterday, and our engineering director made an offhand comment that made me cringe. He commented that our principal developer for one of our products (he really is the only programmer) “like most good programmers” was a physicist. He went on to say that he also did a lot of the initial code for our system, and is a physicist.

    Groan.

    Anyone who is a skilled developer, who has been through at least part of a computer science program, who has grounding in architecture, and data structures, and groks object oriented design, will produce vastly superior code.

    I speak from experience, since I do have a physics degree and background, and I have done some scientific analysis programming (not professionally). 

    I believe the reason why he made the observation is that of course physicists will be better suited to understanding the detailed instrument theory, and how it all works, so they are positioned to create real world, usable instruments. (the instrument in question is an electron microscope)

    But, Physicists are MASTERS of shortcuts. We get stuff done, and have no concern for the next iteration. We cut corners, use undocumented registers, and in general employ practices that make any professional programmer cringe. What we produce works, but often is a mess of procedural functions, or if we use an OO environment, we bastardize the methods and object inheritance in ways that almost assure that the code will be unsupportable.

    In short, when you have physicists as your principal software engineers, you will end up with a pile of spaghetti code, lots of procedural cruft, little usable documentation, and often no real coding style and standard.

    But they will deliver something that functions fast.

  • Modified Joke – Product Manager, the Lawyer and the doctor

    A doctor, a lawyer and a product manager were discussing the relative merits
    of having a wife or a mistress.

    The lawyer says: “For sure a mistress is better. If you have a wife and
    want a divorce, it causes all sorts of legal problems.”

    The doctor says: “It’s better to have a wife because the sense of security
    lowers your stress and is good for your health.”

    The product manager says: ” You’re both wrong. It’s best to have both so that
    when the wife thinks you’re with the mistress and the mistress thinks you’re
    with your wife — you can do some product management.

  • Lost hour of productivity

    Gotta whine.

    About once a month, I get an error in Outlook.  Something to the point of “OUt of resources” yada yada.  And it advises to “close some programs to free up memory…”

    Has that EVER worked?  Sigh.  I have 16 gigs, and am running 64-bit Windows 7 so there is literally a metric ton of memory free.

    Anyhow, from prior experience the only way to recover is to restart.  Sucks, but that is the only way. So I save all the work I have been doing and go to restart.  First warning that something is not copacetic: I get warnings that I have a modified normal.dot file in Word.  And I can’t ignore/cancel past it.  WTF.  Finally name it something bizarre and it reboots.

    Then I get a warning that PGP full disk encryption isn’t working right.  That has happened before, and it always is a fluke.

    Then outlook fails to start.  Says it can’t find the server, or my outlook.ost file.  Sigh.  I know what this means, I need to run scanpst.

    three iterations of that later, and one more reboot, and I am finally back working.  Lost time 1 hour. Lost time if I had called support? 3 hours (BTDT).

     

    Coda: I suspect these issues are caused by our policies and group settings in the domain. I have never experienced anything like this on any other Win 7 system, and I have been running it since 2009.

    Sigh. One of those days. Back to my wireframes and product requirements.

  • Ok, I get it already, we lose orders because we don’t have feature X

    I recently joined this company, and inherited a product that is world class.  But it is missing a pretty important capability (to be fair, when the product was originally developed, this was a feature that wasn’t even a twinkling in the eye of the market). 

    I get that we lose orders because we lack it. We are developing a capability.  It is not a 2 week (or 2 month, or even a 2 quarter) project. But there are still at least 1/2 the opportunties that do not demand the capability.

    Is it too much to ask you to not waste time on lost causes?  Is it too much to as you to sell what you have?  Our product is vastly superior in performance to all our in class competitors. It isn’t even close.  Focus on selling what you have. We will address the rest as soon as possible.

    But one thing I can tell you is that continuing to chase lost causes, and sending lost order reports will not get the project done faster.  In fact, it will cause me to tune out your grumbles.