Monday, May 26, 2008

Becoming Less Obtrusive

I'm back to spending most of my time on my code, so blogging is unfortunately becoming a rare indulgence for me. Today, though, I started adjusting some of the intricacies of my user interface and I need to put this information out there for people who haven't switched over yet:

You want to write your javascript unobtrusively

You may not know it yet, but you do.

When I started the startup project I'm working on right now, I had very little familiarity with javascript coding. I'd done a few hacks here and there to make things pretty, and I'd done some ajax work in the past to streamline an otherwise unintuitive interface, but I really hadn't spent that much time with it and considered it more as a toy concept group that's primarily the domain of "flashy" websites.

In the last few months, I've been working on a website that requires a few neat tricks with the presentation layer, and so I've been leveraging javascript more and more. First I just used the tricks that were packed in with ROR (prototype and scriptaculous helpers), but when I wanted more control I started writing the javascript myself, and then I began introducing JQuery. Before I knew it my .rhtml pages looked something written by Dr. Frankenstien himself (reincarnated as a hack of a web developer). "onclick" handlers were sprinkled throughout the page, sometimes mini-scripts would be jammed in between the mark-up if I was only going to use the function once; it quickly became a nightmare that only I could navigate (I being the one who wrote the whole mess).

Now, I'd heard the term "unobtrusive javascript" before, and even read a few blog posts on it, but it sounded like it would take too much time to abstract everything that way and I just wasn't into wasting time. This is a startup, right?

Well, I built a new section of my site today, tentatively exploring the idea of writing all my javascript separate from my html, letting the site develop first in a graceful way without the scripts and then adding them in only if javascript was available, and you know what? I'm a convert. I firmly believe that this is a better way to code for the web. Of course, this could be due to my relative inexperience with the concept, perhaps challenges will present themselves in the future that will cause me to rethink my position, but here's what I'm seeing today:

- I know for a FACT that my website will work on mobile devices and browsers of any type, even without javascript available, because I've already tested it that way (and I haven't done any extra work to make it "degrade gracefully").

-all of my javascript is in one place; I don't have to hop back and forth between my script file and my html file trying to trace the various possible user paths.

-I can test my page flow with a framework like fitnesse, since fitnesse can't use javascript.

-Both the html and the javascript are more readable and therefore (in my opinion) more maintainable by someone other than the author.

Basically, if you support on principle the use of CSS for styling, or the use of the MVC pattern in software, you are already an implicit supporter of unobtrusive javascript because it supplies many of the same benefits (separation of concerns, more readable code, modularized concepts, etc).

So here's the motto that I should be living by more often: Don't knock it until you've tried it.

(For more information on unobtrusive JS, try this link)

Thursday, May 22, 2008

The Pitch

After a very relaxing week in Mexico, I'm back in the saddle and working again, so that also means I'm back to blogging. BEFORE the trip, though, something happened that I want to discuss a bit today: We secured an investment. Not an enormous one, but certainly enough to lift our spirits.

For me, this whole pitching process was a first, but my Father has done this several times before, so when we went into this meeting I mostly stuck to the technological portion of the demo and allowed him to do the talking (carefully watching to pick up what pointers I could). As the presentation progressed, and the investor signed, I think I derived some common components that could be used anytime one is trying to get a person to believe in them strongly enough to back them with money.

Prove the Problem

When we started the talk, we didn't just fire up the computer and show our service. What would that have shown? "Here's a piece of software, it's really cool and people will pay for it!". Wrong approach entirely, software (product or service) has no intrinsic value, it is only as valuable as it is useful. Thus, in order to sufficiently impress upon your potential investor just how great this software is, you need to establish the proper context: What problem exists right now that this product/service is going to solve? This is important, I think, because once you've shown that there is some pain in the current state of affairs, all you need to convince your client of is that your solution alleviates that pain. It doesn't need to do anything and everything to be useful, it just needs to be able to solve that targeted problem.

Show, Don't Tell

A picture is worth 1000 words, and a prototype is worth 1000 paragraphs. It's not good enough to get into a pitch and say "We're proposing to build X software which will solve this problem", who knows how much work that will take or whether it's even possible? Glorious words about the supremacy of an as-of-yet-not-constructed product are not likely to inspire much confidence, but a working demo that somebody can play with proves a couple of things:

- the software is possible
- the interface is nice and intuitive
- we, the founders, are already invested in this idea

