Technologically speaking, it is very similar.  The way you interact with it, however, is different.  The applications don’t feel like mobile apps.  They are robust, full featured and intuitive.

Related posts:

1. Design Is Communication
2. Why is Apple discouraging interface consistency?
3. Design Last Design
4. Beginning Web Design Workshops

While there is a certain truth to this, there are many viable reasons for product manuals to be used. There needs to be a certain level of competency that can be achieved without the manual.

A manual is never an excuse for poor design.

Your product should be designed to encourage people to experiment. That’s how people learn how your product works, and it is also how they discover advanced functionality.

For example, Google SketchUp encourages you to grab the basic 3D modeling tools and start playing around. The manual becomes necessary when you need to do something more advanced.

You cannot make every feature equally intuitive.

As software products grow, they typically become less usable. Complexity breeds usability problems. It’s impossible to add features to an application without making the interface more complex. We can mitigate this in a couple of ways:

1. Don’t build any features which aren’t absolutely necessary
2. Don’t give all interface elements equal weight.

The first item is what makes people love or hate 37 Signals applications. They are simple and intuitive, but lack advanced features. For that reason, they are able to have maximum control over their UI designs, and thus, have some of the most intuitive applications on the web.

The second item is what Microsoft fought against with the new release of MS Office. For years the number of buttons on our toolbars grew. Our menus were stuffed full of items we never used. Yet, they were given equal weight to those that we do use.

Microsoft had a number of innovations to solve this problem:

• Customizable Toolbars
• It learned which items you never used, and hid them.
• Eventually, the Ribbon Bar replaced the old toolbar paradigm.

Even with these problems, Microsoft Office was a success because their interface encouraged people to experiment and play.

When you first start Microsoft Word, you are given a blank document with a cursor. You can type, format text, insert images and more, all without reading the manual. When you get into more advanced options, like embedding documents or mail merge, you look up what you need in the manual.

Overwhelmingly Scary Interfaces

Sometimes we come across applications which do encourage us to play, but still frighten us. Photoshop is the classic example. They encourage us to play, but not in a real world context. You can easily start a new document and draw all over it, but when you need to really do something specific, you get scared.

Simple tasks, like changing text size, changing font colors, and image cropping can be scary to a new user. Let alone advanced image slicing tools and warping utilities.

Photoshop failed in making a sandbox to play in. Instead, they scare you with a blank slate.

The O’Reilly Publishing company has capitalized on this fear with their “Missing Manual” book series, which has become very popular.

Discover new features as you go

Music publishing software is dominated by two products: Finale, and Sibelius. Both encourage you to start composing by giving you an empty music staff, and simple tools to drop notes onto the staff. It keeps the spacing clean for you, encouraging you to continue playing.

Over time, you discover new ways to enter notes using a MIDI keyboard. While these features are much more efficient, the products encourage you to play the easy way until you discover them.

I encourage you to take a look at your interfaces and discover new ways for people to harmlessly experiment with them.

Related posts:

1. Why is Apple discouraging interface consistency?
2. Designing the User Experience
3. Simple user interfaces are not always easier to use
4. Flip3D vs. Expose

One of the key issues in this space is the lack of a good IDE for developing media rich websites without Flash. That’s what makes Flash so attractive to designers, the ease of creating these multimedia based websites. Dreamweaver doesn’t come close.

Over the last few years we’ve seen major Flash studios, like Fantasy-Interactive, make the move to web standards.

Even though HTML/CSS/JS is far more semantic, more accessible and more flexible, we don’t possess the tools to build a really top-notch IDE.

The bigger question is… should we bother building such an IDE? I’m not so sure. It’s the transparency of the markup that makes HTML/CSS/JS so accessible. Abstracting that markup in an IDE would probably bring along the same issue’s that plagues Flash today.

Related posts:

1. Why Flash is Mostly Bad
2. Unobtrusive Javascript Controversy
3. Reasons to Validate
4. Beginning Web Design Workshops

eBay's Registration, as an example

