Interface Magic

I’ve been a fan of interfaces (the programming kind) ever since I started using them as part of COM programming, sometime in 1995.  At times, I went overboard, creating an interface or maybe two for every class I wrote.  In the COM days, you really needed to worry about this, because it was the way to communicate between dlls and exes without worrying about nasty linkage and header file issues (i.e. basic C++ programming B.S.).

Now that I’ve been writing more of my own code as a lone programmer, I’ve gotten a bit mellower about interfaces.  I’ve been writing smaller projects and I don’t have to worry about other people using my code.  However, the other day, I found that creating an interface was just the quick fix I needed to save myself from copying and pasting a bunch of code three times.

I had already created three different classes that were just data holders with unique data.  I only needed these three, so doing some code duplication didn’t bother me (we all have a tolerance and I hadn’t reached it just yet).  But, then I needed an output routine that would have to traverse the data for each instance of all three classes and I realized that creating one simple data access interface would let me write just one routine.  Also, later, I could use the same interface to clean up the original code and make it more concise, if I felt so inclined.

On a previous project, I had designed a set of interfaces to cover the functionality of some very different classes that needed to be selected and manipulated on the screen.  When a colleague stopped by and wanted to write a new uber-manipulation tool, I thought for a moment and told him to implement the common Control interface that I used for my other objects and he’d be halfway done with his job.  It also meant that I didn’t have to suffer through someone else hacking away at my already working, but somewhat complicated selection code.

One other thing that I (and my coworkers) did at a previous job was to give every class a public and a private interface.  All communication with the classes was done through the interfaces and not through a class directly.  Remember that the other benefit of interfaces is the clear indirection between the communication layer (how you interact with the class) and the implementation layer (how the class responds).  It’s very easy to get lazy with public and private tags to access data, but many times we get a little lazy and let other code see our internal structure.  Then, when we find out it’s too slow or needs slightly different functionality, we have to change the calling code to change our internals.

For me, one of the great benefits of interfaces is the ability to reuse code that calls the interface, allowing me to worry about the new functionality without having to rework the old (i.e. I don’t need to accomodate a new class in the old code because I’m calling interfaces instead).  Interfaces can allow my classes to masquerade as several different kinds of objects without the need for complicated inheritance trees.  I often find that creating a new base class to handle a particular interface can be just the ticket, too.  One of the best things about software is its malleability.  It often pays to rework a few things and add some interfaces, even after the fact, to make the code easier to understand, use, and reuse.

Driven to Distraction

I do double duty writing – software and fiction.  Some days I find myself more productive than others and it’s usually due to one thing – my internet connection.  It’s not what you think, actually.  Most of the time when my connection is good and I have several tabs open in my browser, my productivity sucks.  I keep waiting for something interesting to happen: an email from a colleague or friend, a good post on one of the blogs I follow, a good link posted on facebook, etc.

It’s too easy to while away a spare hour with this crap (let’s face it, it’s not a productive use of time.)  I find myself most effective when I shut down my browser.  That way, I can’t even notice that a new email has arrived (it’s probably just spam anyway).  No matter what work I’m doing, if I don’t need the internet to do it, I’m probably more productive not even being distracted by it.

A while ago, I had a discussion on the Comments section of Coding Horror about email.  The issue was about whether to send and read emails versus calling, and this leaked into the issue of checking email all the time.  The person on the other end of the discussion said he wasn’t distracted by looking at his email because Outlook pops up a little message in the corner of his screen when a new email arrives.  The problem with that is that it still interrupts your flow and writing anything is all about getting into flow.  It takes time to get your brain fully focused on an activity and any interruption, however slight, can keep you from operating at optimal capacity.

If you think you’re operating at full capacity, try shutting down your browser for a while and working and see if you get more done.  If you don’t think you’re focused enough, do the same thing.  I’ll be your productivity improves.

Truth In Advertising – Part 2 – Toyota

dctr

Don’t forget to buy Design, Code, Test, Repeat.  It’s a fun, funny, and helpful read.

——————————–

Toyota – Ad Script Meeting

Talent: At Toyota, we care about your safety.

Background Person #1: Guffaw.

Talent: That’s why we’re spending over $1 million every hour to improve your safety.

Background Person #1: Chortle.

Background Person #2: Actually we’re spending that money on the marketing and advertisements that talk about our spending money on safety.  It’s a circular reference.

Talent: I can’t read this anymore (snicker) it’s (hahaha) too freakin’ funny.  Okay, okay, I’m not going to laugh any more.  Whew!  Now seriously.

