There is no Silver Bullet for software development, as you can read in Fred Brooks epic 1975 book about software development titled “The Mythical Man-Month“. But if I have to come up with any Silver Bullet it would be: ‘Rush code to live’. This is a theoretical model for doing software development, which follows the DevOps model. Since it is a ‘Silver Bullet’ it claims to be a revolutionary way to produce software much faster and cheaper.
SaaS needs a rush
In a Software-as-a-Service (SaaS) landscape you need to keep your customers happy by continuous, incremental improvements of the software, which follow an organic growth model. By doing big bulky updates, the user will have to wait a long time before anything changes and the user experience will suddenly change, which might alienate your users. Apart from that: 1) the moving target kicks in; 2) risks grow, since reverting will be increasingly difficult; 3) it is unclear what needs to be tested; 4) and users lose confidence when you keep moving the deadline for the next version.
So take SCRUM, with a product owner and everything that comes with it. Now split your big software team of into small expert groups of 2-3 people that own a specific part of the code. Increased feeling of ownership encourages responsible behavior. Next is to make sure every group has one natural leader (a more senior developer), to avoid unproductive coding style/architecture discussions. Let the programmers develop blocks of code that are as small as possible, but can be brought to live individually. This would make them work for 2-3 days on a single small feature. If a feature is too big, simply cut it up into parts to make it smaller. Test the feature and bring it to live by the next day, when the code is still ‘top of mind’ and bugs can be fixed fast and easy. It is important the testing is done together with some other developers in demo-like sessions to avoid blind spots and encourage competition and enthusiasm.
Testing and deployment
When bringing the code to live, make sure this is done carefully by only the best developers. Do it when usage is low and do not tell customers about your ‘Ninja deployment’, since this may increase the expectations and thus the bug costs. When bringing code to live, your monitoring must be top-notch and you must be able to revert fast (only to fix bugs and redeploy). This means that if something fails, it will always be the new feature and only a limited set of customers will notice. If you can, bring the feature live for only a subset of the customers first. Both of these measures help further reduce the risk and positively influence the test (test vs. bug costs) trade-off on which you decide the amount of testing effort. Do not hesitate to bring code to live that does not add value. Even if it only provides part of a feature and must therefor be hidden, you should still deploy it.
Change your thinking
Now think outside the box and consider the truth of the following ‘Rush code to live’ principle:
Every 10 lines of code written but not brought live (into production) will cost you one extra man-hour every day.
Reasons it might be true? Only after code is running flawlessly on live will people stop discussing, changing, arguing and worrying about it. Note that I only have a gut feeling to back this claim up, and is not based on any research whatsoever. Still, I believe the cost of unreleased code is way higher than anyone can imagine, so ‘Rush your code to live’ for fun and profit!