Why it’s overlooked:

• Checkboxes are small, particularly ones which aren’t grouped in a fieldset;
• They are typically at the bottom of a form – Out of sight out of mind;
• They are placed in close proximity to a larger button which takes the focus.

This checkbox is completely unnecessary, and it’s purpose can be handled in a much more graceful manner.  Most popular websites have fixed this issue, while most less popular websites have not.

The “I agree” checkbox is the leading cause of form validation errors. In my research, about 1/3 of participants in our studies miss the checkbox the first time around.  Even though the problem is easily corrected, people occasionally abandon the form altogether when it fails validation the first time.

This error pattern sticks out like a sore thumb when you see it in action, but goes completely unnoticed when you aren’t observing real people using your form.

Replace with a quick sentence: “By clicking the ’submit’ button, you agree to our terms of service.” The legal contract is the same (as far as I know), without the added point of failure.

Twitter's Registration Process

Twitter’s registration form is pretty straightforward and simple.  However, by placing the “I agree” sentence beneath the button, it will lose some attention.

YouTube's Registration Process

Google gets it perfect on their YouTube registration page by visually grouping the sentence with the submit button.

Basecamp's Registration Process

As usual, 37Signals takes it a step further and emphasizes this with excellent copyrighting and design on their Basecamp signup page.

Related posts:

1. How to Label Submit Buttons
2. Amazon.com Redesigned for the better?
3. New Browser Windows
4. The difference between User Research and Usability Testing?

Back in 2001, while a music major in college, I started doing some freelance work on the web. Pauline, an independent jeweler in the Los Angeles area, became my first client. Not only was she my first client, but she stayed with me for 9 more years until her passing last week.

Pauline taught me many life lessons:

• How to pick a good business partner;
• How to always be professional;
• Ethics matter more than money;
• Separate business life from personal life;

… and my favorite …

• How to find beautiful women to pose for photographs. (For her jewelry catalog, of course…)

Pauline is the reason that we developed Sandstone, the software framework that now powers all of our business. Our ecommerce product Simpli5 was born out of an ecommerce website we built for her years before. The tools that built Pauline’s website also built our little business.

Business aside, I had many memorable conversations with her on the phone after work. When my wife and I were married almost 3 years ago, we had Pauline design and create her wedding ring. Each time we look at the ring, we will remember the love and care that she spent creating it for us.

I never had the pleasure of meeting Pauline in person. It’s amazing to think that this woman, whom I’ve never met face-to-face, could have such an impact on the life of a young guy in Ohio.

Thank you Pauline. Memory Eternal.

[obituary]

Related posts:

1. New Years Resolutions are for Lazy People
2. Paper Prototyping vs. Balsamiq Mockups

Traditionally, the analysis portion of a usability session takes quite a long time. The end results is usually what I call a “Dead Document.”

“Dead Documents” are reports that have value, but negatively impact productivity. This is usually because it takes too long to create the document, or there isn’t enough time to consume it.

I have developed a quick and dirty system for analyzing the data. It requires only a few hours to create and only a few minutes to consume.

Conduct a quality study

The quality of the results directly depends on the quality of your study. For the purposes of this post, I’m going to assume that your study was conducted properly. (Quality questions, good prototypes, people in your target demographic, etc…).

Use your brain

Even though you were the administrator of the study, you were also a participant. Your brain already has a good idea of the results. Take a few moments to write down your hunches. I like to mindmap, but you may prefer to doodle or freewrite. You should not worry about structuring or organizing your thoughts, just let them flow out of your head and onto paper.

Here are a few examples:

“A few people had a hard time understanding how the dropdown navigation works. I think it’s because they were distracted by the dancing Santa Claus on the opposite side of the screen.”

“It was obvious that people weren’t seeing the ‘logout’ link, even though I thought it was fairly obvious.”

In the next steps, we will try to prove or disprove your theories using the real data you collected.

Prepare to Review

Write down the questions or use cases that you asked your participants to discuss. We are going to grade each response with one of the following values.

