Many software developers are overly sensitive to performance and spend a lot of time and effort considering the performance of their code design. While I understand their concerns and that they don't want to be negligent, their efforts are generally inefficient and sometimes misguided.

Performance bottlenecks are commonly not where you would have expected them to be. A lot of upfront effort can be wasted on poor assumptions and planning.

Many respond to this argument by doing even more preemptive optimization design and planning, so as to correctly identify the bottleneck. This is rarely as efficient as simply implementing the original feature, profiling it, and then tune or address the actual bottlenecks.

There are certain contexts where some preemptive optimization is appropriate, such as network drivers or low-level protocol implementations. But in the majority of cases, there is no need. Overall, the balance of concern is wrong, in my opinion. Some advance thought for performance, so long as it doesn't disrupt your progress, probably won't impact productivity much.

Unfortunately, I've been in many conversations where someone played the "performance card" and derailed any discussion or progress while that tangent had to be addressed. This is an example of a larger, more troubling problem in software development.

There are many areas of presumed conventional wisdom than few are willing to challenge. This combined with the typical myopia most developers experience, whereas they see the problem they want to solve as opposed to the one that is there, is one of the main risks to success for software projects. Also, if the conventional wisdom and status quo was so correct in software, why are there so many failed projects, blown schedules and budgets, and quality and sustainability problems in the software industry?

People need professional development, whether conscious of this or not. It is my opinion that one of the most common reasons people change jobs is the lack of professional development.

Boredom and the lack of a challenge are common reasons people cite when leaving a job. This is a cry for professional development; their new job provides a new context with new challenges,which stimulate the individual, encouraging new perspectives and the assimilation of new information.

It is preferable for everyone that the employee does not have to take such drastic measures as changing jobs to satisfy the need for professional development. Unfortunately many companies, particularly startups, do not have any program for professional development, even if only an informal one. There is too much to do and never enough time; how can you expect a fledgling company to spend scarce resources on developing employees? Most would rather hire individuals with the skill set required for the job and not be responsible for their development.

Herein lies a common mistake; many employers confuse developing employees with hiring for established skills. They are independent as current skills addresses short term needs whereas professional development addresses long term concerns of retention, satisfaction and future skill requirements.

Considering the cost and time required for recruitment and training, it is foolish for an organization to dismiss professional development, regardless of the "good reasons". Like character in individuals, it is telling if an organization will respond to its challenges rather than succumb to excuses. An organization's commitment or negligence regarding professional development reveals much about its values. For many employees, this will be a greater cause to change jobs.

Chris Risley, of Bessemer Venture Partners (bvp.com), first introduced me to the idea of high concept. It is a term borrowed from the film and television industry that summarizes a proposed idea and usually leads a pitch. It is intended to evoke immediate interest and possibly understanding of the idea. For example, YouTube could have been described as "user posted video on the web".

All too often, an entrepreneur over complicates the communication of her endeavor. Besides her passion, she has been spending an enormous amount of time contemplating, refining and planning her new business. So, she rushes to explain all the richness and subtleties of the idea and how its innovation will change the market. She may even assume that you can't fully appreciate the value of the idea without being told all its nuance.

It is true that complete understanding will take some time and exploration. But this isn't a prerequisite of interest and when pitching the idea to a VC, friend and the target market, capturing interest quickly is critical. The audience's attention has to be earned and most will not have the patience of suspending interest while lots of background and tangential information is provided.

Herein lies the power of the high concept; it facilitates immediate interest and understanding. The high concept doesn't have to (and rarely will) capture the breadth and richness of the idea, but some essence that makes a connection with the audience. 

But is can also focus the entrepreneur and this focus is probably more valuable than the mechanism of communicating the idea to others. Entrepreneurs get easily distracted and assume, just as when communicating, their idea needs full implementation before releasing into the market. What they presume is the minimal feature set for a release tends to have fluff that could be removed.

The high concept is a simple litmus test; how does feature X support the high concept? This should not be a slavish rule but a sanity check. As Einstein said, "Everything should be made as simple as possible, but not simpler." This focus can save an entrepreneur time and money, particularly at early stages where time-to-market is paramount and final value propositions are still emerging.

I have two favorite examples of high concept. In television, an NBC executive asked Michael Mann to come up with a show based on the idea "MTV cops". The result was Miami Vice and I think it is clear how the show tied to the high concept. In the Web 2.0 space, Meebo is "IM through a web page". Simple and concise, just like the actual product. I think many would envy Meebo's success and attention.

Most of software development can be considered from one of two perspectives: Is it innovative or can it be considered a commodity?

Starting with the latter case, these software projects are a re-implementation of software that has already been written numerous times. It is even possible to buy existing applications and integrate with other components or implement minor customizations. An example of commoditized software are shopping carts. Years ago, in the early Internet, merchant websites and shopping cart integration was expensive and required significant development; today I can pay an extra $20 a month in web hosting for the same functionality.

For a commoditized software project, it makes sense to look at low cost development options. These frequently employ overseas developers, thousands of miles away in other time zones. With commodity software, the requirements are well understood and many exemplary models exist. Communicating project requirements and expectations is easier, so the risks are far lower.

Innovators don't have such ease; requirements change often and are foggy at best. Building from existing components is either unfeasible or requires too much customization (the dreaded "integration tax"). This poses a great challenge for an entrepreneur, as being first mover may be more of a risk than an advantage. Large amounts of time and money can be expended while the entrepreneur searches for her actual market opportunity or the proper way to seize it.

Incremental and iterative development can help mitigate these risks for the innovator. With each iteration, the innovator has feedback that allows her to tune and adapt requirements, converging on essential functionality and de-emphasizing tangential functionality. For an entrepreneur with a limited budget, efficient use of development resources is critical.

While iterative development can keep you focused, it is not enough. Close collaboration and interaction with developers is also key. Building a rapport between product visionaries and those executing this vision not only creates a common sense of ownership, which leverages "collective brain power", but it forces the entrepreneur to clearly communicate her vision. Too often innovators have a muddy understanding of their own ideas. (A technique called "high concept" is another good tool for entrepreneurs and will be the subject of a future post.)

Unfortunately, many entrepreneurs treat their venture as commodity software, as they attempt to outsource development to low cost programming body shops. While I have a particular bias in this case, the real question for an entrepreneur is: If it is so easy to outsource your innovation, is your idea actually novel? Are there any barriers to market entry for a competitor? These questions are important to address before any development investment is made, regardless if the software is being treated like a commodity or an innovation.