Top posts for the month of February

I started up the blog this month, initially with a focus on recording my own personal thoughts. As the month has gone along I have received great feedback, both directly on this site as well as on LinkedIn and Facebook. Thanks to all for your participation.

Here is a quick run down of the five most popular post this month, based upon the number of views for each. Feel free to keep passing the link around, subscribe to the RSS feed, or simply popup back when you have time. I’ll be posting daily as I have no shortage of topics I’m anxious to write about.

• Steroids for developers, don’t tell A-Rod.
• Why waste time testing, developers can deliver 0 bugs…
• Tips for Staying focused.
• Win the lottery, choose the right startup
• A few thoughts on UI design on a budget

John

“There are many things of which a wise man might wish to be ignorant.” – Ralph Waldo Emerson

Emerson must have been an engineer, of sorts, as I’m sure he was thinking of metrics and how they can help, or hurt, your efforts to ship products.  No, I am not anti-metric.  I do believe that metrics are critical to good decision making.  However, I think it’s easy to go overboard with your metric gathering and analysis and never ship.

Here are the product development metrics I care about:

• Are we on schedule?  Yes or No.  ”Almost” is not a valid answer 
  • I use SharePoint for project tracking and monitor the schedule regularly.  Tasks not completed on time ultimately mean we will end up eliminating functionality, push out release dates, or cut back on testing which increases risk to the overall product quality..
• What % of the requirements have been completed?
  • At the end of the day it’s important to know if you’ve satisfied the business requirements.  Completing the functional requirements without having truly met the business requirements happens too often.  Don’t let it happen to you.
• What % of the requirements have been tested?
  • I need QA to think about the business requirements just as I need developers too.  We build products to achieve business goals.  We do not build products just to build products.
• How many bugs are currently open?
  • While it’s an imperfect measure due to the fact that not all bugs are created equal, it does provide useful information.  Track this throughout the project and avoid letting the open bug count too large.  If you reach the end of the project with a large number of bugs it is unlikely that you’ll fix them all.
• Did the release have the desired impact?  As you evolve your requirements process make sure you work with the business folks to define what the impact of this new product release should be.  Will it increase user logins by 10% a month?  Will it result in 25% more purchases?  Once you release the product stay on top of how the product has impacted the business.  If it failed to meet the goals specified or resulted in a negative impact to other key metrics, let people know.

What do you think?  How do these line up with what you track?

-John

What makes a great developer?

I was following along with a great thread in the .NET People group on LinkedIn that was discussing the differences between good and bad developers.   I’ve thought alot about this as I’ve hired developers for startups and here are the qualities I always look for:

• Understands that they must learn about the direction the product is going so that they can plan new development and bug fixes in a manner that is  in-line with the architectural direction the product is headed.
• They are able to meet the functional and technical requirements without having to be reminded to read the spec.
• They perform sufficient unit testing to ensure that QA doesn’t immediately report obvious bugs.
• They understand that mentoring other developers on the team is important in order to help raise the bar of everyone around them.
• They are passionate about the products and technologies they are using.

It is clearly critical that your early team members are strong with the technologies being used but that is but a part of the equation.  Passion for their craft and for the company is critical.  Early team members must be willing, and able, to wear multiple hats.  Make sure you’re focusing on finding great team players, not just great coders.

-John

Visual Thesaurus

If you ever use a thesaurus take some time and check this site out:

http://www.visualthesaurus.com/trialover/

The manner in which Visual Thesaurus visual maps our potential alternatives is highly intuitive and is by far the best alternative I’ve seen to date. While I could never convince myself to pay for the product I would consider buying it if I was a professional writer.
For user interface designers, engineers looking for new ways of building user interfaces, this is a site you should check out.

-John

Why waste time testing, developers can deliver 0 bugs…

While I have had this conversation at nearly every company I have worked at, I do not believe that testing is a waste of time nor do I believe that you can deliver 100% bug free code ever.    I recently saw this great post which got me thinking:  Top ten most infamous software bugs of all time.

• Yes, you can deliver software, even Enterpise software with no QA.  QA is all about risk management, helping you to better understand what you are about to ship, where the risk areas are and gives you a certain sense of comfort.  You can go without this if money is tight but there is major risk with this approach.
• Developers should just write code with 0 bugs.   This is ideal of course, and, perhaps even feasible when you look at the world in the micro level of individual functions.  Unit testing, of course, should help provide a solid level of comfort here but it is only a piece of the puzzle.  The bugs that will bite you hardest come from the interplay of functions, from incomplete understanding of requirements, from poor performance.  Individual developers focused on individual features will not catch these.
• Unit testing is the answer, get 100% code coverage and dump the QA team.  Same basic problems as noted above.  Good unit testing takes time and you are often spending higher $$s on the developer resources than on the QA resources to get the same level of coverage.  There is definitely an argument that automation is worthwhile, which I completely agree with.  However, it comes down to managing expenses and in most startup environments it’s cheaper and nearly as cost efficient to have a good QA team on board than to have your developers writing large amount of unit tests.

Thankfully, I have not had this discussion at my current company.  We have a good QA team and developers that are investing a proper amount of time on their unit testing.  We are also striving to live by my Engineering Tenants which keeps us focused on doing the right things.
Let me know what you think. Have you ever worked in an organization successfully delivering software that did not have a QA team?

-John

Mistakes made by US-based SAAS applications?

If you’re from outside of the United States, do you have stories of foolish mistakes that you have seen in US-based SAAS products? Share with the group or drop me an e-mail.  I’d like to see if we can get some of these out in the open and try to improve upon past mistakes.

-John