• 1 – Indicates that the user was able to complete the test without assistance.
• 0 – Indicates that the user was able to complete the test after some help.
• -1 – Indicates a complete failure. Could not complete the test even with assistance.

In the end, we will sum up the results to come up with a pass/fail score. Before we can do that, we need a baseline score to compare against. Before you review the tapes and notes you need to decide what you think a “passing” score should be.

For example: You were testing a login form with 5 participants. Since this is a crucial feature to get correct, a score of 5 (all participants passed without assistance) is your baseline.

Another example: You were testing the ability to rename a bank account inside an online banking application with the same 5 participants. This is not critical, so a passing grade of 3 may be acceptable to you.

Another example: You asked the 5 participants to explain how they would contact support if they were having problems. A score of 4 would be acceptable here.

I setup a simple spreadsheet to keep myself organized. This easily translates into a deliverable document once completed.

Analyze the Results

Start reviewing your tapes and notes to extract the results of the tests, and plug them into your document. Write down any observations that you think are important. Keep track of things that were said that may be important later.

Sum up the total results across the participants and compare that with your baseline. I like to notate passing and failing tests in red and green.

Write a short paragraph for each test indicating the level of success, and a note about what was done right or what could be done better. Note anything interesting that your participants may have told you.

Write an overview paragraph at the top of the document explaining the results of the test overall. Which areas of the system need the most improvement, and which are working well.

The finished document is usually 3-5 pages of information which can be quickly scanned and understood.

Related posts:

1. Why You Should Outsource Usability Testing
2. The difference between User Research and Usability Testing?
3. Usability Review: OldNavy.com
4. Making CAPTCHA Usable

The answer to both of these questions is yes.  Technical stories represent efforts necessary to improve the infrastructure of a system.  While they do not add value to the system through the addition of new or refined functionality,  they do directly add value to the system in other ways.

It is our responsibility to identify the value directly added by each technical story, and to educate the client on this value.  It may not be as quantifiable as the value of new functionality, but it does exist. Better system stability, lower vulnerability to security or other malicious attacks, enhanced scalability and more robust disaster recovery all intrinsically add value to a system.  Value can also come in the form of more efficient future development, and the associated reduction in cost or schedule.

In the article, Jack observes:

But what about the type of story asked by one of the members “As a development team member, I want the existing unit tests to run under CruiseControl, so that I know if anything breaks”. Where does this belong?

Well this is a perfectly written story but the story really has no ultimate value for the end user at least not directly.

I disagree with Jack that such a story does not have an ultimate value to the end user, or that it’s value is at most indirect.  Automated unit tests allow the development team to deliver new features to the end user much faster.  Every feature added to a system has a value, therefore the lack of any given feature has an opportunity cost.  The direct benefit to the end user is the reduction of that opportunity cost.

If I am unable to articulate the direct value of a technical story to a client, I have no business doing that story let alone asking the client to pay for it.  Effort without value is waste.

We include these infrastructure upgrade tasks in our project MMF workflow.  Cards are written for them, and these cards are added to the project backlog.  Once educated to their value, our clients are then empowered to make priority decisions between technical infrastructure tasks and new features.  We must trust that the customer knows their business the best.  They will know if the opportunity cost of a delay in the implementation of feature X is of higher value than the future cost and time savings of a conversion from Scriptaculous to JQuery, and will set the appropriate priorities.

Related posts:

1. Eliminating Waste from your Agile Process
2. Agile Development for Tiny Teams
3. Our New Development Process
4. Workflow – Minimally Marketable Features

I’ll be podcasting, blogging and networking all week.  If you are around, make sure to hunt me down.

Are you attending?

If you are attending, post in the comments so we can find each other this week.

Related posts:

1. Codemash Presentations That You Won’t Want To Miss
2. Goals for 2009
3. Why we need another CMS
4. CWSA Looks Promising

Interface First Design

I’ve always been a supporter of Interface First Design. To your customer, the interface is the product. The customers needs are all defined by the way they interact with your product. This is why we have always encouraged designing the interface before writing any code. This keeps developers from over-engineering features and ensures the customer gets what they expect from you.

