Why A Startup Fails

As a follower of www.CodeProject.com and their newsletter they often share very interesting articles and blog entries along with technology news.  The other day they shared an interesting story: https://oncletom.io/2014/why-our-startup-failed/  Its an eye opening look at why a start up failed with insight tips and an emotionally compelling story especially for those who in a start up or working towards building a start up.

Here are a few tips from the article that hit home for me:

Trust Your Gut - in short, don't let someone else sell you something or lead you to believe an idea is just too good to fail

Each hire should be tight to objectives, costs and metrics.

• Is the hire generating revenues, is it creating product value or is it sustaining the organizational growth?

(This advice could be applied to any endeavor.)

Are you have any financial involvement insist on 100% open accountancy.  If someone does not know where every dime went or tells you not to worry about it - these should be a big red flag.

Don't take for granted that interest in your product is going to equal sales or contracts.  Until money is in your hand, you don't have a sale.

Big Customers = Lots of Time.  The larger the company is odds are the more time it is going to take them to buy into your product or service let alone move the purchasing outcome through their internal channels. 

Companies want to know you are going to be around for a few years. We you don't have years of operating under your belt it's hard to guarantee you are going to be around to support your product or service for years to come. 

Investors don't want to invest if you "need" their money.  Investors are going to be most comfortable investing when you can show their money is not needed in order for you to operate or develop the product correctly or perform some sort of core business function.  Investors in a start up want to see what return they could gain from their investment.  If they see you are going to carry on, continue to develop, grow and generate sales without their money, that is when they want to invest.  Because their investment dollars could help you do all those things more quickly, generate more money and create a return on investment. 

If your sales pitch to a potential investor is, "We have a lot of interest and a great idea, we just need your money to hire people to build it and ship it." - odds are you are not going to generate investment.  Because at that point you are asking an investor to become a business partner and essentially help run/start the company.

EZ-Face

My EZ-Face multiple face recognition application, which helps make face recognition, true face recognition for robots easy I'm pleased to say keeps growing in popularity.  It was recently entered in the Instructables.com Robot Contest http://www.instructables.com/id/EZ-Face-multiple-face-recognition-made-easy/

I'm very pleased that my project which was first released on 3.2.14 has been so well received and folks are putting it to use in their robots.  I'm looking forward to sharing more code projects in the future.

You can download EZ-Face and my future software offerings from J2R Scientific at: http://www.j2rscientific.com/software

Remember - the source code is included!  :-)

Neato Burrito - Cool stuff on the net

Neato Burrito - Cool stuff on the net

This is what I'm going to call cool and interesting finds on the net - Neato Burrito.  What do you think? 

First up is the DARPA Open Source Catalog: http://www.theverge.com/2014/2/4/5377492/darpa-publishes-all-its-open-source-code-in-one-place-open-catalog DARPA the Defense Advances Research Project Agency for the United States Military has often had many of its projects in an open source domain.  After all, these are tax payer funded efforts and if they are not deemed a national security risk to share, then they should be open.  But to obtain the information you had to track it down yourself and usually ask for the information.  I've done that myself when I requested documentation on the "Manny" humanoid robot from the 1980's and had to place a phone call to a military base and to my surprise I was promptly sent a large envelope with all sorts of neat info on the robot. 

In an effort to modern the openness of some of their projects DARPA very smartly started their Open Catalog: http://www.darpa.mil/OpenCatalog/index.html  Check it our for yourself.

Next is this awesome 42 minute presentation on robotics http://www.youtube.com/watch?v=JcyKOSECgtk On the Applications of Python in Robotics - by, Lentin Joseph.  It gives and overview of how Python can be used on a Raspberry Pi computer for color tracking and send control signals to an arduino microcontroller for motor control signals to steer a robot. 

The Truth About Agile

The Truth About Agile: http://www.telerik.com/agile-project-management-tools/blogs/13-10-23/the-truth-about-agile-top-30-agile-myths--busted.aspx