Talent: At Toyota, we care deeply about our profits.  So much so, that we’ll stall as long as possible before issuing a recall to maximize our image and profits.  That not only goes for our basic Toyota line, but also our premium Lexus vehicles.  At Toyota we do everything we can – whaa, I can’t do this anymore.

Director: Ow, my stomach hurts from laughing.  Okay everybody.  Take five.  Smoke ’em if you got ’em.  Oh, that reminds me, we’ll be shooting the next “Why our new Marlboro cigarettes are healthy for you” ad tomorrow.

Computer Science Majors – Part 1

As a computer science major, you have certain advantages over other students.  You have ready access to the technology that’s used in the industry.  Unlike some types of engineering, you can build worlds entirely inside of the computer that’s probably sitting on your lap or at least on your desk.

If anything, it should also be clear that the next billion dollar idea might be only a few days coding away (think Facebook).  That’s not to say that you’ll make your fortune in software.  Most of us don’t become millionaires, but most of us do make a good living and it’s hard to think of a more flexible, enjoyable one at that.

In school, however, it’s easy to get lost in the just the coursework that you’re given and not think about the endgame (getting a job), but in fact, you have many opportunities to make that easier as well.  Each project is an opportunity to put a principal into practice.  Every homework assignment that involves writing code is a chance to practice the art of writing code.

The first step towards your career in software, starting from college, is to think about each class and each project like a something you did on the job.  When it comes time to write a resume for an entry-level software job, yours can stand out as more than a list of classes taken.  Add these projects to your resume and it will look like the resume of someone who has actually done something, which you have.

Next stop:  side projects, internships, summer jobs, and volunteer work.

Breaks and Creativity

dctr

Don’t forget to buy Design, Code, Test, Repeat.  It’s a fun, funny, and helpful read.

In one section of my book, I talk about taking a step away from your desk when you’re trying to figure out a tricky solution to a problem or are trying to think creatively.  If you don’t believe me, here’s an interesting article about different types of thinking.

I solve most of my creative problems and have most of my epiphanies when I’m not staring at the computer screen.  That’s not to say that I don’t come up with good stuff when I’m actively working – I do.  But it never ceases to amaze me how many great (well, I think they’re great, just allow me that) ideas I have when I’m taking the dog for a walk, taking a shower, or sitting at the dinner table – anytime I’m letting my mind wander.

Just yesterday I had an idea for a new project at the dinner table, then I came up with some more ideas related to it when I was watching TV later in the evening.  Next time you have a tough problem, try taking a break and taking the pressure off yourself.  Talk to yourself – explaining the problem to yourself or someone else can open up these same creative pathways.

Oh Yeah? Prove it!

It’s been a while since I’ve interviewed for a job.  The last time was when I was working at Lockheed and wanted to find something closer to home.  I went to a small, local software developer and two guys put me through the ringer with test questions.  At the end of a day of work, I was tired, uninspiring, not very sharp, and I didn’t get the job.  Some things are just as well, I suppose.  You won’t get every job you interview for because you’re not right for every job.  I probably wasn’t right for that job anyway.

In my 24 years of software development, I’ve given and received numerous types of interviews.  From grueling take home tests, on the spot tests, mind puzzles, behavioral interviewing, mindless “what did you do at your last job” questions, “what’s your greatest weakness”, etc.  In my experience, they all suck.  Interviewing just plain sucks.  I participated in the hiring of my new manager many years ago.  We put several guys through a two day process, finally chose one, and he still was clueless.  The fact is: interviewing is a crap-shoot.

Your best bet with interviewing is to try a combination of things.  If it’s for a programmer, then you have them do some programming.  They can do it at home or on paper during the interview, but it should be something that’s not a trick problem.  The purpose of something like this should simply be to make sure that this person can actually write some code.  Have them design a simple class to do a simple job (some people can code a procedure, but class design is beyond them).

Skip the mind game problems.  They’re dumb and all they prove is that they can either remember the answer or can figure out a mind game problem.  What color is a newborn African-American baby’s teeth?  Really?  The answer isn’t white.  It’s nothing – babies don’t have teeth when they’re born.

Your job when you’re interviewing someone is to find out if they can work with you and do the work.  Yes, make them do some coding.  Show them your code and ask them about it.  You might try some pair-programming with them.  Give them a demo of your product and see what their reaction/questions/comments about it are.  Are they engaged?  Interested?  Do they have a clue about your domain?  Can they understand what you’re talking about?

