Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

10 Steps to Go From Agile to Ultra Lean Development

Why you shouldn't use certain programming languages, why you should focus on speed over quality and other nuggets.


advertisement
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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap