Sprout, a Flash/Flex Development Blog By WeAreMammoth, Inc.

Apple Mail and DoneDone, sittin' in a tree...

2009-11-03T14:36:00.004-06:00

I use Apple's Mail and iCal to keep my schedule organized and to keep a hold on the multitude of things that would otherwise get lost in the ether of my mind. If it doesn't come through one or both of those programs, the chances of it slipping through the cracks are extraordinarily high for a person like me. I (mostly) subscribe to the Inbox Zero philosophy and so I try to take action on emails as they come in so that I can ignore the things I need to ignore and do the things I need to do. I especially like using Mail's Todo section to keep track of all the things that I know I'll have to do, but can't take care of right at the moment I am notified about them. Because of this, I've written a little Applescript which I trigger via Mail's rules to automatically add a Todo item to my list whenever I get something from DoneDone that requires my attention). You can download it here. This script will watch for incoming messages from DoneDone and either create or check off issues in your Todo list based on whether the issue requires your attention or has been marked as completed in DoneDone.

Before you set up your rules, be sure to modify the script above by replacing "YOUR CALENDAR NAME GOES HERE" with the name of the actual calendar you want to keep your todo list on.

Here's a rundown of my rules setup:

1. All conditions must be met.
2. From contains "@mydonedone"
3. Subject does not contain "- New comment"
4. Subject does not contain "- Response to"
5. Run the script above.

It isn't much, but for naturally disorganized people like me -- every little bit counts.

Simple sells depending on who you're selling it to

2009-10-26T00:00:00.010-05:00

We love simple. That's why people say "I just want things to be simple." No one says, "I want things to be complicated." I'll prove it to you right now.

If you google the phrase "I want things to be simple", you'll get 954,000 matching results. "I just want things to be simple" returns a respectable half-million-plus results.

Try "I want things to be complicated." There are 4 unique results (as of this post). So, I guess I was wrong. Four people want things to be complicated. Only one of these results is not about the subject of boyfriends. I'm serious. If it's not about boyfriends, one person in the history of digital recorded history has, jokingly or not jokingly, wanted things to be complicated. This is it.

Suffices to say, we are lovers of simplicity. We crave things that make sense, that have rules, boundaries, and expectations. Simplicity is not boring or mundane. It's comforting. It makes us feel like we know what we're doing. It lets us predict. It lets us plan. It enables us to do things.

As a company, we strive for simplicity. It's why we have X2O, a platform that gets rid of the complicated-yet-trivial necessities of RIA development. It's why we sell DoneDone, an application that tries hard to mask the extra noise of issue tracking and expose only what really matters to you right now. Hand me something simple to use, simple to understand, and I'll simply like it.

