Innovation

I heard some good talks on innovation a few months ago at a user conference for iRise software.  One of the topics was how to create an innovation pipeline for your business using social networking concepts.  A few companies have already started doing these types of things to great success.

For instance, Dell has its new IdeaStorm web site.  They use a unique form of crowdsourcing to introduce product innovation to the company.  Users go to the web site, submit new product ideas.  Ideas can be modified, voted on, discussed, etc.  The main idea of the site is to use the user to initiate innovation within their line of products.  An interesting idea since the consumers are really the product experts.  Especially power users, those who are the most passionate about the products, have a lot of untapped insight.

Tying this all into a software model, programmers, business analysts and architects have been trying for years to bridge the gap between the user and the end product.  Things like forums and message boards are often catalysts for enhancement requests and bug fixes.  But, some companies are taking this to the next level by only including feature requests which are the most popular.  Using a voting system, Atlassian determines the most popular product enhancement requests.  This list determines the features to be added in the next version of the software (along with other factors).  It is a pseudo-open-source model.  They obviously continue internal innovation but user input seems to be the main factor.

Considering this Atlassian model works well for commercial software (although I could argue they may be too transparent about their future plans which puts them in a competitive disadvantage), I was considering how this could work for internally developed enterprise software.  I could see this really working.  Sit down with a seasoned customer service rep (power user) and you find out quickly where the limitations of your software lie.  If they only had a formal model or process where their feedback is adequately captured and fed into the enhancement pipeline.  Not overwhelming bureaucracy, just a direct line of communication between the grunts (users) and the grunts (programmers).  Like the red Batphone Commissioner Gordon had in his office.

Java

I took a Java development class years ago (back in 1999, I think). I learned a lot. I even used Java to build a server-side utility. It was quite simple, but it did have database connectivity, etc. It was nice to try it out and practice what I learned. Since then, I have been exposed to Java and its stack of technologies, but nothing hands-on.

About a month ago that all changed. My team is now deploying two Java-based 3rd-party products. The first is going through the pains of load testing, QA and production deployment. Not just little pains, but serious kidney-stone-type pains. I have learned a lot about Java during this time. I can’t help but compare it with what I know about .NET and my experience with Microsoft technologies. Here are my observations.

Application Server Confusion

This is the big one. Java has no single technology stack. You have to choose one. We have a new stack just rolled out. Our team is going through the pains of working with systems analysts and engineers who are just learning how to use the new stack. Whether it is JBOSS, Sun’s app server, weblogic, Websphere, or whatever; you have to learn and ramp-up on that app server’s quirks, expectations, deployment methodology, configuration management process, etc. Although some things are uniform across these stacks, a lot is not. “You have to unlearn what you have learned”.

.NET has one app server. One configuration management story. One runtime. I agree, there is lack of choice (i.e.: no choice), but therein lies simplicity, and therefore power and freedom. (I know, I know, you can run .NET on Linux with Mono, but seriously, who really does that? Is that really an alternative to Windows and IIS?) If I want to run a .NET web app, I just need to know Windows Server and IIS, nothing more. I don’t need to buy anything. I just buy a commodity Windows server and I am ready to roll.

Deployment

Deployment is not easy in the Java world. Maybe I am just a newbie, so it all seems complex, but man, working with wars, jars, deployment descriptors, config files, etc, can be a mess (this sentence has WAY too many commas). Especially considering migration from one environment to another, these obstacles can get even larger. Let’s say you move from your development environment to QA, you have to build a new war file with different deployment descriptors, set up your app server, data sources, etc, and deploy the application. It sounds easy when someone says, “To deploy an application, all I have to do is just drop a war file on the app server”. That is a lot more complicated than it sounds.

.NET eeks-out a win on this one, but not by much. It can be as easy as running an MSI file, but it can get as difficult as managing a mess of dlls, DSNs, config files and custom IIS settings. But, if done right, deployment can be quite simple in the .NET world. A lot of the ease, I think, comes from the unified/standard configuration system.

Operations Ramp-Up

