Archive for the 'Software' Category

The power of data aggregation

Lately, I’ve been thinking a lot about marketing.  Now that Lasso has a first version out in the wild, my focus must shift to reaching my potential customers.  One challenge that i will have in this task is the fact that I, personally, am not a potential customer of my product (i.e. I’m not a business owner, the customer that i need to reach first).

Now, I don’t have a lot of experience in marketing (read that: none), but intuition tells me that step #1 in being a good marketer is having a deep understanding of your customer and your market.  So, the question then becomes, how do I gain deep insight into how and why business owners make decisions about how they reach out to their customers.

One of those is, of course, directly visiting businesses.  I talked about this in a previous post and it is still the #1 way to gain insight.  But unfortunately, visits take a lot of time and resources.  I want to find more ways to learn from the experts.

Being the self respecting techie that I am, I naturally turn to online resources to begin my learning process.  I’ll start finding industry blogs.  I’ll find influential + knowledgeable people on twitter.  I’ll start reading relevant news. etc.  There’s 2 problems with that approach

  1. This type of knowledge seeking falls in the “know that i don’t know” category.  Useful, but I’m less likely to be surprised
  2. It’s pull not push.  By that I mean, I have to seek out the information i’m looking for.  And if, for some reason, i don’t do it for a few days I am liable to miss interesting opportunities.

Enter the wonderful world of data aggregation.  This weekend, I spent about 3 hours setting up a series of data feeds that will deliver the news and information I need right to my feed reader.  Using a combination of Google Blog search, Google site search, Postrank, Twitter search, and last but not least Yahoo Pipes.  I made a very simple way to keep on top of all relevant and interesting news + articles about the restaurant industry.  The great thing is that although the breadth of information that I am pulling is quite wide, the amount of information that i have to process is pretty low (thanks to awesome services like Postrank).

Now, it’s certainly not perfect yet and i still have a lot more tweaking to do, but I’m feeling confident that, used properly, powerful tools that allow for this type of data aggregation and transformation  will (and certainly already are) positively transform the way that we think about market research.

Adobe AIR: Introduction and Overview

As I was preparing for tomorrows RIA Meetup, it dawned on me that it probably would be a good idea to use my blog as a way to both document and share the work that goes into the meetups. From now on (time permitting), every time we have a meetup, I’ll try to accompany it with a blog post.  Now on to the content:

Adobe AIR is runtime environment that liberates RIAs from the browser and brings them right onto a users desktop.  When I first heard of a AIR prior to it’s formal release, I (mistakenly) thought of it as an extension to the Flex SDK.  While this is correct in a limited sense, defining AIR in this way is too narrow.

In truth, AIR is desktop runtime that enables developers to build rich, web-enabled applications that are installed on a users OS.  Developers can build AIR apps with their choice of Flex, Flash, and even DHTML.  In the rest of this post I’ll build a case for why one would choose AIR and how AIR development differs across technology choices.

Why Choose AIR?

As you do when designing any software product, technology choices should be driven by customer requirements.  Here are some of the customer requirements that would start to point me toward AIR

  • Daily use.  A customer will use your app frequently and is willing to install the application (an extra step compared to viewing a web page) because it is accessed often
  • Connected.  The application relies on data out in the cloud.  It’s probably multi-user or social in some way
  • Need for offline use.  If offline use is a requirement, this could be a big push to AIR (or google gears, or some other local storage technology)
  • File system access.  Will the ability to read / write files on the users local machine enhance the usability or experience of the product?

Now let’s move one click down to some of the technical advandages you gain when choosing AIR

  • Your product loads faster.  No SWF DL or HTML page load.  Your code is local and will boot up faster
  • Multiple ways to store data including
    • File system access.  can read / write files
    • SQLite database
    • normal “browser-like” approaches like cookies
  • Desktop notifications.  notify users when there is some sort of state change
  • Control over the window.  Removing the standard looking window chrome does a lot more than you think to enhance the look and feel of your app.  the window can even be transparent… ooooh :)