The problem comes when we (and I'm back to the general we) dream, when we pitch, when we sell. We are bad at imagining simple things. Sometimes it's because simple things are difficult to think up. It's why instruments like this...

...that led to instruments like this...

...did not happen overnight. It took decades of dreaming, thinking, and re-thinking, to get to simple. Sometimes, simplicity is hard to make.

However, more often than not, simplicity gets lost in dreams and pitches because it just doesn't feel like enough. It feels like you're not getting your money's worth. Even worse, a simple thing that's also simple to build feels like it should have no monetary value.

Standing behind something simple feels too easy and too cheap. It flies in the face of things that should be big, inspirational, and awe-inspiring - because it's only when ideas feel big, inspirational, and awe-inspiring that they also feel worthwhile. We forget that the real end-product often has different parameters for success.

An infographic inspired by Craig Bryant

The natural urge to complicate is something we fight at WAM. We have to constantly re-sell and re-pitch simple to ourselves. We're all recovering complexaholics, but it's a good habit to break. Countless arguments about how DoneDone and X2O should ultimately behave ended up with incredibly simple solutions - changes in text, moving a link somewhere else on the page, removing something, or not doing anything at all.

Yet, these simple conclusions came out of hours and days of discussion, thinking, and re-thinking. To get to the simple conclusion took effort and sweat. If we were paying ourselves for the effort, it was definitely worth quite a bit.

It's this very mindset we hope to instill in our clients and the work we produce for them. Simplicity is not for a lack of thought or caring. Just the opposite, in fact. Simple solutions shouldn't be thought of as not enough of anything. Sometimes they are exactly enough of everything.

We Are Mammoth Banter, 10/21/2009

2009-10-21T17:22:00.002-05:00

Let it be known .... the following t'was once written as standard communication at We Are Mammoth:

Great question. I'd say, the ones that have eyebrows should have
a consistent height and the ones that don't should have a
consistent height. Lemme know if that makes sense.

New additions to DoneDone: Admin issues, linking to other issues, api additions, and bulk issue tagging

2009-10-15T23:42:00.006-05:00

Last Wednesday, we updated all DoneDone accounts with a bunch of long awaited updates. It's been a little over a month since we launched a major update to DoneDone, so we're excited this has finally passed. Here's what's new:

Issue management for administrators
We now allow administrators more control over all issues within a project. Admins can now do the following on any issue in DoneDone:

Change the priority level of an issue
Re-assign the issue to another person
Close (or re-open) any issues

If you're an admin, you'll notice a new label at the top of each issue detail page displaying the current mode of the issue. By default, all issues appear in normal mode.

If you want to change the priority level, re-assign, or close/re-open any issue, click the "Switch to admin mode" link. The issue will then refresh in admin mode. Clicking the link again will return the issue back to normal mode.

We know many of you have been waiting for this feature for a few months. We spent weeks contemplating how to best modify the interface while adding as little visual clutter while making it clear when you are (or are not) in admin mode. Hopefully this does the trick. We appreciate your patience!

Linking to other issues in your DoneDone project
We've had a few requests to allow linking between related issues. Now, you can link an issue to another issue within a comment or description by simply typing in the issue number with a # sign. If the issue exists, DoneDone will create a link to that issue.

We aren't the first ones to have adopted this convention. Garret Dimon's post here explains why this feature is used in Sifter, and we couldn't do a better job of explaining why.

New additions to the API
We've added the following capabilities to the API. We hope this gives you greater flexibility in creating third-party apps for DoneDone:

GetIssue lets you get the details of a particular issue (create date, update date, title, description, creator, resolver, status, project id, files, history, and tags)
GetIssuesInProject allows you to get all issues in a project. By default, all details of an issue are returned but none of the history. You may optionally choose to load history as well (comments, status changes, etc) for each issue, though expect this to potentially take awhile.
CreateIssue lets you pass in a string array of tags
CreateIssue also lets you create an issue on behalf of someone, if you are an admin.

Add tags to bulk loaded issues
Last month, we released a new feature - bulk upload issues using a CSV file. We now allow you to optionally include a comma-separated list of tags for each issue. For more information, click the "Import issues using CSV" link at the bottom of a project's home page.

We hope you enjoy these new features. As always, let us know how you're feeling using our forums page at GetSatisfaction, connecting with us on Twitter, or emailing us.

Are you high yet?

2009-10-14T12:59:00.002-05:00

Before a project:

They say jump, you say how high, they say this high, you say ok, they say how much, you say that much, they say stand there, you say how long.

Then:

They say jump, you say how high, they wanna see how high this high looks, you say can't do it, they say ok, they say as high as this much gets us.

Finally:

You jump, they say that wasn't very high, you say that's as high as you wanted, they ask for just a bit higher, you say this high, they say we think so.

Rinse, repeat.

Why the corporate ladder doesn't work in the software industry

2009-10-13T00:00:00.001-05:00

I never fully understood the corporate ladder in the software industry.

The typical corporate ladder generally follow this pattern: Moving up the ladder usually means you write less code. It means you involve yourself more with business objectives than with technical nuances. It demands you think more about some overall vision and less about the intimate details of code. Architect more, develop less.

The corporate ladder creates a false perception that once you've reached a certain level, programming is no longer where you're most valuable. Leave the dirty work for the junior developers. At the same time, it suggests that lower level programmers shouldn't concern themselves with the overall goals and direction of the application at-hand.

Great developers should be both "in the trenches" and "high level" at the same time. For software to really succeed, I'd rather have a group of developers that can think about why something's important, how to best implement something, and then implement it - all at the same time.

When you split up roles into the somewhat arbitrary hierarchy of those that think about the "big picture" and those that only think in if statements and for loops, you lose accountability. Pure architects can make a guess at the best architecture, the best design pattern or the best practice. But, it's only when you're in the trenches that you really discover where the problems lie (and don't lie). And frankly, if you're not in the trenches, you won't care all that much about the trenches - let the developers worry about it. The corporate ladder flies in the face of accountability.

Perhaps, we've taken the architect-developer analogy too far. Maybe, the corporate ladder in the software industry needs a better analogy.

To build a building, architects architect and developers develop. Architects have a general knowledge of building things - enough to create elaborate plans and specs in fine detail. But, they don't develop. It's not reasonable. The separation between those that think high-level and those that work in the trenches is largely for practical reasons. Ask an architect if they could practically design and then build, and I bet many would say yes.

Sometimes I feel like these window washers

2009-10-08T10:04:00.002-05:00

Value does not equal cost

2009-10-07T23:49:00.006-05:00

Questions that help me decide the value of a project:

Do I get to learn something I've always wanted to learn?
Can I re-purpose or re-use the code or concepts?
Is the end product something useful?
Will this help people?
Does the project have a clear set of objectives?
Are there interesting problems?
Do the people I'm working for have similar values?
Are there elegant ways to solve these problems?
Do I think I can do a better job than most?
Is the interface important?
Are the deadlines reasonable?
What percentage of the time will I be thinking creatively?
What percentage of the time will I be doing trivial or tedious work?

Questions that help me decide the cost of a project:

How long will this take?

The hopeless anatomy of an unsubscribe page.

2009-09-28T20:47:00.004-05:00

The latest app refusing to let me out of their sticky-ass email campaigns is Yammer. Is it really that hard to remove my record? Come on, please, I've tried to lose you three times, I'm certain of it. I have a two year old with the SQL chops to handle this. She loves computers.

And, can I see some stats on those sign up and log in links please? It's funny how the simplest things are the easiest overlooked, and subsequently, the things which end up making a non-user into a non-fan. There, I said it Yammer, now let it go.

"Future of Web Apps is Going to Sell Out "

2009-09-25T15:06:00.002-05:00

I really got my panties in a bundle when I read, and subsequently misinterpreted, this blog post headline. Turns out, its a conference.

Why simple ideas normally have complex implementations

2009-09-23T00:00:00.001-05:00

Why do most simple ideas end up becoming complex implementations?

First off, I should simplify the question. Ideas are always simple. That's why every business idea must be accompanied by the elevator pitch - 60 seconds to get your idea across from beginning to end. When ideas start feeling complex, you've left the comforts of Idealand and actually started thinking about the implementation. "Big idea" guys stop here partly with the excuse that it's not part of the big picture, and partly because the real picture trying to come into clear focus is a bit...blurry.

So, the real question is, why do most ideas end up becoming complex? Once you dig into the details, new questions, edge cases, and confusion arise. An idea that hasn't been thought through has little chance of surviving Complexityville at this point. Rather than rethinking the idea altogether, the usual mentality is to work through the problems with head down and blinders up. Decisions are made, features are added all for the sake of sparing the sanctity of the Big Idea. Then complexity festers.

In the odd event, that an idea actually has a simple implementation, there's a whole other problem. An idea that's easily implemented is rarely considered a "big idea" at all. If it's simple to build, it must not be a good idea. Truly simple ideas seem inferior. Businessmen, venture capitalists, and angel investors don't throw millions at these kinds of simple ideas for two reasons. First, they throw money at superlatives - innovation, cool, cutting-edge - often times just other ways of saying an idea is complex enough to be worth its weight. Second, simple implementations don't seek investors, they seek implementers. Just build the damn thing.

The fortunate/weird reality is, simple executions win alot of the time. People like things that are simple to use. No one likes things that are hard to use.

Yet, when the tables are turned, the temptation to conjur up hard-to-implement ideas usually wins out.

Shooting in the dark.

2009-09-22T20:33:00.000-05:00

It sounds incredibly "duh", but it's surprising how often I try to solve a problem prior to understanding what exactly I'm trying to solve. Me constantly finds, er, me, catching, well, myself grasping at straws in the hopes that pure creativity will step in and bring closure. Shooting in the dark, if you please.

It's not only me, myself and I, though. It's pretty much everyone, and definitely minds subject to prolonged stretches of focus (software devs) are particularly prone to simply shooting away.

Since I've been at Mammoth, though, I've learned to identify myself getting into a 'problem plateau', or, a place where it's unlikely I'll happen upon a solution based purely on the knowledge at hand. Confused people call this "spinning their wheels".

Catching myself blowing a perfectly good workday requires discipline and modesty. Discipline because it takes practice. Modesty because practice comes before perfection. I run low in both of these scarcities, but have managed to scrape up enough of each to know that the time it takes to blindly discover a fix is always greater than the time it takes to logically identify and then attack a problem.

So, how do I know when I'm screwed and wasting my time? Well, it's like a puzzle where I don't know what the picture is or how many pieces there are. And I'm given one single piece at a time. Back when I programmed, I'd hack 'n' whack until it worked, with no idea how I ended up at the solution. How many other features may have been compromised? How much extra, inefficient code got stuffed in there? I'll never know, cuz I just spent way too long shooting everything that moves.

So, one tip for the desolate and prideful. You are not an island, and neither is your problem. So, much like getting lost in the wild, you should stop where you are and yell for help. Now, wait until someone finds you. Your teammates are your search and rescue team. Defer to them. They're on your team because they have similar skill sets, experience, and hopefully intellectual capacity. They'll know how to help.

Whatever you do, though, don't start eating strange berries. And don't pretend you'll get anywhere near a solution prior to being able to verbalize your problem to your team. And perchance you do hack 'n' whack your way to a fix, you certainly are still lost in the wild, because you're nowhere close to being a better problem solver than you were before. And, it's 2 am.

Fixing software problems after the fact

2009-09-21T00:00:00.009-05:00

It's better to finish something that's not quite right than to continue to tweak and tweak the unfinished piece. It's much easier to go back and fix something that's "done" than to finagle with nuances of something you're still working on.

The emotional value of finishing is underrated
Too often, we underestimate the emotional and motivational value of work that is simply...done. Perhaps, it's not the end-all final product. Perhaps there are tectonic changes to be made. But the mental lift-up of knowing that an execution is complete is largely underrated.

Programmers and designers don't usually talk about emotion because it feels like a weak excuse, but it's apparent in everyone I've ever worked with - most notably myself. The good feelings of getting things done have huge implications on how well and how efficiently you continue to do your work. The bad feelings of tweaks during development and building software still not graduated from "idea-mode" have an equally negative impact.

The perceived problems of changing functionality is overrated
At the same time, the perceived headaches of trying to tweak functionality after the fact, even deeply rooted functionality, is entirely overrated. The reality is, very few add-ons, removals, or logic shifts are undoable. Good programmers prepare themselves for this anyways. The basis of design patterns and best practices is largely to accomodate for the very real fact that what your code is doing today will likely get tweaked (endlessly) tomorrow.

Iterative development is the antidote to this problem in some ways. It gives developers a taste of being done each time an iteration is released and clients the privilege of tweaking at frequent pitstops along the road to the perfect end-product. Yet, iterative development still works too largely in favor of the latter. It quickly starts feeling like the finish line is a long way off.

It works both ways
Finishing a flawed product isn't just for the sake of the developer either. It's so much easier to see what you really want to change, what's clearly important and what isn't as important as you thought when you see something in its current "final" state. There are no more what-ifs, there are only yesses and nos. Something does or doesn't work like you really want it to. These are things that a developer can take back to the shop and change.

I'll take a completely solidified, 90% correct concept over a 90% solidified "perfect" idea. Going back and correcting completed software is far more palatable than the two-steps-forward-one-step-back dance of code that's trying desperately to finish itself and be perfect at the same time.

The Cowboys spent $1.2 billion on this strategy
I wouldn't apply this methodology to all industries - like real architecture for instance. Yet, sometimes it happens anyways.

The new Dallas Cowboys stadium (at a cost of $1.2 billion) has a major flaw. At just 90 feet off the ground, punters are finding they can easily hit the $40 million, 11,520 square-foot scoreboard. If Cowboys Stadium were code, we could easily adjust the scoreboard height. In real life, it's a multi-million dollar job.

Their solution? The NFL has instituted a new do-over rule on punts that deflect off the scoreboard. I'm not sure if I'm completely happy with a rule that sounds like 6th grade gym class, but, it's a simple change that costs $0.

If league officials had cared about this detail before the stadium was finished, the Cowboys would likely be taking snaps at the Wal-Mart parking lot across the street this Sunday.

Look ma, no hands!!!

2009-09-13T21:57:00.003-05:00

Compliments of Apple.

Deleting issues, importing with a CSV, and more admin control with DoneDone

2009-09-09T00:00:00.000-05:00

We have some updates coming up for DoneDone in the next release. While we don't have a firm date set yet, it will very likely be within the next two weeks. Thanks to everyone for the feedback so far.

Deleting issues (for good)
For a long time now, we've been telling you to simply close issues to get rid of them. But, many of you have requested a true delete of an issue. In the next release, every person can permanently delete issues they've created (administrators can delete anyone's issues). Deleting issues will remove them from DoneDone for good. They won't show up in status reports or the "closed" issues bucket.

Here's what the issues page will look like with the new "delete" button. We're still tinkering with its location...

(Thanks to Kevin and Gian for formalizing the request in our forums)

Importing issues
Many of you have requested a better way to transfer issues from another bug tracker into DoneDone. In the next release, we'll allow you to bulk load issues for a given project by uploading a CSV. You'll be required to provide a column for title, creator email address, and resolver email address, as well as optionally include columns for description, create date, and priority level. Each row in your CSV will be converted to a new issue in DoneDone.

DoneDone will parse each row of your CSV file and add an issue. If something is wrong with a particular row (i.e. we couldn't match an email address to a person assigned to the project, required fields weren't provided, etc.) DoneDone will skip that row and move to the next one. At the end, you'll see a full report of which rows were successfully inserted as issues as well as which rows had problems.

CSV import results will show what issues were uploaded and what issues couldn't be uploaded.

More power to administrators

Our final big change is to allow administrators more control over issues. Currently, admins can modify titles and descriptions of any issue and create issues on behalf of someone else. Many of you want more control as admins. In the next release, admins will be able to:

Re-assign an issue to someone else
Close any issues
Change priority levels

We may consider more options for admins, but we'll start with these for the next release.

Finally, a special thanks to you
All of these updates were made because of the consistent feedback we've been getting from our loyal customers. We take great pride in keeping DoneDone lean on features and ensuring only the ones that make sense get into the app. Even something as simple as deleting an issue is something we agonize over - not because it's hard to do, but because we want to make sure there's a good reason to do it.

We'll update you as soon as we've finalized testing these new features and can update all DoneDone accounts.

Embracing constraints should be real world sensibility, not cult dogma

2009-09-01T09:00:00.006-05:00

Embracing constraints in design and programming shouldn't have to feel like you're going against anyone's grain. Yet, there's still a sense in the real world that enjoying these limitations is some Web 2.0 cult-ish right of passage instead of just - making sense.

Without constraints, you can't have creativity or innovation or "cool" period. Creativity is relative to the environment you're working in. Using a whiteboard marker to open a bottle of Schlitz is creative, unless you happen to have a bottle opener in your other pocket.

Using tables and shim gifs to slice up a web page layout was really fucking cool back in the day, because we could now take just about any blasphemous design and make it work in HTML. (Side note: I traditionally do not swear in my public writing - but seriously, it was really fucking cool back then.) Had no one ever thought of how to work around those limitations, web design would never have reinvented itself into the "standards"-compliant languages that still allow for great design today. Oh, and standards-compliance today = more constraints.

In reality, every great achievement is an achievement because there was a constraint or two in place. Usain Bolt's 9.58 run is heralded as a great achievement because it's the fastest any human-without-proof-of-illegal-drug-use has ever run 100m-with-a-tail-wind-of-less-than-2-meters-per-second.

Ben Johnson broke the world record in the same event in 1988 (then 9.79 seconds), but no one would consider that a great feat because he tested positive for steroids.

If we didn't embrace constraints in sports, there'd be no fuss over Barry Bonds or Rosie Ruiz. They'd be the greatest home run hitter and 1980 woman's Boston Marathon champion, respectively - no questions asked.

Here's a game. Connect all 9 dots without lifting your pen.

Sure ain't much of a brain teaser. But now, try connecting all 9 dots without lifting your pen, using just 4 lines. You're intrigued aren't you?

But that's just it. In other realms, constraints are called something else. Rules, laws, or even...games. The notion that embracing constraints in the web world as some holier-than-thou attitude toward how we build applications is nonsense. We often get too brainwashed by the infinite possibilities of what we can do that we forget constraints are the things that define what among these possibilities is actually innovative (or cool or creative or smart or clever or even fun).

For the curious and stumped, the answer to the puzzle is here.

The internet circa 1999

2009-08-26T20:27:00.003-05:00

I ran across a clip from a short film produced in 1967 called "1999 AD". Some pretty accurate predictions regarding the internet here along with the very common inaccurate assumption that there would be little-to-no change to any societal norms.

Remembering your last search with DoneDone

2009-08-25T17:59:00.003-05:00

We made a small tweak to issue lists in DoneDone today.

Previously, things worked like this. You'd go to a project and search for issues. You'd click into an issue to view the detail. You could even click the "Previous Issue" and "Next Issue" links in the upper-right to scroll through the issues you searched for. But, as soon as you clicked "Back to My Project", your old search was gone.

Now, when you click "Back to My Project", we'll take you back to the last search you did for your issues so you don't have to search for the same set of issues again. We hope this makes things a bit more convenient.

Some thoughts on the world's most popular thing's home page

2009-08-17T09:26:00.003-05:00

Twitter's trending topics section on their revamped home page is nice, but I keep thinking it should scroll to more trending topics as my mouse moves over the fade on the right. Anyone else get that impression?

Gradient fades suggest mouse-gesture scrolling....I think.

Also, the topics that overlap the fade aren't clickable. Sucks to be Usain Bolt at 9:38AM Central Standard Time.

Links to the right of the red line cannot be clicked.

As I am a big advocate of not complaining about everything, I will say it overall is a very pretty page...

DoneDone makes firing people a whole lot easier

2009-08-10T00:01:00.001-05:00

This weekend, we made an update to DoneDone to better support removing people.

Previously, when you wanted to remove someone, we'd also remove all related issues that were created by or assigned to that person. It was an early decision in the design that no longer makes sense to us. If a person leaves your company, it's unlikely that his or her issues magically don't matter anymore.

Now, when you want to remove someone, DoneDone checks if there are any issues related to that person. If so, you can move all these issues over to either someone in your own company or the company that person worked for (if it's a different company).

The new person in charge of these issues will be notified by email and you'll see a note about what happened in each issue's history.

We think this is a great feature that you hopefully don't have to use too often!

A proposition from Starbucks

2009-08-06T10:59:00.006-05:00

A proposition from Starbucks. Does McDonald's screw up their coffee?

A note: I got a better shot of this today. More legible. Also, Mustafa has provided proof that, indeed, McDonalds does have their work cut out for them as well. A different kinda problem though, as is plainly obvious in this here image.

Building an ISV on top of a client business

2009-08-03T11:07:00.003-05:00

I had the privilege of writing a post for 47hats - a blog strictly focused on topics related to microISVs and startups.

In my writeup, I share some lessons learned from our recent release of DoneDone and X2O, as a company whose primary focus is working with clients. How have we managed to design, build, and maintain a couple products with limited resources? Here's the post.

Thanks to Bob Walsh for letting me graffiti his site. Also, here's a link to his new book, The Web Startup Success Guide. Looks like a great read!

of non-wordiness and wordlessness

2009-07-30T23:02:00.006-05:00

Garrison Keillor, writes a novel in a simple column at the end of the Tribune Tuesday. Every single word in this column is precious. A book in column-form.

In other news, these guys got together for beer. One of them said this:

"... we both had been cast as characters in other peoples' narratives that we couldn't control ... if we take control of our own stories, we can take control of narrative."

-Henry Louis Gates Jr.

Then they agreed to "lunch together" at a pub in Cambridge. And the president was pleased.

We went to the moon six years after this? Hmmmmm....

2009-07-22T21:58:00.010-05:00

Anytime a blogger or tweeter rebels against "anything-that-has-to-make-me-think," I must interject. Technology today, for better or for worse, is amazing. Stop complaining.

I recently stumbled upon a video of NBC's live coverage of the assassination of JFK whilst doing some Walter Cronkite reminiscing. I'd already seen his very famous announcement of Jack Kennedy's death - the one where he's just received a memo from the AP, takes off his spectacles, looks at a clock off camera, and swallows the lump in his throat.

But, the NBC broadcast is well worth a look. It uncovered some hidden gems in technology circa 1963. It's amazing to think about how limited your tools were back then. You couldn't bring a live TV crew to the scene and most live communication was done via messengered tape recordings or with a rotary phone at the desk. Somehow we rocketed a few men to the moon a few years later.

However, more fascinating than this is how poorly even those tools worked - especially when it was needed right this instant. Technology just wasn't as suited for spontaneity as it is today.

Here's an attempt to use a phone-speaker-extension-thing no one seems to have ever seen before, including the manufacturer. Chet Huntley (the man on the right) handles it 5% convinced that it's actually a ticking time bomb.

When NBC wanted to switch over to the local Dallas affiliate, things also went a bit haywire.

In a brilliant description that today would be summed up in the letters W, T, and F...

"As you can appreciate, communication facilities, as you just saw, went in and out. This is a time of, what would probably best be described as, controlled panic. The arrangements for that switch to Fort Worth were made entirely hastily, under conditions of extreme pressure. And that is why the picture came and the audio didn't and then when the picture dropped the audio came in."

Today, we seem to be a bit less tolerant of things not working. And, perhaps, that's a sign that things really are working.

Use time as an investment in your business

2009-07-21T15:34:00.012-05:00

WAM's been in business now for nearly three years - our profits completely home-grown through a combination of client work and selling products. The overwhelming constant in our success has been to use time as an investment in our business. Time is, indeed, like money. You can use it to just buy stuff or you can use it to make an investment.

Use time to invest, not just to purchase
Time is money. But look at your time more like stock (and more like a mutual fund, not like this piece of garbage I've been holding onto for years) rather than cold-hard cash. If you spend an hour on a piece of functionality and the result of your efforts is only what you wrote, you purchased that piece of functionality with your time. But, if you can extract it, learn from it, or re-apply that knowledge elsewhere, you're now making a sound investment with your time.

How we're investing time into client work and products
Virtually every addition in the past two years to X2O was at a result of needing it for a client project. Any opportunity we can find to generate code so we don't have to re-invent it again and so we can offer it to future clients, we take. The early additional time investments have always been worth it. I can't think of a feature in X2O that I wish we didn't spend the extra time on. Our data-modeling product is as good as it is now because of what our clients needed for their own projects.

It works the other way too. With DoneDone, every feature we add to our product now makes resolving bugs in our client work better. When we add new features to DoneDone, we're making our own lives easier as much as we hope to make our customers' lives easier.

In the end, these investments in time actually convert to real money. More product instances sold, more repeat business, and more efficient client work.

When you're a self-funded small business, you have to find ways to make your company next week a better company than it was this week. One of the easiest ways to do that is to be a smart time investor.