However, I often find myself over-designing. I waste a lot of time designing things that will be deleted in future iterations.

Introducing Design Last Design (DLD)

Recently, I’ve been experimenting with what I call “Design Last Design.” Essentially this means we sketch out a user interface in the beginning, as we always have, but we don’t pretty it up. We build the whole application in greyscale with standard fonts, and boxes, but nothing pretty. Near the end of the project, we wrap it all up with graphic design. The interactions are all still designed up front, but the graphic design is laid on at the end. We don’t waste time on graphical details which are not yet important.

Focus on the customers needs and build a crude UI which fulfills them. The UI can, and probably will, be ugly. That’s ok, as the purpose of this step is to gather feedback on the interactions, not the graphic design.

It feels like you are building a wireframe in OmniGraffle or Visio, except with real behavior underneath.

Our customers have appreciated this process, since it makes design changes easy. We can juggle elements around the page or move things from one page to another. The whole application is working and can be played with. We can do some pretty intensive usability testing on these interfaces too.

The goal of this process is to collect as much feedback about the interactions of the application as possible. When customers know that design is not-finished, they are more open and honest with their comments. The cost of implementing change is less. When we are ready, we can start to lay a graphic design on top of it.

The quality of the finished product is always better than our previous methods, without an increase in development time.

Related posts:

1. Design Is Communication
2. Designing the User Experience
3. Beginning Web Design Workshops
4. Designing Data Collection Forms

Our transition to a lean development process was the first exposure most of our clients had had to any type of agile environment.  Understandably many of them felt out of their element and truthfully we felt the same way.  What really made the transition successful for us and our clients was the trust that came from the good relationships we’ve maintained.  Being very transparent with our clients went far in cementing that trust.  We let them know that this was a major change for us too, that we were (and still are) learning and refining our process.  Since our clients are very much part of the project team, I openly solicited input from them on how we could improve the process.

Kanban Boards

We employ separate MMF Kanban boards for each client’s project.  Each board has the following queues through which the MMFs flow:

1. Backlog – This is an unordered list of all MMFs that have been conceived. This queue has no limit. It serves as a dumping ground for ideas as simply existing in this queue does not imply any commitment that an MMF will ever be implemented. MMFs in the Backlog may or may not have an estimate.
2. Pending / Scheduled – This queue is prioritized with a limit of 3. Barring priority changes, MMFs in this queue are committed to development. A planning meeting with the client is triggered when this queue reaches 1 item. During this planning meeting the next two MMFs to be developed are identified and added to the queue in order. The client is welcome to change priorities at any time, reordering the queue or swapping MMFs from the Backlog. All MMFs in this queue will have an estimate.
3. Work In Process (WIP) – To address our goal of reducing WIP, this queue has a limit of 1. It is while an MMF is in this queue that the nested, story card based workflow is employed.
4. Acceptance Testing / Show & Tell – Again, to reduce WIP, this queue has a limit of 1. Once the MMF in this queue is ready, a deploy of the software is triggered.

Estimation

Each MMF is given a “shirt size” of small, medium, large or extra large.  These estimates are assigned at any time while the MMF is in the backlog queue.  Sometimes estimates are assigned when an MMF is added to the backlog.  Other times an MMF does not receive its estimate until we are about to pull it into the pending queue.  There is no scientific method for determining the shirt size of a given MMF. It’s a simple process of assigning a “gut feel” based on the description of the MMF.

Even though there is no formal process to calculating them, some of our clients have found them quite valuable in helping determine priority.  We’ve had clients make the decision that the combined value of 3 small MMFs outweighed the value of one large MMF, and pulled them into the pending queue ahead of it.

Once MMFs have been pulled into the pending queue, the estimate serves as the primary tool by which we can answer the client’s question of “How long until I have this?”