Running marathons hold the key to startup success

“We are different, in essence, from other men.  If you want to win something, run 100 meters.  If you want to experience something, run a marathon.” -Emil Zatopek

I’ve run a couple of marathons in my day and they have taught me a lot about myself and they have helped me understand how to weather the ups and downs of startup life.  Here are a couple of lessons that I wanted to share:

• Train the way you want to run the race.  I ran hundreds of miles training for those 26.2 that I would run on race day.  Uphills, speed workouts, and long runs.  To be successful in a startup you have to be comfortable wearing many hats.  Seek out opportunities to help out (not at the expense of your goals, however) and round out your out your career.  Time spent helping support, sales, marketing, finance, etc., will make you a stronger team player and better able to understand, and make, business decisions.
• Take days off.  While I worked hard I was never afraid to take time off to rest my body and my mind.  Marathon training, like the fast pace of startups, is exhausting mentally.  Take time to clear your head, focus on hobbies, just get away.  These breaks will help you be fresh when it’s needed.
• Don’t give up, push hard to the end.  In my last marathon I twisted my knee at mile 20 and could barely walk on it.  I had trained for a long time and was not going to give up even though I could barely walk.  Challenges arise, obstacles will be put up in front of you,  While my decision was foolish physically it taught me that I could deal with adversity and come through.  Challenge yourself, drive hard for the goal, and you will succeed.

If you haven’t run a marathon, or worked in a startup, consider taking a chance.  Both are great experiences and are great opportunities to learn more about yourself.

-John

My favorite search application

If you haven’t tried SearchMe (http://www.searchme.com/ ) you are missing out on a very cool search application.  Applications developers should check out the interface as we can all learn a few things:

• The iphone style interface where you can easily flip through search results is extremely easy to use.  Instead of scanning pages of text for results, as with google, you see the pages and can easily dig in when you see what you want.
• The ability to zoom into pages without fully launching the page makes the search process even easier.  With most search engines you are constantly drilling down, then back up, until you find what you want.  Searchme goes above and beyond in making it easy to avoid this behavior.
• The interface is actually fun to play with and you find yourself exploring and seeking to learn more about it as you’re searching for your results.

I won’t give away more secrets, explore and learn what’s out there.  The web keeps moving quickly, don’t let it get too far ahead of you.

-John

Keeping the polls open until Thursday

http://twtpoll.com/eccfw4

So far it looks like I will be writing about “Social media and how it relates to CRM systems”…    Unlike the Oscars there will be no awards presented to the leading article, but I’m sure there will be some degree of celebratory toast raised for the winner.  I have  a glass of wine waiting for the occasion.

-John

If a page on your site fails to work for a customer that never calls support did you really leave the customer with a bad experience?

While all of us know the answer is yes many SAAS companies fail to pay more than lip-service to this truth. One of the best things about SAAS is that the customer is not running your application on some remote desktop that you are likely never to see. If they encounter an error, especially a server side error, you should know about it.
Here are a few things that I recommend any SAAS application strongly consider to make you more aware of those errors happening in the field.

• Monitoring.  If you are running a SAAS and have no monitoring setup please power down your servers and walk away now.    Running hosted applications without monitoring is similar to sky diving without a parachute.  Sure, initially everything looks like it’s going well but then…..  Well, you get the picture.  While I could write volumes on this topic, and volumes have already been written, make sure you’re keeping an eye on the following items for Windows-based applications:
  • CPU Utilization.  If you’re CPUs are averaging above 80% you could be in trouble.  I’m happy if I see the machine CPUs averaging 50 – 60% as I know I’m getting traffic matching my current hardware.  On the other hand, if your CPUs are running below 10% you might have other problems.  You might either be wasting hardware (not enough traffic) or you may have serious scalability problems.  Take the typical scenario of a web server making request to a database server.  Imagine for a second that your database queries are encountering locking problems.  The CPUs on the database and web server will both look low and you may be pleased by how well your application is holding up (but should not be).  Remember, looking at only one metric alone can lead to false assumptions.
  • Free Storage.  Let’s assume that you’re following best practices and have a smallish C: drive for the operating system and other partitions setup for your application.  As a general rule I like to ensure the C drive is not more than 85% utilized and the other drives remain under 80% utilization.
  • Network transfer rates.  Pay attention here too.  It’s rare to see young startups running into bandwidth problems unless they are working with a lot of rich media.  However, make sure that the connections between machines, and to the outside world, are not being saturated.
  • Database locking, web server processing queues.  To my earlier example, issues in these areas can sometimes lead you to mistakenly believe that your application is performing well.  Keep a close eye
• Setup appropriate logging facilities.  Web server logs and SQL server logs are not sufficient in the long run but can be a reasonable starting point for a team on a budget.  Minimally, dump your logs to database tables and have nightly reports generated for typical errors. 
  • 404s.  Did you forget to post some files?  Track these down as they are embarrassing.
  • 500s.  Your server is getting hammered or throwing application errors.  Either way, get to the route cause by digging into application logs.  You do have those, right?
• Logging application errors.  Design your application to centralize error handling and write errors to a central location, preferably a database table that can be easily monitored and against which you can write reports.
• Client side error handling.  Those pesky JavaScript errors that your users encounter can also be tracked, although you have to be really good.  You are good, right?  Use JavaScript try/catch mechanisms and make sure you pass the errors back to the server for logging.
• Intrusion detection.  Once your site becomes popular you become a target. Setup intrusion detection systems to keep the bad guys out.

Remember, the point of all of this is to find and fix the problems with your site.  Unhappy customers will not be customers for long.  Let’s get out there.

-John