Talk about their previous work.  Find out what they’ve worked on – in detail.  What pieces of a product did they actually code?  In what language?  With what tools?

Finally, remember this is a two-way street.  Don’t treat your interviewee like a child.  You want them to want to work with you at your company.  I’ve been on many interviews where companies treat you like they’re the last hope you have of finding work, rather than courting you, and I’ve turned down jobs because of it.  Who wants to work for people who seem like they enjoy putting you through a ringer?

Managing Coach

I chose the title Managing Coach to point out the difference between this type of management and Managing First Class.  You might argue that it’s a horrible analogy, but let’s see where it goes.

I’ve had the pleasure of working with and for some wonderful managers, and conversely the pain and misery of working for bad ones.  A First Class manager sits separately from the rest of the crew (they’re all in cattle class, packed into cubicles, after all).  They hobnob with upper management and periodically make announcements during staff meetings about the status of the flight (or product release).  Then they go back to First Class, have another drink, and work on a presentation or other high-level document.  They have little knowledge of the daily activities of the developers and sometimes have little knowledge of the technology either.

The First Class manager, on the other hand, knows a lot about what’s going on in the rest of the company – the role their project plays, deadlines that others are facing, and their relationships to the ones his group is facing.  He’s able to stay on the radar of other company managers and his superiors.  Because of this, he’s able to hear about projects that his group might participate in, or that may affect the future of his group.

A Coach manager (there’s a double meaning to ‘Coach’) has more interaction with the passengers (developers).  He (or she) takes an active role in the day to day activities, providing guidance and inspiration.  He knows what people are working on, what’s moving and what’s not moving, and why.  If a developer is stuck, he knows enough to ask some pertinent questions and make a suggestion or two that might get the developer unstuck or walk away himself with a task to remove an obstacle.

Regardless of where a manager sits, it’s his activities that matter.  Some managers concentrate only on one aspect or another.  The best managers do both.  Just because a manager doesn’t have extensive knowledge of technology doesn’t make him useless in being a Coach.  There have been times in my career where my manager could have steered me in the right direction with a very non-technical conversation, if he had taken the time.  I can also remember numerous times when I was a manager, when developers would knock on my door, describe a problem in detail until my mind and eyes glazed over, then have an inspiration, thank me for listening, and leave with a solution in hand.  What role did I play?  Just a sympathetic ear.

You might gather from my last example that availability is a good trait to have.  If your manager is in meetings all the time, they’re probably a First Class manager (this is not a rule, by any means).  To be an effective development manager, being available to your developers and seeking them out for informal updates can make for a less intimidating and more informative and productive relationship.

If you’re a manager, think about what you can do to enhance both aspects of your management skills.  If you’re a developer, show this article to your manager to give him some food for thought.  Even managers need a coach.

How to save money by outsourcing

I can only think of one reason that the CEOs of companies don’t outsource their most expensive people.  They is them.

I’m going to make some sweeping generalizations and estimations here, so bear with me.  I’m going to stick with larger software companies because they are more likely to open overseas offices or outsource jobs.  Larger software companies tend to have higher paid CEOs and also higher pay for their software engineers.  Let’s do the math.  Average CEO pay: $10million in money and stock options.  Average software engineer pay: $70,000 to $100,000 in money and stock options.  Ratio: at least 100 to 1.

If you believe my estimates are out of whack, that’s ok.  Let’s assume that the ratio is closer to 25:1 or 50:1.  When one accounts for the entire executive staff – you know all the VPs of this, that and the other – you can add another 10 people or so whose ratios are 5:1 or 10:1 versus the average worker.  You can also add the board members, who tend to be CEOs of other companies.  They can make $100,000 for attending a dozen meetings a year.  Sometimes they get stock options, too.

It seems clear to me that a large company could very effectively save 80% of their executive compensation by moving those jobs to qualified people in India or China.  Clearly if the engineers there are capable of writing our software, they should be smart enough to run the company as well.

I’m obviously not a fan of massive outsourcing or excessive executive compensation.  I don’t believe that either of them accomplish what they’re cracked up to achieve.  I’ve seen outsourcing fail miserably due to communication problems, over-promising results, and even cultural hesitation to say, “No, we can’t do that.”  I also don’t understand how executives justify outrageous pay, bonuses, and golden parachutes, even when they don’t perform.

There’s a happy medium somewhere, but it seems to be getting lost.  The next time your CEO suggests that outsourcing will save your company tons of money, maybe you can find an anonymous way of suggesting that the CEO could outsource their own job to save even more.

