Getting the Message Across

What Happened?

So our co-director is estimating the cost of bringing on a new client. Their data is a little different than our normal fare - especially the volume. We don't want to bite off more than we can chew.

The prospective client sent one month's worth of information. A quick look revealed records with no useful text. Then we identified a slew that do not fit our profile. Expert data analysts combed the remaining records flagging them as they went.

In our meeting today, the good doctor and I went over the results. We began by recalculating all of the numbers before. Then we adjusted our estimates based on the actual results. Of course, some numbers did not add up. From that, we remembered changes in the filtering. Change the SQL and boom - everything reconciles again.

All through the process, my co-director made notations on the white board. He started at the top and moved down with each calculation. The progression over time provided as much information as the data. We ended with a range of possible outcomes. And somewhere in that range falls our actual experience.

The folks in this department are professional researchers. I worked for a company that said they made decisions with data. These people live, breathe, and sleep data. It's second nature.

What Did I Learn?

First - always build a prototype. Secondly, the prototype doesn't look like the final product.

In software development, you never do the same thing twice. Every job has some unique twist. After all, if if the job was the same then I could use the same code. The customer wouldn't need me to develop new code. Prototypes help me provide a more meaningful estimate.

In our meeting today, my co-director and I created a prototype presentation. We put together enough to see if the message comes through. I lose sight of that when developing software, The prototype has a purpose - try some new technology, experiment with a new algorithm, or even just identify nasty, hairy edge cases. I lose sight of the message, and start writing the final product. It's no wonder that the customer's think they see a finished product!

Like a good estimate, a prototype needs rough edges. It should crash. The prototype should say things like Menu goes here. This isn't unprofessional. It's honest. Those blemishes provide visual cues that the product isn't finished. And when the software looks better every time, your customer sees real, definable progress.

This just grates on the perfectionist inside of me. Another character flaw to overcome...