Which Incorrect Assumptions are Harming You?

There's a saying, "Never ASSUME because it makes an ASS out of U and ME."

There may be occasions when you want to show that someone else is a bozo, however it's going to be far more common that you need to cover your own behind.

Minimize the number of assumptions you're making, and I guarantee you a better, more productive and happy life. I'm going to focus here on the workplace and leave the self-help and spirituality angle to others, or maybe a separate article.

When starting a new project, do yourself a big favor and take time to review the desired outcomes (requirements), and list out the assumptions you're making about achieving each of them. This is probably not news to a professionally certified manager, but it is definitely something that engineers need to learn and put into practice.

A requirement such as "Integrate event registration form with Paypal checkout" is something many others may have done, however if this is your first time at it, then you need to identify the assumptions you're making about how easy this will be.

You're essentially just answering "what do I need to know so that I can make a realistic estimate about this task?" But you need to start by listing even the most basic assumptions. For example, "I have the prerequisite HTML/CSS/Javascript/Ajax knowledge to make a registration form." Do you really, or are you good with a couple of those things and assuming the rest will fall into place by searching on Stack Overflow or CSS Tricks? Is Google really your friend?

This will probably be an iterative process where new questions come up as you find answers for the earlier ones. You don't necessarily have to answer each and every single question up-front, but make sure you have enough information at hand so that you and others can be more certain about a particular approach.

Sounds a lot like "documentation" or "process" which a lot of energetic engineering and creative people might shun. This skepticism eventually dies down after you've been on projects where you found out very late that people (maybe it was you) made incorrect assumptions about what needed to happen or what would be happening at a certain point in time.

For example:

• "I thought Unity would easily export my game to multiple platforms, so I saved that for the end. Now, I'm finding out that there are lots of things about my game that are a complete hassle to fix and I wish I had done something entirely different instead."
• "I was just going to comment out some code here and there so that I could have a simple demo for the trade show, but it turns out that things are too interconnected now and I don't have time to both make a reasonable demo and stay on schedule for my other deliverables."

Don't let hubris be your downfall. You might be very smart about a lot of things, but spending a little bit of time to identify and honestly assess your most basic assumptions can go a long way towards not ending up on what my physiology professor politely referred to as the "ab-oral" end.

What do you do to avoid being on the wrong end of things?

It's About Showing, Not Knowing

Microsoft, Google, and others are known to ask some "trick" questions in job interviews, which (unsuccessful) candidates will complain have nothing to do with the position they're applying for. There may even be some hesitation about applying for a position at a company that includes questions such as, "how many golf balls would fit into a school bus?"

The point of these questions is not to humiliate you, or force you to fail an otherwise flawless interview. Any proficient candidate could probably answer the technical questions directly from memory, and asking such questions only helps to establish that a candidate has the prerequisite knowledge that qualified candidates need to possess. After one of these standard textbook answers is delivered, the candidate may be asked to deal with unexpected variations to see whether they can solve more of a real-world problem. This is the first part of verifying that the prospective employee hasn't just memorized answers about common topics, but truly understands how the solutions work.

The trick questions are also part of this process of assessing the candidate's analytical skills. They're not necessarily looking for you to provide the correct answer. They already know it's a tricky question, and that you might not answer it correctly in the stress of an interview. All they want to see is how you might work out the solution.

Don't bother with websites which list the trick questions and memorizing the answers. Instead, put more time into bolstering your knowledge of the fundamentals, and then practice this knowledge by applying it to some real or made-up projects. You're not going to be hired because you knew how many piano tuners there were in Chicago, or why manhole covers are round, but more because you could deduce a reasonable answer.

I said reasonable and not correct. In real life, you will probably have more time to research, come up with multiple approaches, and also discuss with colleagues. That process will probably uncover a correct or good answer. However, you need to demonstrate at the interview that you are capable of aligning your thoughts correctly so that they will eventually arrive at a good solution.

We can only memorize things which have happened. The real world, especially in the world of high-technology, is often about inventing the future, and those are different skills than the ones that typically helped you pass exams in school.

It's all about showing how well you understand, and how well you can create a better solution.

Consider the source...

It's important to investigate things before you subscribe to them. Just because something sounds plausible doesn't mean that it's true. Likewise, just because an apparently untrustworthy person says something, that doesn't mean they're lying.

"Consider the source," is a saying which also applies. It basically means that people are predictable, and the things they say and do are consistent with their beliefs. This means people may be lying outright, or unconsciously, in order to support their assertions.

You see this all the time in politics with each party determined to oppose the other. For example: anything your friends or supporters say or do is considered to be good, but if your enemy says and does the same thing, it only goes to demonstrate how stupid, wicked, or bad they are. If the enemy ever does a generally accepted "good" thing, then we're quick to ascribe an ulterior motive. When one of our own people does the same "good" thing, we're calling for Nobel prizes to be awarded.

