digitalBush

I had the most awkward conversation the other day and it was so awesome that I just had to share. I wish I could give you some kind of funny back-story which ultimately leads to this conversation, but there isn't one. Ladies and gentlemen, this conversation just happened randomly and without warning. I can't make this stuff up.

Person - So, did you go to school to learn about computers?
Me - Actually I went to school for Computer Science.
Person - So you learned how to, like build computers and stuff?
Me - No, I learned how to write software. This whole building computers thing is just kind of a bonus my employer gets from me. I kind of just picked it up along the way.
Person - (Light bulb dimly lights up over her head) Oh! So you could work for Microsoft!
Me - Yeah, I guess I could.
Person - So, I bet that Bill Gates is your hero, isn't he?!
Me - No, not really.
Person - So, then you must be a Mac guy then, right?
Me - No, I kind of use both. I'm not particularly tied to Macs or PCs.
Person - oh! Oh! OH! You could work for Disney!
Me - I suppose I could. I mean, I could work just about anywhere considering that businesses these days run off computers and all kinds of companies need software developers.
Person - (Blank stare)
(Awkward Silence)
Person - Oh, I guess you're right.
Me - (Swift Exit)

Image courtesy of Bruce Tuten

The funny thing for me if just realizing how little people understand about computing.  Since I have a "degree in computers", I'm qualified to write software, repair broken hardware, fix your recipe spreadsheet, and design microprocessors.  There is no difference really.  After all, it's just a computer, right?  In the same spirit, I fully expect a marketing person to be able to maintain the books of a fortune 500 company.  After all, it's just business.

Similarly, I received a phone call at work because an electrical outlet wasn't working.  Since computers run off electricity, then naturally I must be an electrician also. How nice. I'll be sure to email my past professors and let them know how much my degree helped with flipping a breaker.

One thing I'm starting to notice is that it is much harder to write software now than it was 4 years ago.  Am I becoming incompetent?  Hardly, I think I'm a much better developer now than I was then.  The "problem" is that my company has grown from a single table database with maybe 100,000 records to an unknown number of tables with tens of millions of records.  Back in the day, it was easy to churn out a piece of software because things were much simpler.

1. The impact of my software was minimal.  I was writing things that weren't directly tied to revenue.  Most of my development was data analysis and simple data importing and exporting into that single table.  A lot of the data was crap already and there wasn't much I could do worse than what was already there.
2. My software had no other systems to integrate with.  After all, I was paving new ground with what I was doing for my company.  There was nothing else to maintain other than this crappy software I was writing at the time. 

Now there are many things that have to be considered when writing software within my company's environment.  There are several different systems which share data.  I have to be very cautious about what my software touches to keep from disturbing other processes.  Suddenly we now have so much software that maintenance becomes a concern.  Copy and paste works fine (It's still a bad idea!) if you have 2 programs. Copy and paste becomes a nightmare when you have 100's of things.  The same thing goes for embedded logic.  You can get away with a crappy check for a specific login to do something special with small environment.  In a big environment, that kind of stuff won't cut it.  No one will remember it's there and it will undoubtedly rear it's ugly head later on.

So, the most frustrating thing in all of this is having to justify the increased time and resources required to complete tasks.  When someone says something like "Let's make this button for this one login do this special thing", it makes me want to cringe.  Great, now I need to create a mechanism to be able to do "special things" and stub this into perfectly normal code.  And since we can't embed client specific logic and data into the code, we must make a place to store that "special thing".  And since "special things" are forgotten by developers, then we must create an interface for someone to manage these things of special nature.  All of this for one client who probably isn't that big and definitely not worth the effort required to do something stupid that doesn't make sense anyway.  4 years ago I wouldn't have thought twice about completing said request, and I would have just opened up the code and typed up "if(stupidClient) specialThing(); else normalThing();", compiled that and deployed it.  I still find those beauties every once in a while and want to punch myself in the face for having done that.

Now instead of getting praise for quickly doing things, I'm greeted with the phrase "All you need to do is have it do this when this person is logged in and clicks this."  Yes, I'm aware that is what the result should be.  That is evident, but what isn't always evident is the implementation. It's hard to convey to those making these decisions why it isn't so simple.  If it sounds simple, then it must be simple, right?  I wish that were the case.  Every decision about changes or updates to a piece of software have to be considered and weighed carefully.  It's very easy to take a piece of good software that's easy to maintain and turn it into and nightmare over the course of a few feature requests. 

Who's governing the standards of the code behind the things you use on a daily basis? Tennessee's lottery has had an issue with their switch to computer generated numbers.  Big deal, the lottery screwed up, we all do it from time to time, right? The problem is there should have been some checks and balances to prevent a bug like this from reaching production.  Are they not using test driven development?  Did anyone actually review the results of the generated test sets?

How can we know that we can trust the software running the things that we interact with?  A friend of mine brought up electronic voting in a conversation we had today.  There is a large issue here.  How do I know that when I press the button that it really is counting towards the candidate that I select? More importantly still, how do I know that the code and hardware are hardened enough to prevent malicious activity?

Obviously, all of this just raises questions in my head.  I'm not sure I have the answers to this, but I know for sure I'd love to inspect the code of some of this stuff.  I'd at least like to know that real life code had some kind of audit.  Think of it as a Good Housekeeping seal of approval or FDA stamp for publicly consumed software.  For lack of a better name, we'll call it the Josh Bush Software Guarantee.  I like that, don't you?  It kind of has a nice ring to it.

Jokes aside, it's important to realize that computers control many aspects of our lives.  Even though the lottery is a tax on the mathematically challenged, I want to make sure it's fair for everyone.