Action Items and other buzzwords

Alright.  You've asked the dumb questions and now know what you've got to do.  The holes in the plan have been filled in and you're feeeeeling good.  You whistle a happy tune as you head back to wherever it is you code.

And then, just like that, you're lost.  You frantically scramble over the meeting minutes and discover that what you consider the "Important Bit" is only written as "Joe talked about working on the FooBar project."

Fortunately, Scott Belesky (author of the excellent Making Ideas Happen) has also encountered this problem.  He recommends capturing these notes as "Action Items."

The format of an Action Item is really simple.  Every time something you'll need to do comes up in a meeting, write it down on a small piece of paper.  Personally, I use a pocket notebook, but you can use Post It notes or anything small that works for you.

These don't have to be exclusively used in a meeting.  Carry your notebook around with you.  Capture them when you have a good idea to follow up on.  Write down complaints other people have (any great product solves a problem).  Action Items are a great alternative to the ubiquitous "To Do" list.

Making Meetings Matter

I had a meeting with my boss earlier this week.  In it, we discussed three separate projects, each at different stages.  Each project had different requirements and impacted different parts of the company.  Ultimately, the meeting didn't help much for all the time we spent on it.  It wasn't the fault of the diverse array of discussion topics but rather how we managed the meeting.  I left with a distinct sense of "wait, what?" (especially for our new project).

I'm sure I'm not alone in dealing with such things.  Over the next week, I'll investigate some things that anyone can do to salvage a meeting.  For today:

Ask Dumb Questions.  

This culture of head-nodding we've cultivated is hurting us.  Too often we pretend we heard or understood the past five minutes when in reality we were all off in dreamland accepting our third Nobel.  Asking for clarification helps glean details that may otherwise slip through the cracks and cause a Malcom event.

If you don't understand something, ask.  If you're confused, perhaps others in the meeting are as well.  Chances are, you'll avoid costly communication errors later on.  These dumb questions can also bring up flaws that others might not have heard of.  If I had thought ahead to ask specifics, I'd understand the scope of our new project a lot more and would be much more effective in my research.  Unfortunately, I'm now forced to ask them via email.

If you're the boss, create opportunities during a meeting for people to ask clarifying questions.  Make sure to cultivate a non-critical atmosphere (but bring a Nerf gun in case anyone dozes off!)

NASA sounds....boring

NASA sends rocket-powered jetpack-using robots to Mars.  They developed the technology to bring men to the moon and back.

As I was reading through their software development process, it all sounding so...boring.  There usually aren't any overtime hours.  Everything is written out in reams of paper before any code is written.  Don't get me wrong, it's wonderful to see that somewhere out there is a coding team that uses proper code techniques but their methods seem like all the fun of creation is gone.

A large part of the reason I like to write code is the creation process.  My absolute favorite part is writing proof-of-concept code that works, showing that my idea has validity.  Dear NASA.  As much as I love your work, pleas don't hire me (unless you need another astronaut).

Getting it less wrong

I'll be honest.  I'm looking at some of my posts from the past few weeks and wondering just what I was thinking when I decided to start a blog.  Who am I kidding?  I'm not that great of an author.  Heck, I don't have anywhere near enough real-life experience to write about.

A friend of mine commented today that he wished he could go back and redo large portions of the component we'd just finished.  He had gone through a few advanced tutorials as he began framing our next project and learned a lot that we wished we could have known earlier.

This isn't a new story.  We learn throughout a project and want to start over before we're even finished. Even top programmers will discover new secrets as they explore the edges of the known.

Programming is about getting it less wrong, every time.

I guess that's why I'm still writing this blog.  You can't learn how not to do it if you don't start somewhere.

When your code supports billions

Obviously, some testing of code needs to be done before it's released.  This can be anywhere from "it compiles, ship it!" to the extensive rigor NASA software goes through.  Some of this stuff seems over the top, even to the strictest of developers:

Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.

Yikes.  And I thought the the fact that I had to deal with code that was released without testing was bad.  Can you imagine writing just under a page of details for every line of code?  Obviously, this isn't the standard.  In fact, NASA's shuttle team is only one of four teams in the world that live up to the Software Engineering Institute's Level 5 standards.

We'd all love to write bug-free code.  The problem is, we all don't have the time or patience to write code like the NASA team.  They do exemplify some best practices for us (source control/bug tracking) but their overboard attitude toward bugs just doesn't work for a small feature on a deadline.

Anthony Ferrara brings up an interesting point.  While your software may not have actual lives riding on it, some of it is pretty important.  The key is to divide up your features and test them according to your importance.  Some things are mission-critical and others are just icing.  Sort those out and test accordingly.

Numbers part 10

In my last blog post about numbers, I talked about the issues programmers can encounter when dealing with whole numbers.  Just like elementary school, things get a lot more complicated when we add fractions.

Most decimal numbers on computers are stored using the IEEE floating point specifications.  To greatly summarize the standard, binary digits after the decimal point are no longer stored as double the digit before them, but rather 1/n where n is double the previous digit.  This can cause some peculiarities, as most numbers result in a repeating decimal (much like 1/3 does in base 10).  In this system, any fraction that does not have a denominator that is not Dyadic will be repeating and will likely result in rounding errors.

This raises the question: Why on earth are we storing numbers like this?  Can't we just store the number after the decimal as another whole number and ditch all the rounding errors?  As it turns out, I was wondering the same thing and asked the kind folks at programmers.SE.  As it turns out, most calculators do use an alternate storage method that avoids these errors (at least in base two).  The problem is that doing it this way takes up a lot more space than above.

Almost all of the time, the only people worrying about these errors will be mathematicians.  Outside of research, the place you're most likely to encounter this is when you a coding an application that handles money.  Fortunately, this has a simple answer: Multiply the money by 100 (making it a whole number) do all the math/taxes/etc

Getting your ideas heard

We all have ideas.  Sometimes, they're actually good.  Problem is, not all of us are decision makers where we work.  Often, our ideas are shot down before we can even fully express them.  How can we get our ideas to be implemented despite our position on the corporate ladder?

First, let's look at why this happens.  In a typical scenario, I've found out about a new thing that'll work twice as fast as the doohickey we've got now.  I go and talk to my boss about the wonders of The New Thing.  My boss (hopefully) thinks about this for 10 seconds and then interrupts.  "Doesn't this new thing have caching issues?"  Sure, it does, but they're working on it.  However, it's already too late.  I'll be fighting an uphill battle, defending New Thing.  Even if I do manage to push it through, all future caching issues (and anything else that's related) will be pinned on me.

See what happened?  We tend to be critical of any new idea and for good reason.  Most new ideas are terrible.  Thus, when the new idea is yours, people will seek to find the flaws in it.  Instead of bringing up the solution for the problem, bring up the problem you intend to solve.

Instead of seeing something that could go wrong, they'll see something that is wrong - and needs to be fixed.  Explain the details of the problem and wait for others to come up with solutions.  Once a few ideas have floated (and been criticized), bring up yours.  Instead of being put on the spotlight to be judged, it is now part of an idea slurry that will hopefully result in a solution.  The solution will have buy-in from others so you're not the single point of blame.

Bringing up the problem first helps people focus on what really needs fixing, rather than the how.  Creating an idea slurry ensures that the focus is on fixing the problem, rather than fixing your solution.