In general, just because you hear about a lawsuit, there's no reason to jump to conclusions that the suit has any merit. Quite often, it's just a stunt put on by a legal firm to drum up some revenue for themselves, or by an organization seeking publicity for their cause. In my business law class, we were told that you can sue for as many zeroes as your secretary can type in on the form because the final award (if any) is more likely to be based on actual damages. A judge might throw out the case altogether, and a jury might even side with the defendants. These outcomes don't always generate the same headlines as the initial filing.

In the case of this lawsuit, we see that it takes a few more years to possibly get to the bottom of what's really going on.

The following is an adaptation of a message I posted to the gamedesign-l group on Yahoo! Groups. It's some advice for an aspiring game programmer.

Most game programming students (and artists too) have a lot of interesting ideas in their heads about the cool games they want to make one day. You might have played various games and found a lot of room for improvement, and you probably want to address these kinds of deficiencies in the games that you will be making.

The best thing to do right now is to become proficient at programming, and all the other subjects that go along with making a great game.

If you're a student, you'll have some nice opportunities to select classes on these topics, and if you're a hobbyist, then you'll have to guide your own study of:

Logic
Programming is all about logic. Game design, which is about creating the rules for how the game plays, also involves much of that same logic and planning.

Math
The real world operates on strict rules, your game will abide by these rules or manipulate them in some way. Physics, Geometry, and Trigonometry are important for this, as is Economics.

Music
The proper use of sound enhances the gaming experience.

Art
Games use 2D or 3D artwork and you need to know the techniques involved in displaying art and animation. Develop your aesthetic side and art skills because it will help you understand and enhance the work that artists do. It will also help you make some good art of your own when you're making a game by yourself.

Psychology
Not necessarily to solve people's mental issues, but a familiarity with human behavior helps to know just a little bit about what's going on inside a player's head so that you can better tailor the game experience. You might also find this useful when working on AI, but not for the reason that probably just popped into your head.

Literature, Film
The only way to understand the elements of a great story is by getting exposed to plenty of them. As good as you think your game's story and plot are, you might find that your storytelling improves as you become more well-read.

History
Many games involve story telling of some kind, and you'll find that history provides a lot of ideas.

I'm sure others can contribute some more ideas about topics that should have been listed, or have additional ideas as to how any of these are important or less so.

A good way to direct your journey into learning about game development is to take an idea you already have and plan out that game. You'll eventually figure out what areas you need more information about, and you'll eventually get that knowledge and move on to the next hurdle.

In the end, you'll have your game, or have made smaller games along the way.

Bad usability is like a leaky pipe or driving or a road riddled with potholes.

I am famous for my car analogies. Most people get them immediately because they all have experience with cars, and I've been able to come up with some good examples that helped people understand some really complicated things.

Here's a great non-car analogy from 90 Percent of Everything: bad usability is like a leaky pipe.

The author explains that if there are too many opportunities for the user to get lost or make mistakes, then you might not see as many customers completing the transactions you were hoping for at your web site. This is applicable to applications too.

The article includes a graphic that shows how a lot of water might drip out on its way to the tap. Each drip represents a usability "leak" such as "What does that error mean?" and "What do I do next?" What you get at the end is not the complete volume that was supposed to come through but just the amount that managed not to drop out along the way. Imagine losing 60% of your customers simply because they got lost on the way to completing the sale! What is the likelihood of them coming back for more?

My car analogy would probably be about potholes, and I'd say something along the lines of...

If the drive to your store is always characterized by potholes, detours, traffic, or other undesirable incidents, then drivers are likely to choose much more comfortable alternate destinations even if those destinations only offer a portion of the things the original destination promised.

In other words, your store might lose a sale, and maybe a customer for life if your product's usability stinks.

It's bad enough when heavy rains cause the potholes, but it's worse when the potholes are of your own creation.

It's easy for a programmer to become oblivious to usability holes. The assignment might have been broken down into tangible sub-tasks, and somewhere along the way, there is no check to evaluate the whole solution to see whether it is "correct" in all dimensions. It may employ the best possible algorithms and a pass a peer review, but what about the user's review? Does the solution work for the user?

Users don't care why your program is fast or slow, they just know that it is.

Users don't care why something can't be clicked or can't be scrolled, they just know that they'd like to click or scroll those things.

What they care more about is not whether your task was completed on schedule and budget, but whether theirs will be.

It's especially bad when a competing product or service might do a better job at providing those same features, because the user will need more justification to keep using yours. As stated by Raymond Chen at The Old New Thing blog, "it doesn't matter how great your 1.0 system is if you don't survive long enough to make a 2.0."