Estimates are not carved in stone.  As we work, we understand the scope of an MMF better and uncover knowledge upon which we are able to make a better estimate.  Sometimes development of a higher priority MMF will impact the estimate of an MMF farther back in the workflow.  The more accurate our estimates, the more valuable and useful they are.  We update our estimates as necessary for the overall good of the system.

A change of more than one size, such as small to large or XL to medium, does trigger a review as to why we are making such a significant change to our original estimate.  Even though the process of setting an estimate is one of an educated guess, we do want to continue to improve our ability to make accurate guesses.

Data Tracking, Trailing Indicators and Their Application

There is a significant amount of data that exists around just this part of our development process – enough to keep a data mining, business intelligence geek busy 40+ hours a week.  The truth is, however, that if I were to spend my time doing analysis of our process – there wouldn’t be enough flow through the process to generate data worth analysis.  We are a tiny team of 2, after all.  I applied YAGNI, and we are only tracking the couple of data points that are critical to our management of the system.

For every MMF, we track the date it is pulled into the WIP queue (start date) and the date it is finished in the acceptance test queue (complete date).  From those two dates, we are able to calculate and record the MMF’s cycle time.  We do not record any additional data points for MMFs.

We log MMF cycle times by complete date and estimated size.  I maintain population means by estimate size, rounded to a full day.  I’m then able to use these averages to compute the answer to the client’s question of “How long?” by applying them to all MMFs ahead of the one in question.  MMFs in the WIP or acceptance testing queues  are included by determining days left as the difference between start date + average days and today.

Flexibility to Interface with our Client’s Business

Each client and each project will naturally be a little bit different than the last.  We have adapted this workflow a little bit to better fit with our client’s business process.  For one client, we expanded the limit for the pending queue to 5.  This allows for a longer interval between the triggered planning meetings, which fits better with his schedule.  For another client we actually maintain the backlog as a collection of different lists of MMFs – one for each functional area of the project.

Kaizen

Our goal is to work towards the most efficient and effective process for developing software for our clients.  Just as I solicited input from our clients for improvements, I’m very interested to hear your feedback on this workflow.

Related posts:

1. Our New Development Process
2. Technical Stories in Agile Software Development
3. Agile Development for Tiny Teams
4. Eliminating Waste from your Agile Process

With the new year upon us, it’s that time to make our resolutions. But, why do we wait to do this at the beginning of the year? If change is needed, make the change now.

I came to realize the problem with this a month ago (beginning of December). I’m a typical geek. I sit in front of my desk for about 12 hours a day, and most of my exercise comes from walking to the restroom down the hall. Needless to say, I’m not a perfect specimen of health. I’m not fat by any stretch, but I’m not in shape and I could eat healthier. So, like many I decided to do something about it this year and make “focusing on my health” my resolution for 2010.

Except for one small problem. I needed change NOW, not starting in a month. Waiting a month to start to change would make my problem worse. Suffice to say, I joined the gym that day and today (Jan 1), I’m already feeling much better.

What change do you need in your life?

• Do you need to blog once a week?
• Do you need to stop checking email every 5 minutes?
• Do you need to treat your wife and family better?
• Do you need to eat out less and cook more?

Do it now, and start reaping the benefits now.

Related posts:

1. Goals for 2009

We determined that our new process needed to be:

• Simple – Being a tiny team, the impact of time used managing the process rather than used generating billable work product is magnified.
• Able to handle concurrent projects – We needed to be able to support ongoing development needs of current clients while continuing to develop new clients and projects.
• Scalable – We will add subcontractors to our team as needs arise. Our new process must work regardless of the team size. It also needed to be easy to teach to new team members.
• Flexible – In addition to client work, Josh and I are partners in Prfessor.com which includes a significant amount of development efforts. The process needed to be flexible enough to manage these obligations too.
• Waste Reducing – We needed to address the four top areas of waste that I identified in our original process (see Eliminating Waste from Your Agile Process)
  • Work In Process (more than the bare minimum necessary)
  • Rework
  • Over-engineering the code
  • Repetitive tasks