Fear-mongering

I try not to lump people into buckets.  I like to think I’m open-minded enough to consider various points of view.  One thing, however, that really makes me mad is fear-mongering.  When W was running for his second term, the Republican supporters ran TV commercials warning us all that the U.S. could be headed for disasterous terrorist attacks if we voted for a Democrat who would most certainly be “soft” on terror.  More recently, there are ads urging me to call my Congressman and tell him that he should vote no on the health care plan.  The ads are full of fear-inducing messages about rationing, skyrocketing costs (aren’t they already?), etc.  Two of the messages talk about two different Congressmen, each of whom is the deciding vote.  Well, which one is it?

Politicians do it, marketing people do it, and salesmen do it.  “You don’t want the extended super warranty?  It protects your computer for 20 years and covers damage, even if you drop it in the toilet.”  Now, stories of people dropping their cell phones in the toilet are widespread, but your computer won’t fit in the toilet.

Too many decisions are based on fear.  Some decisions are valid to make on this basis.  Do you walk down the street in a neighborhood that’s known for trouble?  Do you leave your car unlocked when you know that there are people around who regularly steal cars?  Do you go skydiving without being absolutely anal about checking everything that come into play?  Of course, not.  However, most of the ads on TV and salesmen trying to sell you something are betting that you won’t do the research.  You won’t bother to find out the truth.

We all make decisions about things on the spur of the moment, often based on the fear induced by the situation or persuader at hand.  However, when you take some time to think it over in the absence of the pressure, you often come up with a clearer view of the situation.

People who resort to this are manipulating you and nothing makes me angrier than being manipulated.  When you can, take the time.  Do the research.  Make up your own mind.  Punish the fear-mongers.

Marketeering

Marketing people tend to get a bad rap, especially in software.  Just read a few Dilbert comics about the soulless folks in marketing and you’ll get a gist of their status.  I’m not suggesting that it’s entirely undeserved either, but not all marketing folks are dishonest, horrible people.  On the contrary, I’ve worked with many bright, knowledgeable folks who made a big impact on the company I was working for.

This post will deal mostly with an overview.  There are generally two kinds of marketing: inbound and outbound.  Inbound is the art of determining customer needs and producing products to meet those needs (i.e. taking in information).  Outbound is taking the products that you have and presenting them to the customers in the form of websites, webinars, presentations, brochures, advertising, trial software, etc. (i.e. sending out information).

Ideally, you’ll have folks at your company that are concerned with both inbound and outbound marketing.  Good inbound marketing is key to producing the products that customers will actually buy.  It should involve conversations with customers, and involve them in the testing of your software in alpha and beta stages of development.  I’ve always been leery of know-it-all people who come into the company and try to turn the place upside-down without any experience in the domain of the products (i.e. they’ve got 10 years of marketing experience, but they don’t know anything about building construction or software that supports it, for example).  That’s not to say that you shouldn’t hire someone not familiar with your domain, but you should expect them to, and encourage them to learn about it.  In the absence of this, your products can easily be led down a path of uselessness in the field.  It’s seriously hard to listen to folks who’ll pontificate on the direction your software should take when they haven’t a clue how it’s really used.  Expecting that your software will create a complete shift in how your customers will do business is a recipe for disaster.  Most companies are like slow-moving barges.  Having them move quickly because you’ve changed entire processes will likely result in a loss of sales.  When in doubt, ask several customers.

Good outbound marketing is essential to support sales and must be done at the appropriate level for your software and customers.  For example, if you write highly specialized software that costs thousands of dollars per license and will likely sell only a few copies per year, buying a Super Bowl ad is probably not a good use of your advertising budget.  Of course, the biggest bang for your buck is quality website.  When your customers find you, you save time and money.  Ensure that your site is clean and makes it easy to find out the information a user will want to know.  If possible, allow them to download a trial, preferably fully functioning.  After that, the marketing folks will have to figure out what to spend their money on to best increase awareness of your product and attract customers.  In my experience, huge booths at huge conferences are not cost effective if your software is high cost and long sales time.  For lower cost, easy to justify sales, it might work better.

This column isn’t the place to do a complete breakdown on marketing.  Besides, I’m a software guy and you probably are, too.  The point is to arm you will a little knowledge about what your marketing folks are supposed to be doing.  If they’re not, maybe you can nudge them in the right direction.  It can be hard to see the big picture when you’re in the middle of a detailed project.  Asking questions about what’s going on can lead everyone to think harder about the big picture and where the focus of effort should be.