That last item is particularly important, I believe, because it shows the investor that you're in the same boat with them. If you're asking for money before you've done anything else, you're basically saying that you have an idea and you want the investor to bear all the risk. Does that show that you really believe in your idea? I don't think so. But if you have a working piece of software that you can show off as a prototype, you're basically saying "I am confident enough in this idea that I've already invested time and money into it, and I am sharing any risk that you take by providing me with more resources to put into it". That sort of impression is much more likely to elicit a positive response.

Demonstrate Differentiation

Your idea is probably not original. I don't mean that in a bad way, I just mean that you probably have at least SOME competition, even if it's indirect. An investor doesn't just need to know that your solution is good, they need to know why it's better than the others. If I were building a search engine (I'm not) I would have to show more than that I could just return relevant results. That wouldn't be enough by a long shot; I would have to show that I had a feature of my application that made me Different from other search engines in a way that would make people abandon other products in favor of mine (maybe mine credits your paypal account with a percentage of the revenue I make through advertising, or maybe it pulls results that are relevant to you and your social network, etc). The bigger a barrier that differentiation is to your competitors the better.

Ask for the Money

Probably the simplest piece of advice, but also the one that would be hardest for me to do. I watched as my father finished our demo and then immediately turned to the investor and said "What do you think? Is this something you'd like to participate in?", and I internally cringed realizing how tough it would be for me to throw something as personal as a monetary transaction out on the table like that: I would feel like I was SELLING them something. Of course, that's exactly what you're doing, and as unpleasant as it might be you just have to ask for the "sale" or they have no reason to give it to you. With my instinctual indirect approach, I probably would have done the demo, asked if they liked it (which probably would have brought a "yes"), and then thanked them for their time and left. A week later I would have been nothing but a memory to them. Asking somebody if they "like" your idea is not the same as asking if they want to invest in it, because the latter is a call to action: if they say yes it's a committal to spend money and if they say no they'll have to give you a reason why. They could lie about "Liking" your idea and never have to do anything further about it. If you want, you must ask.

So what do you think, is it a perfect formula for success in money-raising? Of course not, how could there ever even be such a thing? But it worked for us once, and I would imagine that NOT incorporating a few of the above components could be a near-perfect formula for failure.

Tuesday, May 13, 2008

Perspective

Right now I'm technically on vacation in Mexico with my wife, so I have no time for long posts. However, I did have this brief thought today and wanted to share it.

Fire Video

The linked video above is of a fire that my next youngest brother assisted in putting out (he's one of the crew that comes from the left of the frame about two minutes in). He's been a firefighter for a few years now, and has all kinds of stories about different occasions on which he's helped people while on a call, and a few in which he even saved their lives.

Now, I am passionate about my profession; sometimes to the point where I get involved in pretty heated arguments about development methodologies, code style, language preference, etc. I'm also emotionally attached to my work: I'm unsurpassingly happy when I'm being productive, and borderline depressed when I'm not making much progress. Bascially, my work-centric thought patterns can sometimes progress to the opinion that the "software" world is "the" world, and since most of my friends are in that world too there's little in our conversations to help us get a grip.

Listening to my brother talk about his job gives me a strong dose of reality. People get into real life-and-death situations every day, things happen that will determine the outcome of the remainder of their lives. Oliver (my brother) has to make choices in his work that really deserve the gravity and angst with which I sometimes view my code, and hearing about those things really makes me wake up to the reality of MY work. It means that I can see my craft for what it is: a hobby, a profession, but ultimately something that must bow to the truly important things in life. Thanks to him, I can attain some real perspective.

Monday, May 5, 2008

Maintaining Discipline

Last weekend, I made a huge mistake.

As I've alluded to in previous posts, I'm currently working hard full-time on my prototype for a startup venture, and that means I've been coding a lot. Around the time when the aforementioned mistake occurred, I was working on some pretty feature-rich tasks, and I just wanted to get them done. I felt like I'd been treading water for hours, and I was tired, and I needed to get a new build out. Because I'd set a goal for myself of getting features X,Y and Z done that evening, I was despairing the time still in front of me. I had tests to write for each of the new features I wanted to add, and some code segments were going to be rather duplicitous and would be begging to be DRY-ed up. Unfortunately (for the code), I was tired and in a foul mood and I decided that if I wanted to get to bed I would just have to slap the code in and worry about the other crap later. In 30 minutes, I had a new build on the server (tested by me in a web browser) and I was in bed. Woo-hoo, a victory every insomniac can appreciate!

Then the next morning came. I opened up my code editor, and realized that I was faced with a conundrum. Usually the very first thing I do, before checking my backlog to see what I want to work on next, is run my tests (even though I haven't changed anything from the night before). That gives me the confidence to move forward knowing that everything I've written in the past is still doing what I intended for it to do. That morning I had no such confidence. I couldn't even press the button to start them because I was afraid to see what my test suite would look like; as I recalled my actions of the night before, I was overcome by a feeling that could best be described as a hacking-hangover, complete with all the remorse that accompanies the alcoholic variety. I had broken discipline, and now I was going to pay. I had an unpleasent decision to make: lose productivity that morning to clean up what I'd done the night before (write all the tests I skipped, abstract out all the junk I'd hardcoded, refactor out duplicated blocks, the list goes on), or press on adding more features while basically blind as to their effect (save a manual test-fest through a browser).

Of course, being the responsible steward of the code that I am, I chose the former, but during those next few hours I kept thinking to myself "what the f%#@ made me think THIS was a good idea?". I couldn't believe that after everything I've read, written, and experienced that I'd still fallen for the lie that I could just fudge the process "just this once". Please, I beg of you, learn from my mistakes!

Here's what goes through my mind everytime this happens:

- doing any task takes time
- writing tests is a task (1)
- writing code is a task (2)
- refactoring (code and tests) is a task (3)
- only task-2 actually contributes to production features
- THEREFORE task-2 alone will produce the same end result as all three tasks, and in less time.
- I'm "tired" [substitute "bored"/"hungry"/"impatient"/"an idiot"]

These are the ingredients for a most unpleasent recipie. You jam out some of the ugliest stuff you've ever written, but your goals are accomplished, so you can move on. Do NOT fall for that crap!

You must remind yourself, in your weaker moments, that you use this process for a reason. One might say "but Ethan, I DON'T use that process, by 'sacrificing' your automated testing and refactoring you actually were just coding the way I do every day!". If that works for you, great, but that won't cut it for me (or anyone who ever works for me). I make mistakes all the time: I write tests so that no one else ever has to find out. I am lazy and hate doing maintenance work: I refactor my code so it will take as little time as possible. When I don't do those things, I hurt myself and create debt I'm just going to have to pay back later with interest.

What interest?, you might ask. Aren't you just defering a set amount of work until another day?

I feel that the answer to that question is no, for a couple reasons.

1) writing each test BEFORE you write the code to pass it (TDD) means that the code only does what you need it to do, and you don't waste time prematurely throwing in bits you won't need.

2) even if you write the tests afterwards, doing it in the same session means that you still have the code fresh in your mind so you can test what you need to quickly and efficiently. Doing it later means, in the best case, that you will have to spend a little time refreshing yourself on what that block of code does. Worst case, you will feel rushed and anxious to get on to something that's actually producing new features, and you will miss things that you will have to come back and fix later costing MORE time.

3) belated refactoring means that you only remember that you have to change that code in more than one place after you only changed it in one place and it broke. Try saying THAT five times fast.

4)You might not end up coming back to it at all, costing you or somebody else time when they have to fix a bug or add a feature and they have no easy way to tell if they've broken anything in the process.

If you are tired, go to bed, you can finish in the morning; Or, go ahead and play the hero for a night by staying up and doing it the right way. But for God's sake, the worst possible thing you can do is feel that you're doing yourself a favor by cutting some corners for a quick payoff. Reader, I implore you, don't let my failings be needlessly repeated.

Friday, May 2, 2008

Freshly Minted

I'm working pretty hard on my prototype right now, so I don't have a whole lot of time for lengthly blog posts. Nevertheless, a website caught my attention today that deserves talking about, so I'm making a brief exception. I'm pretty anal about tracking my finances, so in the past I've always used Quicken. I used to think this program was pretty good, but it just doesn't compare to mint.com. With mint.com, you connect all your accounts to one central location, and it takes care of all the integration you would expect from such a service. It downloads and updates your transactions and accounts automatically, thus tracking your spending patterns and the progress of your net worth for easy analysis by you at anytime from any computer. Furthermore, it lets you know how you stack up against the average money handler out there. Check it out, it's free, and you won't be disappointed/