No matter how magnanimous your supervisor claims or wishes they could be, the reality of life is that you have to meet deadlines and get some code turned in. Do what you can to ensure that you are truly solving the customer's problems and not just your own, or else there may not be any customers/clients, and eventually no deadlines at all because there's no product to work on.

Software is like carpentry.
Given the user's requirements, programmers can probably build whatever is being asked for. It might look ugly, but if that's what the end user wants, and they're happy with the resulting product, then success, and profit! Sometimes you create a thing of beauty, and then success, and profit! In general, nobody wants to make something ugly, but circumstances might take that end result out of our control. (I refer you to the numerous articles at The Daily WTF for some examples)

One of the advantages of working with wood is that you can handle it pretty easily and fix constructions issues quickly. Things with steel are not the same. Steel isn't something you just casually pick up in your car or truck at a construction store, and it requires lots of other machinery (and people) to make things with. Now there's nothing wrong with steel as a raw material, but it means that you need to have anticipated a lot of things in advance and make some very great plans. Unfortunately, it also compromises your ability to adapt to changing requirements (and externally imposed limitations such as building codes), and it's entirely possible that if the design and plans are too inflexible, then you're going to be forced to generate a result that's not making everybody happy.

Building software is a little like that. Large projects need to be planned out well, the design needs to be in place and employees need to have some semblance of a strategy so that the business managers can figure out how everything gets paid for. However, one thing we have in software that they don't have in architecture is that we don't build our skyscrapers with steel.

The pliability of our raw material is great. It means we can still be responsive and address unforseen issues with less hassle than if we had built things out of steel. It doesn't mean that we can or should build our skyscrapers crooked on a whim, but it does mean that programmers have some room to make adjustments.

My big deal about this wood example is that your end result is what matters. Sure, it needs to be on schedule and budget, but it also needs to solve the problems that it was supposed to. And it should solve those problems well and your end users should be happy.

Instead of coming up with reasons to disprove why a new feature can't or shouldn't go in, just listen to your customer and take notes. You don't have to come up with the answer in that same instance, but just make sure you properly understand the problem being described. This is just as much about people skills as it is about technical prowess. Quite often, a non-technical user has a slightly different understanding of your system, and the solution might just be to move some UI elements around, or add new parameters.

One of the things that I do in my own coding is to account for future extensibility right there in my functions. For example, passing objects and data structures gives you a silent way to upgrade your system. A trivial example would be a function that calculates averages. An interface like:

float CalcAverage( float f1, float f2, float f3, float f4 );

is limited to only handling a fixed set of inputs. If your needs change, you'll have to track down all the places where this function was called and update them. If it's a large project, you might even miss some modules and be forced to revisit your updates later.

Worse yet, someone (hopefully not you) might cut-and-paste from this function to create variants for other uses. This means that certain kinds of bugs or other problems in the original can propagate to other functions, and the QA complexity has just increased.

Consider an interface like:

float CalcAverage( FloatArray f );

It's much more flexible. I'm not going to explain why because I didn't intend this to be that basic of a programming chat.

Build a reasonable amount of flexibility into your systems at design time. You'll greatly reduce the ramifications of changing requirements. It's much easier to maintain this kind of code, and you'll definitely get more work done.

Going back to the wood vs. steel analogy, software solutions have a lot of room for flexibility. Unlike the business of building skyscrapers, we have more freedom to change lots of things as we go along. It doesn't mean that we should (because that might throw the project way off schedule, or our product might lose its focus), but we should be responsive to the end user's needs and the project's goals. There's no point in releasing something useless, is there?

Me neither!
Like most people, I looked forward to reading the newspaper comics as a kid. There were always a few that I never really got into, like the dramatic serials, and then there were those funnies that I just never understood. I figured that some like Andy Capp were over my head because I was a kid, and Peanuts was only funny now and then, but I figured that was because my lifestyle did not match Charlie Brown's.

Now that I'm older and have acquired the inevitable life experiences, I am able to find the humor or the underlying comedic principle in many more of the comics that now appear in the newspaper comics, and even online. I've also homed in on a few comics that seem to always guarantee a chuckle or guffaw such as:

• Partially Clips
• Gary Larson's Far Side
• Dilbert
  

But then there's Marmaduke. I think my comprehension of the humor in this comic remains at the same 0.001% that it's ever been. Thanks to the internet, I find that I'm not alone:

• The Marmaduke Project
• Joe Mathlete Explains Today's Marmaduke

The only explanation I can think of for Marmaduke's "success" is that a lot more people own Great Danes or other very large dogs than we might imagine, and they can relate to the "humor" in the strip.