One day an innovator in the organization identifies a new business opportunity and approaches you with it.

Hey, there’s a new market we could capture. It’s big. We just need to take a little risk to get to it.

Senior Management may say “We’re not in the business of taking new risks. We’re in the business of selling what we have.” And we can’t blame senior management for this response. It’s political – and the stakes are huge. If a senior executive gets behind a new risky initiative and it fails, they are fired, or at least their career takes a big hit. Even if there were a large reward potential the risk may not be worth it to the executive.

What if we optimized this problem and reduce the risk by limiting the potential downsides?  Let’s start by identifying the major risks:

• Brand Risk.  What if you release your new product and it is a total failure?  Your company’s name will be forever tarnished, and sales of existing product will get hurt as a result.
• Financial Risk (both capital and opportunity costs).  To avoid Brand Risk we should put extra effort into making sure that the product is fully polished and ready for prime time.  We will need teams of people working for multiple months (or even years) on the product development.
• Personal/Political Risk.  If I’ve championed this project and it turns out to be a flop, I will suffer public embarrassment and will likely get fired/asked to resign.  Hmm, maybe instead I should play it safe and let someone else take that risk if they want to.

Tarnishing your brand, losing money, and getting fired.  Yep, those are giant risks.  What if I told you that you could reduce each of these risks to manageable amounts?  Within a small pocket of your company you can create a culture of innovation.  Within this pocket you must encourage experimentation and celebrate failure in the interest of learning.  Treat pocket of innovation like a small startup inside your larger organization.

We can solve this problem together.  To get started building our new innovation culture we must first accept the fact that we will NOT get the product right on the first try.  In fact, you have no idea how many iterations you need to make to get it right.

Failing often is OK as long as we limit the scope of our failures.  We are not talking about orders failing to emerge after a lengthy product development cycle and advertising campaign.  We’re talking about showing a customer a drawing of the product and hearing that it doesn’t quite do what they need.  By limiting the scope of our failures we can decrease the duration of these business model experiments and increase their frequency.  Under these conditions innovation is free to thrive.

How liberating!  The first try is not what matters – what matters is that you iterate over your business model until you get it right, ultimately achieving Product-Market Fit (hopefully before your competitors and definitely before you run out of money).   The other key is to limit spending until you’ve achieved product-market fit – for example, don’t spend money on advertising until you’re confident that the product is viable.

Once the organization accepts this idea it can start making rational choices to minimize the risk associated with the new business opportunity.  Let’s look at each of our major risks and see out how to minimize them given these new assumptions about our uncertainty in achieving product-market fit.

• Brand Risk is non-existent.  If you build a product that nobody wants (and you haven’t advertised it yet), then nobody even cares!  Just resist the urge to create ‘buzz’ around your product launch until you’re pretty sure you’ve gotten it right.  You can’t fail to meet expectations if you don’t create any.  To further protect the original brand, you could release your new product under a different brand, and only attach the parent brand when you’ve proven the success of the new product.
• Financial Risk – limit spending until achieving Product-Market Fit.  The solution to mitigating financial risk is the Minimum Viable Product.  The basic idea is to build only what is absolutely necessary in order to validate your assumptions about your business model.  If we disprove an assumption, we come up with new assumptions and modify the MVP accordingly in order to validate the new assumptions.  Then repeat.  Eric Ries calls this the Build-Measure-Learn cycle, and it is the basis for the Lean Startup movement (fig A)We spend as little money as possible on the MVP, and we don’t spend money on advertising activities until we’ve proven product-market fit.  Sometimes this means building a single landing page to see how many people click on the ‘sign up’ button.  Sometimes it means building a non-functioning prototype and taking it to a few customers to get their feedback.  Still, even if we’ve only got a couple of people working to iterate on the MVP, money is being spent, and it can be tough to quantify progress to senior management.  The bottom line is that it doesn’t take that many resources to prove whether or not a business idea is viable (and if the idea is not viable you should kill the project).
• Personal/Political Risk can minimized.  We’ve minimized brand risk and financial risk, so the political risk for the project champion is also minimized.  Under these conditions, senior management should be able to reassure the project champion that her career is safe even if this business experiment does not achieve Product-Market Fit.  This gives the project champion the confidence she needs to run without constantly having to watch her back.

The result is a framework for creating innovations in your company, ensuring that it will always be able to move with the market and capitalize on new opportunities.