Using AIR with Different Technologies

Another very cool thing about AIR is that there are multiple ways to make use of the run-time depending on your background.

If you are a Flash developer, you can use your familiar Flash CS4 product to create AIR apps.  I know the least about this option, so I’ll move on…

If you are a Flex developer (like me!) you can build an AIR app in much the same way that you would build a normal Flex app.  You have an extended API at your disposal and the configuation of the app is slightly different.  This page does a nice job of explicitly listing out all the API differences between Flex development and AIR development.  I personally will gravitate toward this option since I think Flex provides a nicer development environment and UI capabilities than DHTML when we are talking about desktop experiences.  The other cool thing is that as long as you are careful, it should be easily possible to port an app between a pure Flex browser experience and an AIR desktop experience.

Last but surely not least is DHTML.  So for all you web standards lovers out there (and i consider myself among those ranks), you can translate all your HTML / JS / CSS skills straight to the desktop and create disconnected and/or file system aware experiences.  Pretty cool stuff!  DHTML development comes with a few caveats (not the least among them is that use of eval() is limited due to security concerns.  It is overcomable, but needs to be pretty intentionally designed).  I haven’t looked, but i suspect that there are probably some pretty good JS libraries out there to make DHTML + AIR development a snap.

Getting Started and References

So there is my 2c introduction to AIR and why i think it is a truly compelling platfrom.  It is, of course, not the the answer to every problem in the world; however, for a certain subset of applications, AIR is a wonderful addition to a developer’s toolkit.

To get started with AIR, head to this adobe page and follow the directions.  In the Meetup, I plan on exploring the the APIs around windowing (including notification mechanisms in the system tray or application bar) and file read/write capability.  Obviously there is much more available, but i have a feeling we’ll be pressed for time with just that.

While preparing, i used the following very helpful references

thanks and have fun with AIR!

Learning from customers: 3 ways to improve

Over the last 3 weeks, I’ve spent quite a bit of time doing interviews with potential customers of the product i’m working on.  I’ve done seven over the last 3 weeks and plan to do several more in the next few weeks.  I’ve had an awesome time doing all of them so far and learned a ton, not just about my product, but also about being good at doing interviews :)

After reflecting for a bit on what went well and what didn’t go so well, i think i have a few ‘take-aways’ that i’d like to make sure to remember for the next time around

1. The less I talk, the better

In an interview format it never ceases to amaze me how amazingly easy to lead a subject.  I don’t do this intentionally of course as my goal is to learn from them, not to lead them to whatever “answer” i think i have.  Unfortunately, on several different occasions, I asked a question or made a statement and then watched in horror as the person I was interviewing stopped, thought about what i said, and then changed course.  Ahh!  sometimes i open my mouth too quickly and unfortunately once said, you can’t take that thought back

2. Allow for “digressions”

Being the all-too-often linear person that i am, i generally get annoyed by digressions in conversation.  after all, in the case of an interview, I’m there for a specific reason right?  Well.. true but with interviews like these, digressions are actually a really powerful tool for two reasons.

First, it puts the interviewee at ease.  A quick question about something on the wall or the history of the building might not be what you take away from the interview, but it’s important to remember that the interviewee is usually nervous.  They aren’t sure if you are judging them or if there are going to give the “wrong” answer.  Digressions help them to relax.

Second, remember that there are 3 categories of knowledge: things you know, things you know you don’t know, and things you don’t know you don’t know.  If you never digress, you will never uncover things in the latter category.

3. Never answer questions (at least until the end)

Usually the interviewee is really nervous about doing something “wrong”.  They often become self concious and will start reverting to asking questions.  I do my best to resist the temptation to answer them.  Many times, questions will come regarding the product (if you are showing them one), but the topics can range a great deal.

It’s best to pretend you are a politician and just deflect the question.  “what do you think that means?” or even at times a little white lie like “i’m not sure” will help avoid the inevitable leading that will occur if you answer a specific question.  after all, you’re not going to be sitting there with them when they are actually trying your product :)

anyway, I’m still definitely just a beginner at customer inteviews, but i hope that this is a skill that i can continue to develop as i know that deep customer insight is a key ingredient to innovation, and speaking with customers is the main ingredient to deep customer insight!

Embedit.in

My brother’s company, Increo, just released a new product called embedit.in.  It’s a competitor to Scribd and gives you a really easy way to embed documents in your website.  Way better than forcing a download for something that you really don’t want to have to download.

They got a nice review here:

http://thenextweb.com/2008/12/23/embed-any-file-or-url-with-embeditin/

Check it out.  hope it’s useful!

Splitting a Team By Architecture: Bad Idea

Lets say you are working on a project where there are multiple teams all working toward a common outcome.  You are the manager and you sit down with your architect / lead developer (which could be yourself for all that matters).  You know the solution you need to deliver for your customers and you have started to sketch out a diagram of what your software system will look like.  Perhaps it looks something like the random image i grabbed on the left.

You scratch your head and say, “well, lets have team A work on the front end and team b work on the back end.  Well have joe manage team A and jane manage team B.”

Bzzzt!  While this is of course the most straightforward, neat, and logic way break up your development team.  Is is really the best?  My opinion, as you might have guessed, is no.  Here’s why:

One of the basic arguments for splitting a team up into front end and back is that developers on each team have less to learn.  They can focus on a smaller domain and theoretically become more skilled in that limited domain.  This makes good sense IF the main reason why a project fails is because developers didn’t understand their technical domain deeply enough.  Is that really the reason?  I think not.

I think one of the biggest reasons why projects fail is a lack of

  1. Deep understanding and focus on a customer problem (where a customer can be internal or external)
  2. Poor communication within a development team and around a development team.

So, if those two reasons resonate with you,  why would you split a team across front-end back and lines?  Splitting a team that way only serves to:

  1. Remove the back end team from direct exposure with the end customer
  2. Push communication channels up creating a bottleneck at the top

Lets go through my rational for why splitting a team causes these two problems and why they are so bad to begin with

Backend Team has less exposure to customer

All of a sudden, the goals for your backend team just completely changed.  What once was a common goal of “lets deliver a great product to our customer” just became “lets build a reusable/scalable/flexible/<insert quality attribute here> backend for the front-end team”.  While architecture purists might disagree with me, i think this is a very dangerous thing.  I’m all for great architecture.  There are few things more satisfying that beautifully organized code; however, this does not always deliever in the ways that you want to.  Remember what you are being judged on: how much the end customer loves what you build.  nothing else.

Pushing communication channles up

When you have two independent teams that report to different managers you are effectively moving lines of communication up through managers and their managers.  At first, this doesn’t seem like such bad idea.  Take the burden of communication off individual developers.  Let them focus.  Let managers communicate.  This theory is great when the communication is external.  Managers should be shielding the team from external distractions.  However, this is absolutely dangerous when the communication you are blocking is internal team communication.  Internal team communication is never bad.  In complex software systems, the more team members know what their other team members are doing, the better.  This helps to reduce errors, cut down on mismatched expectations, and increase developer confidence.  I can guarentee that 80% of this good mojo will get lost when it’s translated through a manager.  She just became a bottleneck for good communication.

What do we do instead?

For all the reasons I list above, create very small teams that are oriented around end-to-end features of your software system.  it’s okay for individuals to specialize in particular technologies or pieces of architecture, but make sure that all members of your team are focused on a common customer and make sure that they are forced to communicate with one another.  Sure, this is definitely trickier from a managers perspective, but that’s okay.  If you have a good team with good managers, they’ll be able to handle it.  Sure, it’s not going to look as pretty when you put your progress in some nice bar graph in PPT ’07, but how important is that really anyway :)

Why anonymous functions are cool

A few months into learning about Actionscript, I started playing around with anonymous functions.  I found them to be a convenient way to do some basic event handling quickly and easily while reducing the complexity of the code.