One of the better write ups on Agile I have read in a while.  "As described in the myth “Agile Projects don’t provide Budget Estimates”, agile teams fix the cost, fix the date, and vary the scope. The onus is on the Product Owner to make sure the requirements are not only prioritized correct, but ordered correctly. "

So very true!  Which brings up an important aspect of Agile I don't see many publication how, "How to be a good Product Owner".  If you have a customer, project manager, or product owner - whom ever is setting the priorities - if they are not effective, at that the end product is still going to suffer. 

For robotics and robot builders this is important to keep in mind.  Set your goals and prioritize!

Agile - For Robotics

Agile can be defined as - "Characterized by quickness, lightness, and ease of movement; nimble."

Agile in the business world, specifically software development is a group of development methods based on incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

When put into action successfully it makes for a quick and lean development cycle where software developers are always releasing updates or features to their software. 

Think of it this way as it relates to robotics; imagine you are building a robot that has human like abilities in both form and thought.  It's going to take a lot of work and a lot of time to perfect this robot.  One method to build a robot like this would be to hide away in a dark lab like Dr. Frankenstein slowly going mad while perfecting your creation. 

  OR...

You could apply Agile methods and practices to the design of your robot and release and add features incrementally.  What I'm talking about is applying Agile for the solo developer, in the case a robotics developer who works on both hardware and software.  Agile is designed for teams of software developers, so some overall modification to the methods must be made.  There are many examples of solo agile developers if you seek them out in an Internet search so what I'm describing is nothing new, although it may be new to the world of robotics.

Agile the J2R way

The main objective is to Deliver Value Incrementally.
This is done with three steps:

•     Daily Standup (a review)
•     A defined set of Goals/Vision (with priority levels)
•     Build/Release (carry over)

We'll start with your goals and vision.  You must start by setting a set of clear of objects you have to complete with your robot hardware and software.  For example, I wanted to build a new robot recently to test software ideas for the EZ-B board from EZ-Robot. 

My hardware goals were this:  Build a light weight mobile robot with 2 drive servo motors, a servo controlled gripper, an interactive head, sonar sensor, wireless camera, touch/pressure sensor, voltage monitor for battery level indication and EZ-B wireless controller. 

My software goals were this: Use EZ-Builder software to create a robust set of manual controls to test the robot and it's hardware.  Create controls to allow for voice commands.  Create controls and scripts to allow the robot to autonomously explore about an environment.  Test the ability of the robot to find a target with the camera and attempt to grab the object with its gripper.  Specifically test touch sensor and voltage level sensor integration.  Test and export of values from the EZ-Builder to external software.  Test the import of values to the EZ-Builder software from external software. 

With my goals defined I could set a build/release schedule.  Agile software development is usually a 2 week cycle. For the robot build or solo inventor I think the cycle is important to set and keep but not the specific amount of time in the cycle.  For example if you work a 8-5 job like I do then you are going to have a limited amount of time to dedicate to your project.  What works for me is a week long cycle. 

Now that you have your goals and cycle you need to break down your goals to fit in the cycles.  For example week 1 might be hardware fabrication.  Week 2 might be setting up the software for testing of hardware under manual controls.  Week 3 autonomous navigation.  And so on...  The idea is to have a pre-planned set of objectives to complete in every cycle that account for all of your goals.

Another part of the cycle management is the priority of the tasks.  For example if in week 1 you fail to complete the hardware fabrication, your other tasks may fail.  So that task may need to "carry over" into week 2 or 3 until it is complete.  A goal such as "Test a pressure sensor" if it were missed in its weeks cycle it may be something that can wait and be put into a "back log" of tasks or project goals that were not started or completed.

So within the cycle management we have "carry over" and "back log".  This is a way to mark your project tasks.  Do they get put on the back burner in a back log pile?  Or were they started and not completed or are they critical, if so they might need to carry over to the next cycle. 

