There has been a lot of talk about agile development. In recent years, agile development was surpassed by lean development which adopted many great practices from agile development, but added elements of speed and cost-effectiveness to the overall process. The focus shifted a little bit towards innovation rather than quality of the software and the lean development method has seen rapid adaptation among many young companies which are now needed record low investment funds to bring a product to market.
In my own software engineering practice I have found that the lean development as widely prescribed was too theoretical and general because it is meant to work on a mass scale. I had to make my own adjustments. Plus, when I spend my own time and money, I want to get the most return out of the resources I put into the project. I think many people can identify with that motivation.
What I had to was adjust the way I build software and companies to be more than lean. What I came up with is pretty much insane by any traditional software development project, but it is doing wonders for me and I want to share it with others because I know it works. So before I sound like an infomercial, let me outline my approach which allowed me to iterate and innovate at a lightning speed. Some of my practices have had to become borderline reckless, but some are probably common sense.
I stopped programming in Java and began developing in languages like PHP or Ruby on Rails. This is just common sense as these languages allow more flexibility in developing faster, and are easier and cheaper to host.
I began being extremely realistic about the projects I took on. Since I am just one guy (sometimes joined by limited partners) I have very limited resources and there are many projects that I just should not attempt to tackle with the resources I have at my disposal.
I also began to only focus on business ideas which have no technology risk. For me, that meant stopping semantic web projects and not embarking on cloud-based technology innovation, or search. Those types of businesses just require lots of data-processing power and expensive man-hours, and simply carry unnecessary technology risk. Market risk that already comes with every business is enough risk for me, and there are plenty of business opportunities out there that don’t carry technology risk and work on simple and proven technology.
I also dropped all scalability concerns. It might be reckless, but let’s honestly face it: most of the software I create will never see over 1,000 users over its entire lifetime and there is no need for scale concerns. On the other hand, if scale hits a product I put out into the world, two things may happen: 1) The piece of software may actually be able to handle the scale because that is what servers and databases are generally made to do, and 2) If it does not handle scale well, I can just rewrite some of the code based on the lessons learned on why it did not scale initially.
If I don’t sound strange yet, I also do not focus on security other than to validate input parameters. Again, let’s face it – I have no mission-critical data. Plus if I get hacked, it actually helps me because I get to understand a vulnerability I have which needs to be addressed when the hacked feature becomes popular and sees real world use.
I also don’t hide unfinished products. As soon as I buy a domain name, I put it live online so it can begin aging in the search engines. And whenever I have even test data, I put it live so it can get picked up by search engines for SEO purposes. Some people like to be secretive about their projects, and often that makes sense for a number of reasons. In my case, I focus on SEO because I find it practical, and help early adopters easily find me.
You may already be noticing a trend. I am on a mission to accumulate enough technical debt to become a technical debt millionaire in order to put resources into iteration of innovation. That is the insane-lean development that I’ve adopted that has been working for me and I hope some of the techniques work for others.
Source by Alex Genadinik