We now favor flexibility over high fidelity, convenience over features, quick and dirty over slow and polished. Having it here and now is more important than having it perfect.
The good news in this is that this trend is ideally suited to our times. During the worst recession in 75 years, it's the light and simple products that are needed. And I believe, that this trend also applies to the software industry. Designing a solutions, building a product, doing a project: There is the need for the solutions that easily fits 80% of the customers needs.
If that 80 percent number rings a bell, it's because of the famous Pareto principle, also known as the 80/20 rule. And it happens to be a recurring theme in Good Enough solutions. It could be expected, that you can reach a 80% solutions with less than 20% of the money. The remaining 20% of the features are the ones that hurt and boost the costs. But where to draw the line? Which are the 20% of features to skip? This part is not too easy to answer. Answering the following questions should guide you.
What's available?
There are many examples out there, where lean startups and small-scale enterprises offer solutions that best fit the needs for less money. This could mean, your are not using any closed source products but open source alternatives. Another interpretation could be, you are using pre build component sets and skipping the expensive self made development. Look at the available solutions. Take some time to investigate the features and select the solutions which already adresses most of your needs.
What's inimitable?
There are obvious examples, like (not realy) differing processes (HR,FI). If you are thinking about buying a solution and "customizing" it to your needs, focus on things that are true differentiators. In most of the cases, you will realize, that there are'nt too many parts which make your process inimitable.
Another good example is the UI and it's flow. There are prebuild solutions out there for user interactions, which are broadly accepted. Look at yahoo and their UI components, the JBoss Richfaces and many other examples. If there is a skinning mechanisms available and you plan to run more than two projects on the same component set: use it! If not. Forget about it. If the datagrid allows for paging, be happy. If you need additional information (number of results, aggregate of pages or other, possibly nasty things) that are not available through simple customizing: Forget about it.
What's thwarting me?
Already found your 80% solution? But still having difficulties? It is'nt the right technology? right? :) Some PHP or Ruby stuff? But your company/customer is using Enterprise Java? Perfect. Sounds like you are getting trouble with the technology department. You could possibly look out for some kind of technolgy adapter like Quercus (running PHP in JEE) or Glassfish running JRuby for example. Anyhow, it's important not to break the rules but to bend them to fit your needs. If you sill cannot get to any solution: Remember, that there is still a suitable exit. Do some analysis on the business case and convince them. If they don't want your cheeper solution, that they should pay the bills. If this does not work, you still have a perfect basis for further budget discussions.
What is the issue?
Using Enterprise Java since more than eight years makes me belive that there is an advantage in standardization and guidelines within companys. Programming easy to maintain and well documented projects still has a right to exist. And designing such solutions will still be more expensive that just buying or downloading any simple PHP or other script based solution developed by some people in the backyard. But after all this mainly applies to about 10 to 15% of all the applications in a company. If your project does not fit into this 10 to 15% of applications, you are free to choose any language, framework, technolgy you like. If not: Forget about the simple "Good Enough" approaches and look for smaller parts in your scope to apply the principles. For example you can still use existing libraries but build the basic application yourself instead of using an existing open source project.
As a conculusion, you should keep in mind to regulary see beyond your own nose. Don't just stick to things as they have ever been. Always ask yourself the questions about the 80% solution. About truely inimitable parts and the value of a "here and now" solution.