From Jon’s presentation I realized that we really had two separate workflows, one nested inside the other. We never formalized that distinction, but when we began to view things in terms of MMFs (Minimally Marketable Features) the nested process jumped right out. Understanding this nesting was critical to the success of our new process.

MMF Workflow

Our MMF workflow is a customer facing part of our process. It relies upon regular input from the client and is the primary interface for our clients into our development process. Clients are welcome to look further into our process and see the details of their project. We have found that some clients prefer to let us completely handle the details. Our new process provides the ability for them to be involved in the process without being overwhelmed by the technology and implementation details.

MMFs flow through a 4 queue process:

The MMF workflow is the part of our business process that needs to interface with our client’s business processes. We found that providing the flexibility for our process to adapt to some level to fit the client has been very valuable. For example, for one of our best clients we maintain multiple Backlog queues – one for each aspect of their application. This organization of MMFs has proven valuable to them in support of accurately setting priorities. Another client was more comfortable with a larger Pending queue as it provides an increased interval between triggered planning meetings. We try, however, to keep this queue limit as small as possible in order to avoid thrash in the queue due to changing priorities.

Story Card Workflow

Nested inside our MMF workflow is our Story Card workflow. This is where the actual coding efforts are managed. The MMF workflow addresses behavior while the Story Card workflow addresses implementation. The MMF workflow is the customer facing portion of our process. The Story Card workflow is primarily for internal consumption. The first thing that happens when an MMF is pulled into the WIP queue is for story cards to be written defining implementation details. .

With our unique but complimentary skill sets, our original workflow was implemented through Kanban queues through which story cards would flow:

Estimation

Clients have consistently presented us with two common questions – “How long until I have this?” and “How much will it cost?”. Obviously the answer to both questions involve some level of estimation. We have formalized the process of estimation towards the primary goal of answering those two client questions in a consistent manner. MMFs and Story Cards are estimated using different methods.

MMFs are given a “shirt size” of small, medium, large or extra large. There is no scientific method for determining the shirt size of a given MMF. It’s a simple process of assigning a “gut feel” based on the description of the MMF. As further understanding of the scope and meaning of an MMF is gained, it is acceptable to change the assigned estimate. Continuous improvement applies to the estimates assigned too. These shirt sized estimates are used along with team performance data collected through the process to answer the question of “How Long?”

Story Cards are assigned a point value. We use the binary sequence of 0,1, 2, 4, 8, 16 as valid point assignments. We’ve determined that if a card should be assigned more than 16 points, it should be further broken down into smaller cards. To date, we have found that 8 points tends to be the largest value commonly used. Point assignment happens as the story cards are written, prioritized and added to the Backlog. We have transitioned from billing our clients by the hour to billing them by the point. These point estimates therefore easily compute to provide the answer to “How expensive?”.

Concurrent Projects

One of the most simple parts of our new process is the management of multiple concurrent projects.  We have set agreements with our clients, committing to a specified number of average points per week of development velocity.  With the rhythm of the development process, the actual weekly velocity for a given project varies.  We track our performance on each project to ensure that on average we are meeting our commitments.  Our clients have embraced this process as it provides them with both steady progress on their projects as well as a predictable monthly invoice from us.

For example, we have calculated that Josh and I can produce an average development velocity of 35 points per week.  Currently we have committed 10 points per week to one client and 15 points a week to another client, leaving us with 10 points per week we can employ on either project as necessary or on internal projects such as Prfessor.

Kaizen

Even though this process is serving us well today, we continue to improve the process.  Planning and writing this series of posts has triggered a number of ideas for ways we could further refine our process.  I know that external review of a process can many times uncover issues that those involved in the day to day operations miss.  I’d really enjoy hearing your feedback on our process, or about a process you’ve implemented to solve similar challenges.

Related posts:

1. Technical Stories in Agile Software Development
2. Workflow – Minimally Marketable Features
3. Agile Development for Tiny Teams
4. Eliminating Waste from your Agile Process