If you look at the difference between the time it takes to learn how to use Linux/Unix/Solaris from an operations perspective versus Windows, you have to admit, there is a vast difference. This is more of an OS-specific thing, but it has tremendous bearing on the ability of operations staff to deploy, change and manage an application.

Windows server admins may be a dime-a-dozen, but that is because it is so much easier to learn. This means cheaper resource costs and quick ramp-up time and quicker time-to-market.

I am sure there are others. Maybe I will continue this later. Maybe not. Maybe I am just a Java bigot. Maybe not.

With Every Project, Churn… Churn… Churn…

It seems that every time I want to get a project done quickly and painlessly, I am cursed with a long drawn-out, painful project instead.  I must be doing something wrong in life to deserve this kind of torture.  Application development should not be this hard.

Process is all part of the game in software development.  I understand the value in process, approvals, checkpoints, documentation, etc.  But WOW, sometimes it feels like trying to get your license renewed at the DMV…  Wading through paperwork, “alignment”, approvals, reviews, etc can be very time consuming and painful.

I am convinced those who succeed at wading through process to get projects finished quickly are those with a very large network of buddies and insiders.  Insiders are people who either own or control parts of the governance process.  They are the people who know how to grease the wheels to get things done.  They are the ones with real control.  If you don’t know those types of people, you are one of the many who just wait in line, praying for the process to work as designed and advertised.

Also, these successful project managers know the process.  They understand each point along the way.  They have intimate knowledge about how each piece of the puzzle fits together.  They have the domain knowledge necessary to plan for each facet of the project’s lifecycle.  If a certain review is required, they know when, who, how to get it done.  They know prerequisites, impacts, key players, etc.  This knowledge is never obtainable over night.

No wonder so many projects fail to meet their original goals.  Consider coming on as a new project manager with no prior knowledge of a company’s proprietary process.  How can you expect to succeed on the first or second try.  It is near impossible.  You will have so many “gotcha” moments where you find out parts of the process you are missing because they are not documented or communicated properly.

Process is a necessary evil, but we (the software development community) have to find a way to simplify to the point where process is not a roadblock to project success.  We have to find a way to fade process into the woodwork of the project pipeline.  Make it transparent enough to know its there, but you don’t really notice it affecting or guiding your project.  It just does its job without meddling.

Software and the Great Gazoo Effect

Did you ever watch The Flintstones? What a great cartoon. I watched it all the time as a kid. The show really started off great. After a few seasons, though, things started slowly growing… It starts being a funny cartoon sitcom, nothing like any other show at the time. New characters emerged like Pebbles and Bam-Bam which were cute and added value to the show. Then, over time, unreal stories, more and more new characters and outlandish plots marred the show. The show just bloated itself into the sitcom graveyard.

The quintessential example of this bloat that killed The Flintstones is “The Great Gazoo“. An alien from a futuristic world coming to prehistoric Bedrock, acting as a kind of evil influence on Fred and Barney. He gets them in all kinds of trouble as he seeks to build a dooms-day machine… What a load of crap. What a waste of a good show. Soon after the appearance of Mr. Gazoo, the show is canceled.

So many pieces of good commercial software have also suffered the Great Gazoo Effect. Tumbling into bloated heaps of features, unrecognizable from their former selves.

Jeff Atwood also provides great commentary on the subject.

I agree, over time, software can get bloated and overloaded with “features”. I definitely have seen it happen but mostly on the commercial product side of our industry. It seems the user’s cry for more features and the need to constantly crank-out more revenue from new versions compromises the product at some point, leaving it crippled.

I think a great example of this phenomenon is MS Office. Look at how it has grown over the years. Feature after feature until the UI was completely overhauled due to the abundance of features. Even with ribbon, some features are buried under a heap of their brothers and sisters, completely lost in obscurity.

Software can never be everything to everybody. Each application must have its sweet spot. The closer it sticks to that sweet spot, the longer its life. But, sometimes the spot sours and is no longer sweet. This is a critical point where the Great Gazoo can appear over an architect’s shoulder, whispering and plotting a new dooms-day machine. Let’s all find a way to tell him to get lost. We will explore ideas on how this can be done.