For review, an anonymous function in Actionscript looks something like this:

foo.addEventListener(EVENT, function (event:Event):void { bar++ } );

When you use an anonymous function in this way you gain two major advantages that I can see

  1. You are handling your event in the context of the request.  The code for the handler is in the same place as the code for the request.  This helps you to understand how your request will be handled when debugging
  2. The context of your request is held in the closure for the anonymous function.  This is a big point.  A closure makes is so that the variables which are in scope for the enclosing context will be available to the anonymous method.  This means that when your anonymous function is called back you have access to the variables which probably caused the method to be called.  Very helpful since otherwise you might have to preserve that context on your own.  much better to have the language do it

As I became more familiar with anonymous methods I started to use them in different ways to help me write more compact code (although it doesn’t always help readability).  For example, I often will create factories that output functions (along with their respective closure) to help reduce the amount of code I write.  Again and example:

public class Function Factory
{
    public static functionGenerator(foo:String, bar:int):Function
    {
        return function(woot:String):String
        {
            return foo + bar + woot;
        }
    }
}

Okay, so clearly a trivial example. Why was this worth the effort?  It was worth the effort for two big reasons:

  1. Because this generated function is now wrapped in a closure with the values that were passed in by the caller, we’ve just created a function that – while it looks the same to a future caller – is imbued with metadata that we inserted at runtime.  This means that the caller of this method didn’t have to worry about holding onto that metadata
  2. While what we did is semantically equivalent to instantiating a class and returning a member function of that class, the effect is less code and fewer files to clutter up a clients understanding of the API.  For a client, as long as they understand how to call the method (one of the downsides.  i wish there was a good way to typedef a function in Actionscript) they don’t have to worry about anything else.

So, I hope that was a brief but useful look at why anonymous methods in Actionscript are cool and useful.  I will warn however, they can be dangerous if used too much.  The closure can consume memory, and if you are not careful when doing event handling you can end up with some nastly leaks on your hands.  So all in all, be careful, but go ahead and use anonymous methods.  They help you out a lot!

ps.  This is my first post with the Code Markup plugin.  So if this doesn’t work right away, i’m still learning :)

Collaborate Through the UI

Over the last weeks and months I have started to develop a theory of team collaboration. I have watched my team struggle with 1) internal team communication 2) external communication, and 3) motivation. I have heard over and over again “we’re not making any progress.” “What have we been doing for all this time?” At first, I was wondering the same thing: where did the time go? After reflection, I believe that my team IS in fact making progress, it is just that we have 1) made progress on intangibles and 2) allowed ourselves to drift a bit more than we should.

I believe that a major cause for this is our selection of tasks over the past few months. We have chosen ‘explore’ type tasks. Or design tasks. or infrastructure tasks. All of these are important and eventually need to get done; however, focusing on them in isolation has caused some serious problems. Although we are all in software and all of us know and understand that there is a whole more more to software than UI, the reality is that people, human beings, react to what they can see, touch and feel. I believe that if we had allotted just 20% of the infrastructure time toward UI, those “what are we doing” questions would dissolve. The reason: we can point and say: “that. that is what we have been doing”

I believe that ability to point and say ‘that’ has the potential to solve the three problems my team is having. First, a UI (even a nascent one) causes the whole team to get involved. When there is an interface to see, Designers want to contribute, PM’s want to argue over features, and project managers can explicitly see the holes that need to be filled. Second, where there is a UI, it is much easier for managers to communicate with executives outside the team. Third, when progress is visible, the team is motivated to continue to make progress. It is extremely easy to get stuck in a design, research loop. Working on the UI helps to break this loop by making it more clear exactly what is necessary and unnecessary at lower levels of the application.

What I describe above is not dissimilar to the XP concept of flow. All i’m saying is that for many teams, motivation hinges in the ability to see the fruits of their labor. I think many teams would benefit from investing a little bit more in the UI sooner than what would seem natural.