The next generation of software will be built by companies with vision, the ability to execute, and a vibrant, engaged, and active customer community that will drive product innovation.

The idea is pretty obvious and the execution is pretty radical.

Today software companies use a prescriptive approach to software design - the software defines how people should work (”A better way to do things!”) - and use forums, salespeople, and conferences to create a passive feedback loop with their users.

This leads to innovation being led by a small number of marketers and engineers who want to develop software to make money.

The future of software will move the company from the center of the innovation process to the periphery, replaced by the people who use the software who will drive innovation by engaging in discussions about best practices, success stories, shared metrics, and ideas for radical improvements.

This leads to innovation being led by a large number of subject matter experts who want to use software to achieve business objectives.

Which makes a lot more sense.

Success will be determined by the strength of the community, the quality of the ideas that come from the community, and the ability of the company to execute them - which is radically different than the current model with success being defined by winners of “feature wars”.

At Mercury Grove, we believe that the foundation of community-driven software requires three ingredients:

1. Professional, passionate people with the proven ability to execute.
2. Effective, transparent processes that actively and aggressively engage people.
3. Passionate people who want to be involved in the process of achieving more with software

This is the future of software.

Our first focus was building contact management for CRM. We had the major functionality already in our Groups application. We ported that over from groups (which is in CakePHP), taking advantage of single table inheritance in rails (which CakePHP doesn’t support). This allowed for less code for contacts in Rails than we had before and made pagination much easier.

We are using Behavior to keep as much javascript out of the views as possible (lessons learned from previous apps).

For example, in the screenshot below we are using default labels “Address”, “City”, “State”, “Zip” to provide a hint to the user. If they start typing in the field the label goes away. If they leave the field but don’t enter anything the label comes back. Easy effect, but requires a bit of javascript. Using Behavior, all the code is outside of the page. The form in this case is very clean.. just the input fields. And if you want to add a new address, an ajax call places a new address form below this one, the rules are reapplied and you will see default labels there as well.

We are building the new apps in Ruby on Rails.

The decision came down to how we were going to manage templates for extranets and how we were going to manage credit card processing across the new apps.