Last but not least is the Daily Standup.  This is designed to be a review point for the project.  In Agile software development this is done daily and meeting boils down to 3 questions for each team member:

What did you do yesterday?

What will you do today?

Are there any problems that are getting in your way?

For robotics, this is fantastic to do if you are working with a team.  If you are a solo developer I still recommend implementing a review process where you answer those 3 questions.  I currently implement this on a weekly bases.  Agile software development would call this a cycle or iteration review between cycles.  I find it helpful to review what I did, what I want to do and what problems I encountered. 

Now, all this Agile stuff might sound like things you naturally do anyway at least some of the time.  But if you apply Agile to your robotics development I think you'll find you accomplish more than the traditional method of:  Build a robot, play with it for a while, get frustrated with some aspect.....leave it on desk.....move it to a closet.....see something cool on the internet that makes you want to play with your robot again, dig out the robot, dig out your parts and tools....work like a crazy person on your robot for a couple of sleepless nights.  - Repeat the cycle.

NEW J2R Website!!

Ewww, Ahhhh....that new website smell.  I moved the J2RScientific.com website to a more professional hosting service, namely Yahoo!  Yahoo really does offer some neat features for small business like mine.  The old website was hosted on Tripod, AKA Lycos, that service in my opinion has gone down hill like a bad neighborhood in Detroit.  I really was getting the impression no was steering the ship there at Lycos.  

Check out my new site at J2RScientific.com

The Idea Box = FDD (Feature Driven Development)

If you are like me, you are always thinking of new ideas.  Perhaps, like me, many of your ideas are not that great.  If you also have a habit of jumping from one idea to the next without finishing many of your projects then you and I have a lot in common!

Coming up with new ideas is great!  But chasing your tail trying to switch gears in the middle of a project leads to what I call "Grass is Greener-itis".  For me, each new idea sparks new energy and new potential.  Every new idea has the potential to be the next "big thing".  If I don't work on this new idea I might miss out on the best opportunity ever!!

I've found if I don't govern the tendencies to jump ship for each new idea I never complete anything.  If I never complete anything, I never truly learn anything.  Without learning I can't properly implement new ideas.  And so on, and so on....

To help cure my "Grass is Greener-itis" I have started using an idea box.  The concept is very simple, I use a $1 plastic pencil box and not down my ideas on note cards and place them in the box.  This does two important things for me.  It lets me write down my idea so I don't have to keep it in my head.  It also give me time to further ponder the idea over time.  I treat my idea box like my own personal suggestion box.  Much like you might find a suggestion box at a restaurant.

I note my ideas on 2.5" by 3" card stock.  The small size helps keep my ideas brief, which I find also helps me.  It keeps me writing out complex ideas for example: "build a terminator, teach it track people, give it gun, take over the world".  That complex idea would break down into 4 ideas with 4 cards.  On my idea cards, I try to draw pictures, add concept ideas in bullet points and I always note the date!  The date lets you track your ideas over time.  In this example, you could track the ideas over time. 

Here is a picture of my idea box.  I made a divider out of paper because my idea box is used for ideas and small sketches. 

The idea box plays into my personal implementation of AGILE.  Part of AGILE is to focus on feature driven development or FDD.  The ideas in my idea box represent features in my overall robotics and creative endeavors.  I weed through these ideas through a review process.  On a regular bases I sort through my ideas and arrange them in relevance to things I want to work on or things that might add value to my work. 

I never throw out the ideas; bad ideas simple are moved to the bottom of the pile.  In my example above, "take over the world" would be moved to the bottom.  "Teach it to track people", now that might be moved to the top as I would actually like my robots to do that.  When I am ready to work on an idea or two, I take them out of the box and tack them to a cork board.  From there I can further review the ideas, work on them or reject them.  Completed ideas, I mark them complete and save them in a complete box. 

If you are serial inventor, tinkerer, always thinking of new ideas, or just have some big projects like a house renovation I encourage you to create your own idea box.  You'll find it, a good idea.  :-)