Not My Problem!

Not My Problem!

Ok, that title might be a little misleading, after having beers with a buddy and discussing the software development process, we talked about a client we both had a couple years ago.  He asked me..

If they did XYZ the would see a 2X if not order of magnitude improvement in their process?

This was absolutely true and the decision makers may have or may not have have realized it.  The underlying fact is, what they were doing was working...maybe running on 3 out of the the 8 cylinders but to the organization, that was acceptable compared to the disruption of the change.  They were making progress in this area, and other areas not so much.

I've been in this industry for over 25 years, and have touched most technologies and parts of the development processes.  I may not know everything but it's safe to say I paid my dues and learned from both successes and well things that didn't turn out as I'd like.  With this comes experience and 9 times out of 10 if I suggest something strongly...it's almost certainly something that would make a big impact, along time ago I gave up on sweating every little detail I knew would bring the optimum solution...sometimes it just easier to say...yeah...that will work too and get back to my IDE..after all it does what I tell it to!

Although in many cases my "advice" gets followed sometime it doesn't.  That's ok...the process or technology I'm suggesting just might fix something that is "not my bosses problem" maybe it should be?  Maybe I don't know all the facts?  Either way this can be extremely frustrating...there is a bug in the technology/process and I want to fix it!



I don't have a definitive answer on how to solve this "conflict of problem priority" however over time I've came up with some coping mechanism, if we think about it there are in reality a few possible reasons for this.

1. I could be wrong...yes I said it, I could be wrong, anyone who claims to always know the right answer rarely does, without exception, I look here first.
2. You could be right but the priority of your interpretation of the problem is not your bosses (right or wrong)
3. The change is important and impactful  however the change would be too disruptive, at least at this moment in time
4. If you are a developer and your boss "doesn't like your algorithm" see number one above first. If you still truly know your algorithm is right, look at number one again after a good night sleep.  If still know your algorithm is right and this happens once a year...shrug it off, it will give the boss some points and move on.  If this happens weekly...give it just a little more time with number one, but also realize you may have a "drive-by" manager, someone that likes to swoop in try to understand what you took weeks formulating in 3.5 minutes and tell you how to solve the problem...again look to number one, maybe they are that good :) but likely what I can say here is...well..er...ah...might be time to vote with your feet.

So again I'm not offering up any solutions here, but this is one the toughest parts of being a "hired-gun" to come in and write software, It's not my show, I'm not writing the checks, I'm doing what I'm told.  But also as a hired gun, I can also vote with my feet (which I very rarely end up doing)

-twb