I have compiled a list of talks that I know you’ll enjoy.  Some of these I’ve heard previously, and others are presented by people that are always interesting/entertaining.

Starting Up Fast- Lessons from the Rails Rumble

A shameless plug for my own talk – I’ll be moderating a panel with Joe Fiorini about the RailsRumble contest, interviewing past participants and winners.  Panelists include:

• Joe Fiorini – winner 2008
• Josh Walsh – winner 2008
• Jonathan Penn – winner 2008
• Jim Weirich – participant 2008
• Josh Schramm – participant 2009
• Matt Yoho – participant 2009
• Josh Owens – winner 2007

An Introduction to Cucumber

Presented by: Leon Gersing – I saw this talk last month at the Cleveland Ruby Brigade event, and it was superb.

How Do You Do That on iPhone?

Presented by: Chris Adamson – I got to know Chris last year, and participated in his all day iPhone workshop.  His new book on iPhone development is awesome as well.

Oh Crap! I forgot (or Never Learned) C!

Presented by: Chris Adamson

Patterns: Studying not Stealing

Presented by: Carol Smith and Jon Stahl - I’ve been fortunate to work personally with both Carol and Jon on projects in the past.  I always learn something new from them.

Refactoring the Programmer

Presented by: Joe O’Brien – Joe’s company, EdgeCase, is on the bleeding edge of Rails development in the world.  Don’t miss your chance to learn from one of the smartest programmers I know.

Seeing Constraints, Kanban Explained

Presented by: Jon Stahl – This is the talk that revolutionized our business.  It’s the leanest and simplest process for software development.  Pure Gold.

SOLID Ruby

Presented by: Jim Weirich – After hearing Jim speak a few times in the past, I made a rule to never miss another Jim Weirich talk.  You shouldn’t either.

Source Control for People Who Don’t Like Source Control

Presented by: Jim Weirich – I am under the assumption that this is going to be similar to the  screencast that Jim put together for Pragmatic Screencasts.  I hope so.

Testing the Enterprise

Presented by: Leon Gersing and Charley Baker – Leon had interesting insights about bringing agile development and BDD to the Enterprise through his work at Gap.  This should be very interesting.

What Makes Ruby Different

Presented by: Joe O’Brien, Mark Peabody and Leon Gersing – Ruby is an interesting language that is growing quickly.  They live and breath this stuff, and have interesting insights into what makes Ruby people tick.

WTF 2.0: A Guide to Building Social Applications

Presented by: Anthony Broad-Crawford – Anthony is the CTO for Within3, which develops social networks for the healthcare industry.  I’m proud to work with them on the development of their products routinely.   He’s pushing hard on the limits of social media and has a lot to share.

Come Find Me

I’m on a mission this year to meet new people and learn about their businesses, particularly startups and entrepreneurs.  Drop me a tweet, and let’s connect while we’re there.

Related posts:

1. Who’s Attending Codemash 2010?
2. Goals for 2009
3. Why We Are Not Hiring
4. CWSA Looks Promising

Thank you for making 2009 an awesome and prosperous year for us.

Related posts:

1. Goals for 2009
2. Why We Are Not Hiring

“Trying to strike it rich, eh?”

Truthfully, I don’t think he understands how I feed my family, but that’s ok.   But, this story does bring up a question that’s raised all the time among prospective entrepreneurs.

Can I strike it rich if I go on my own?

My response is always “yes and no.”  Chad Moutray, the Chief Economist of the Office of Advocacy of the U.S. Small Business Administration, published some of his research on the income likelihood of entrepreneurs.  His research backs up my response nicely.

Chances of Striking It Rich

If you want to be wealthy, then entrepreneurship is your best shot.  I’m not talking about being super wealthy, rather making a consistent $100,000+ income each year.

Chances of being Dirt Poor

However, entrepreneurs are also the most likely to live below the poverty line (by a wide margin).

I just want to Make a Decent Living

If your goal is to make an average income and live comfortably, you are better off getting a “real job.”

Related posts:

1. The difference between User Research and Usability Testing?