Thanks to our friends at Shopify (http://shopify.com) for releasing Liquid (http://liquidmarkup.org) and ActiveMerchant (http://activemerchant.org), Rails was the clear winner.

Mercury Grove uses an agile programming model called “Evolutionary Prototyping” to develop its software.

Evolutionary Prototyping uses multiple iterations of requirements gathering (captured in our AppManager) and prototype development. After each iteration, the resulting product is reviewed with the “customer”.

Our particular flavor of Evolutionary Prototyping involves scouring the Open Source community for a pre-existing app to serve as the initial prototype. If we cannot find the right “fit” for the project requirements, we start with a static prototype, using either simple wireframes or basic HTML. When developing our own products, we tend to skip the scan of the OS community altogether so that we don’t have to worry about dealing with licensing issues later on.

It’s a refreshing departure from the lumbering, and often ineffective, waterfall models mandated by the PMOs of many large corporations. Don’t get me wrong… traditional waterfall models that employ rigorous requirements gathering sessions, reams of documentation, and never-ending loops of approval have their place in the world Enterprise applications…but I no longer work in this world.

The model works particularly well for us - both internally for our own product development and also in our consulting engagements. It allows us (and our clients) to see steady progress. Instead of boiling an ocean of requirements, we start with the prototype that meets the base-level of requirements and chip away at the problem - always talking to the prototype instead of abstracting orally dictated requirements through documentation.

It’s a great fit in today’s outsourced, off-shore model, too. When we are able to start with a pre-existing code-base, it makes it much easier to communicate requirements/enhancements to the developers in small chunks.

Let’s face it. Requirements change rapidly. Using this approach allows us to be nimble without being irresponsible.

Sorry team for being late out of the starting gate. Like all projects I have been trying to figure out the best approach to bring my own special flavor to the project. I have decided that I am going to offer a video post for the blog, I am going to attempt to make a 2 min video blog post each week recapping the trials and tribulations of the design process, the interactions of the team members and hope to offer a sneak peak to the readers (viewers) of the up coming thoughts on design. Have a look and let me know your thought. I will try to keep it interesting.

A.

I’m currently reviewing frameworks for the new apps we are developing.

My friends in the enterprise tell me I should use Struts or .Net, but that is just a long way to go for a drink of water. From what I’ve seen, Struts and .Net projects tend to develop the marketing skills of IT project managers, who need to sell why its taking so long and why it costs so much money.

But the simple fact is that Struts and .Net have the framework market share in the enterprise. But why?

If you go to India, you will find a strong belief among developers that those two frameworks are the only things worth knowing. But we are to blame. They just listen and respond to what the “customer asks for”.

When you go into a conference room in India you will have the choice of exotic tea, coffee or Diet Coke. Why Diet Coke? Because that is what they hear we want.

I can see it going down something like this … “Would you like something to drink?”. “Sure, do you have Diet Coke?”. Because really, what else are we going to ask for in a country like India? We are going to ask for what we know, what we feel safe with. Even when something more interesting and compelling is on the table.

Not for me.

The new apps will not be on Struts or .Net.

Having just wrapped up my involvement in a Fortune 500 CMS project, I’m convinced that big apps are on their way out.

If you work in IT for a Fortune 500 company and work on a big app, ask yourself these questions:

1. Have you meet with the big app pre-sales, regional sales and professional services teams, and did they recommended you upgrade, purchase additional software and buy more consulting hours?
2. Did the big app sales team keep telling you about their other applications and recent acquisitions?
3. Did you use an excel spreadsheet or calculator to work out how many processor licenses you needed and how much it would cost?
4. Did you find yourself asking the vendor what they considered a processor? Was a dual processor the same as 2 processors? What about a quad processor? At $20-35k per processor, semantics matter.
5. Did you find yourself asking the vendor if you needed to purchase licenses for development and staging?
6. Were you inundated with questions from your hosting and support providers? Questions like…What hardware should they buy? Do they already support all the components? Do they need training? When do they need to buy the boxes? Who needs access? What type of architecture is it? What should they do with the existing architecture? Does it cost more to support? Does it scale?
7. Did you either a) negotiate vendor training for the development team and business areas OR b) build a powerpoint presentation explaining why you didn’t
8. Did you gather global requirements for the app? If so, did you hear - “We already have a system in country xzy that does this and works.”
9. Did you migrate country xyz’s app into the “global solution”, and catch hell from them because the “global solution” does less and costs more?
10. Have you become one with Powerpoint

If you answered yes to most of them (and you probably did), its important to realize how we got here.

The big app model persists today because it looks good on paper. In this IT model, you only need a few apps to run the business. You can standardize the technology and move support to low cost countries. Business areas are on board because they hear it will cost them less and they will get better support.

But the big app model is not working. It is taking too long, costing too much, and big app vendors are not innovating. Have you seen a big app that doesn’t look old?

Its time for a change.

So what can you do as an IT manager?

1. Stop feeding the big app. Move to a “just keep the lights on” support model. Stop paying the big app vendor a percentage of the overall sales price for support per year. Stop enhancements. Stop all non-critical bug fixes. Stop 24-7 support. If you are concerned about your customers being upset, chances are they are already upset. So start rolling out better solutions in less time (next step)
2. Invest the money instead in hosted solutions that can be rolled out in under 30 days. Hosted solutions don’t require you to expand your internal infrastructure, they typically offer APIs so you can move data around internally when needed, and they are innovating.
3. Build a small internal team to support these “new” apps. Make sure they are on the business side of IT, and have them gather enhancement requests from your customers. Forward enhancement requests to the hosted solution provider and share any roadmaps with your customers.

It is time to get stuff done.

Leave big apps behind.