This article was inspired by the works of Eric Ries’s book,  The Lean Startup and Steve Blank’s Customer Development Methodology.

First, a couple of definitions:

Unit Tests – Low level tests for application logic.  Inputs will be mocked or stubbed.  These do not make calls to services or external databases.  They must run quickly, easily, and frequently. Example: testing a method that calculates taxes based on a matrix of product types and zip codes.

Integration Tests – Application logic tests that may make calls to external services or databases.  These are slower and may run less frequently. Example: testing payment submission such that a payment gateway is called, a successful response is received, and that the response is logged to the database.

Functional Tests – Tests that run from a user perspective.  Usually this will mean invoking a user interface and testing that it reacts appropriately.  Example: testing that the user can login, place an order, and receive a confirmation email.  These tests are not the focus of this article

The Business Case: How Does Building Unit Tests Help Me Make Money?

Make no mistake: there are costs associated with building tests, and may require a large upfront investment before any benefit is realized.  In fact, to the non-technical manager, this combination of fuzzy benefits and clear costs may make testing seem like a poor investment.  That line of thinking is at best short-sighted, and at worst, blatantly negligent to your product’s future costs.

Testing helps your product development cycle move faster

This may be counter-intuitive. As it turns out,  a the whole team has much higher confidence that the new features have not broken existing features when those existing features are continuously and automatically tested.  The result is a QA cycle with less defects, which finishes faster and gets the product to market quicker.  The business gains more confidence in product quality during each product development cycle.  The tech team also gains confidence – unafraid to jump in and modify critical parts of the system to meet the latest business need.  The tests got yo back.

Tests provide historical proof about how the application is supposed to function

One client I had actually opposed maintaining a unit test suite for their enterprise system.  When it came time to make some minor enhancements to the billing system it turned into a big project.  The billing logic had become un-maintainable spaghetti from years of monkey patching by developers who had come and gone over the years.  In some cases the business people couldn’t even tell us how it was supposed to work.  We were literally afraid to modify it.  We limped through the project, but started planning a rewrite of the building system as a future project, involving not just the tech team but also business resources to properly document the functionality.

We test because we care about our customers and because we care about our software.

If you’ve read this far, check out my latest project: FindMyBeer , where you can find who sells or serves craft beer near you.

Today I was fighting with mapping a many-to-many relationship (a common occurrence in grails), and needed to figure out exactly why Grails and Hibernate were not doing what I expected.  One of the great things about Java is that nearly the whole stack is open source so you can just step through the code to see what is going on, as long as you can find the code (and navigate through injected dependencies, but that is a different story).

Eclipse Maven plugins provide great tools to ‘Download Sources’ start viewing them immediately when you step into some third party library code.  I am developing a Grails application on SpringSource Tool Suite (STS, v2.8.2 as of this writing), which is becoming the industry standard IDE for Spring and Grails based applications.  Since Grails uses a Maven-like dependency management system, you would expect STS to be able to download sources for for any of the grails dependencies easily, right?

Not quite.

While this is a feature that might work for Grails 2.0, if you’re using Grails 1.3.7 then you will find a plugin named eclipse-scripts that enables you to download sources and then configure your projects so that STS can find the sources.  Here’s what you do:

grails install-plugin eclipse-scripts
grails compile
grails download-sources-and-javadocs
grails sts-link-sources-and-javadocs

Then restart STS and refresh your project.  Now you can navigate into your project’s Grails Dependencies and view their source through STS!

I found the solution here: https://issuetracker.springsource.com/browse/STS-1440?focusedCommentId=36879&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36879

Credit for creating the eclipse-scripts plugin to Lari Hotari

Linky: http://genecalal.posterous.com/groovy-talk-thursday-july-21

The Scientific Method (sciencebuddies.org)

In this article I will explain a basic, but often overlooked foundation for improving the performance of any software application.

Much of software development is an art, but performance tuning is a science.  I’ve seen a lot of good developers waste time significant amounts of time on performance with little to show for it, or just as bad, improve performance without knowing exactly which change had the desired effect.

Do you remember talking about the Scientific Method from your high school science class?  The diagram on the right is a refresher.  The scientific method is the repeatable process on which all scientific exploration is based.  It gives scientists across the world a common language and framework to compare the process and outcomes of experiments.

The scientific process provides a few of important points that can be applied to software performance optimization:

