There was once such a thing as a waterfall software development cycle. Now it is largely a relic of the past, surpassed by the far more business-friendly agile software development. Agile really began to take off around the beginning of the decade and has been widely adopted. But software development innovation did not stop there and it snuck up on agile development, with many new and emerging development approaches that are often better than agile development.

1) Technology is 95 percent commoditized

[login]As engineers, this is a pain to our hearts and ears, but alas it is true. No matter what country you are in, there is probably another country where engineers can be hired at cheaper rates. Software work that is not outsourced is commoditized by a general move toward simplicity. Whatever is no longer complex can be done with 3rd party libraries and APIs that do nearly everything you want. The business logic that may still be left to write is becoming simpler as the Web space is undergoing a movement where there is a focus on simple business models and content quality, rather than technology.

2) Understanding technology risk vs. market risk

Another phenomenon that is paralleling technology commoditization is lack of something called “technology risk.” In the 1990s good programmers were few and hard to hire. That resulted in terrible software that often destroyed companies by numerous delays, or just never got built. Now, this is nearly never the case. Projects may get delayed, go over budget and software still may not hold up when tested by large scale of users, but generally, it is all fixable and there is little risk of complete implosion.

Instead, the risk in the market, meaning that while delayed or not, the software will eventually be released, it is quite uncertain that it will be a market fit. There are no guarantees in product-to-market fit and there is still risk is there, necessitating more resources focusing on the marketing and product vision rather than on technology.

3) Choose ideas that have no technology risk

While I make it sound like there is no technology risk, there still is if you are innovating in complex spaces like semantic web, cloud computing, search or other advanced or resource-expensive Computer Science fields. If you are in those spaces, there is quite a bit of technology risk. While those spaces are very exciting, unfortunately there is still just as much market risk in them as well – doubling overall risk. Before choosing the space to innovate, most people would choose the space with half the risk and is simpler.

4) Be a technical debt millionaire

This point is not for everyone. If you are doing enterprise software, you should definitely avoid accumulating technical debt because it will make many people in your organization have a difficult time dealing with the software you are building. If you are dealing with people’s finances or medical information for example, you should also be very careful.

On the other hand, if your startup isn’t doing something mission critical where vital information is at risk, you can bypass many things that are commonly considered good practices, and cut corners, in order to release the product faster and test out the market to see how much market risk there really is.

5) Security focus only after being hacked

Security is a good example of accumulating technical debt. There are different techniques for ensuring security and again, if you are in a business that requires strict security, this point is not for you. On the other hand, if can, forego most security practices and just focus on the simple and effective practices like input validation which also helps reduce bugs.

Other than that, to speed up and cheapen development, you may want to leave off session hijacking or complex server configuration security for later, or when you get the security flaws exposed by being hacked. Yes I am advocating being hacked. But again, only follow that advice if you don’t have much to lose. Most hacking attacks are not very malicious and actually help you understand where your security flaws are.

That way you don’t have to guess what to secure and can speed up development focusing on developing the core product.

6) Forget scalability

Foregoing scalability is one of my favorite things to do when I am racing to release a product to test out how the marketplace reacts to it. The concept of scalability is a favorite talking point of business folk, but people who understand concepts behind this buzz-word realize that there are many things to into making something scalable.

Firstly, a product can have some parts that can withstand scale, and other parts that crumble and crash when hit with traffic. No matter how much people may say they know which parts of the product will need to be scalable, the truth of the matter is that no one knows for certain when or if significant traffic will ever reach any particular feature. Furthermore, during the innovation phase, many features get added and thrown away shortly after. It is the normal process of innovation. Not everything attempted will turn into success. The value lies more with rapid development and ability to try out the features in front of small to medium audience to tell whether the features are worth keeping.

Lean projects are characterized by rapid iteration that gives insight what features will stay and see scale. For those features, scalability should be considered. But out of the many developed features, few will see the light of day and many should probably be discarded – so to cheapen the innovation phase, I don’t put much emphasis on scalability.

7) Say no to good ideas

Lean projects by definition require a lean amount of resources. And this article deals with ultra-lean projects. That means there are a limited number of features that can be built at any given time and the decision-making process really needs to be extra crisp in deciding which features or functionality to create.

A common difficulty is deciding which few features to do out of the infinite good ideas that are possible to pursue. That means saying no more often than saying yes, and a focus on rapidly bringing to market the few features that were decided on, and really trying to find the market fit for those released features.

8) No heavy Languages

I realize that no one will use C++ to create a Web startup today. But many people still set out to create Java-based products. Java is still great for enterprise, but it is way too heavy for lean projects.

Most young projects today are done with PHP, Ruby or other new languages that are faster to prototype with. A great example of a successful startup that prototyped with Ruby On Rails is Twitter, which was born out of doing something I am advocating in this article, which is iterating over product ideas. For the team of Twitter, one of those iterations turned out to become Twitter.

9) Speed over quality

This is another controversial point because in the long run quality always wins. In the beginning, the successful features are not known, so the task is to bring something to market fast and if it shows signs of life, then to focus on improving the quality of that product. And if it does not find people who may use such a product, admit it as a cheap and quick failure, learn what made it a failure, figure out how to avoid repeating the failure and quickly release something better.

Teams embracing the lean and ultra-lean projects love the word “failure” because they understand it as a big success. Every failure costs little, and offers insight that no amount of theory would have predicted. These teams quickly learn from the “failure” and a short time later surprise everyone by releasing much better products that arose from the ashes of the failure.

10) User experience over user interface

Over the past 15 years we’ve seen the Web grow and mature. There are even Web eras like pre-bubble, post-bubble, etc. In each era there are many examples of companies or products that looked and felt extremely simple, but provided a lot of value to people, and caught on because they did one thing really well despite looking very simple. Craigslist, Google’s search, and Twitter are some of the biggest companies the Web has seen and are all very simple-looking with great usability (UX).

The reason I bring up this point is that many people find reasons why a product has to have many features and look very beautiful. But the truth is that it doesn’t always have to win with that. It has to have a great core feature set that is easy and extremely intuitive to use. Yet there has to be quite a bit of innovation before such a product is created, and that is why the lean and sometimes ultra-lean style of rapid prototyping and iterative improvement wins.