1. Repeatable process – use the same process for every performance enhancement you make
2. Only modify one variable at a time – Do not make multiple tweaks at the same time.
3. Record the results of each optimization.  Track what you did and how much it helped.

Performance Optimization Method (clickonchris.com)

This sounds simple right?  It is.  The tough part for software developers is to never break these rules during a round of optimizations.  To the right I’ve also included a more detailed diagram of what the scientific process looks like when applied to performance optimization.  Let’s call it the Performance Optimization Method.

But I know what I’m doing!  Why shouldn’t I make multiple tweaks at once?

Lets say you do make two changes at once.  You optimize two queries and drop the page load time from 3s to .1s.  Do you know how much relative impact the changes had?  Did each change reduce the cost by the same amount (50%/50%)?  Did one query account for most of the cost (75%/25%)?  Or did one of the changes not even have any impact (100%/0%)?  What if the two changes were somehow interdependent?  For the most part these questions are impossible to answer unless you use a repeatable process and only modify one variable at a time.  There are exceptions *(there are always exceptions.  If you have a good profiling tool that tells you exactly what two different method calls cost and you are absolutely sure they are not somehow related then you could cut a corner and make multiple changes at once.  If the results do not turn out as expected you still need to go back and make the changes one at a time).  By the way, I hope you are testing against a volume of data you expect in production.

Don’t forget to record the result of each optimization.  This way you can throw your results into a table, and with a little explanation about the process and results you turn it into a report and send it to management so they can see how you’re spending their budget (and how good you are at science).  Having these sorts of metrics reports also makes it easy for stakeholders to justify the time spent on performance optimization activities.

The law of diminishing returns applies to performance enhancements.  At some point you will have picked all of the low-hanging fruit and enhancements start to get progressively more expensive.  Stakeholders need insight into how this is progressing on your project so they can make decisions on how much more to spend on performance.  Metrics reports should provide sufficient detail for stakeholders to make those decisions.

Ultimately you will end up with a faster application and a clear story of how you got there.  Isn’t science fun?

We ended up having a lot of success reducing the footprint through tuning.  Bottom line: we reduced the memory footprint by 120MB, and the startup time from 53s to 24s

Here were the steps taken

The instructions for each step can be found : http://community.jboss.org/wiki/JBoss5xTuningSlimming

Notes on my environment and testing process:

• Windows XP, JDK 1.6.0_22,
• JBoss 5.1.0.GA.  Xmx=512M , Xmx=256 (this is why heap didn’t drop below 256)
• I used jvisualvm to watch the heap and “used” memory values
• For the “Used” memory, I took the maximum observed value while JBoss was starting.  If you understand that a time vs. memory usage graph follows a sawtooth pattern as objects are instantiated and garbage collected, then I took the value from the tip of the highest tooth.

With this in mind, I simplified my blog UI today, switching to this theme from iNove (http://wordpress.org/extend/themes/inove).  Its not a big change, but its an improvement.

-Java 7 is underwhelming, mostly because it will not have closures. It will however introduce enhancements to speed up Groovy, JRuby, and Scala

-If I read between the lines what features are in HTML and any of them are supported by Chrome, then I think that HTML5+Chrome could easily turn into a gaming platform!

-There is no question that Groovy is the “next big thing” for Java. Get on board.

-A java developer could easily add Hadoop to his resume (and dollars to his pocket), by learning Hadoop with Cascading. Hadoop-worthy scale data sets are available for free from amazon: http://aws.amazon.com/publicdatasets/

Grails is really cool. I wish there was a hosting platform available that was anything close to Heroku for Rails. I think it is unlikely that we will hear any good Startup stories with Grails for that reason.

I published my first ever screen cast tonight. enjoy!

The source code is available here: https://github.com/clickonchris/facebooker-demo

===========================================================

I have been working on a Facebook application in my spare time for quite a while now and I think that it is finally interesting enough to start telling people about.

The application is a game called Sprite Club; it is a place where you can judge kids (sprites) on the basis of cuteness, and upload a photo of your own sprite to have them compete for internet fame.  The application is accessible from

apps.facebook.com/spriteclub

or from the friendly url:
www.spriteclub.net

The idea was conceived by my uncle, Matthew Deutch, while looking for an outlet to prove that his daughter is the cutest kid on the internet (We think she’s pretty great).  I am in the project to learn how to do Facebook and social media development.  The application is written in Rails and uses the Facebooker library to interface with Facebook.

Enjoy!