We hear it a lot. “Oh, we’re too small to need all that.” But the truth of the matter is that, in all likelihood, you do need that. You see, modern ALM best practices are all about one thing: keeping your project from failing.
Let me run a couple scenarios by you. You’re a project manager at a Fortune 500 company worth a couple hundred million dollars. You’re about to budget $200,000 on a six month software project and you’re going to use a typical waterfall methodology. When that project falls flat on its face and gets scrapped without ever delivering anything of actual value you’ll hem and haw, point out that this or that made the project unfeasible to begin with and point out that the other three projects you’re managing are going great. No one is really happy about the project failing at the moment, but a few months from now no one will remember it anyways.
Now, consider you’re a member of a small startup. You only have five developers (in fact the startup only has six employees), and you’re about to budget that same $200,000 on a six month software project. Of course, your company doesn’t actually have a net value at the moment, and the money you’re spending is directly from one of your primary investors who also has an interest in the project itself. What happens if this project fails without delivering anything of value? The investor backs out, the company goes belly up, and you all get to play the employment game.
These scenarios, while obviously exaggerated, are not all that far fetched. A project failing without delivering any value can be devastating to a small to mid-sized company. The statistics tell a grisly tale: most software projects fail. Most of those that fail do so because of communication and requirements gathering issues. Most of the budget is spent fixing “self inflicted” problems, and most bugs are found by the end users. Stakeholder feedback comes too late to do anything about it.
These are exactly the issues that ALM addresses. Work item tracking increases communication and visibility. A prioritized backlog allows stakeholders to provide feedback before requirements are implemented. Unit testing, automated coded UI testing, repeatable test cases, and continuous integration help find bugs before they get into production. A tool like Visual Studio’s Feedback Client allow stakeholder feedback during development.
Perhaps most importantly, the “best practices” associated with modern ALM ensure that we aren’t creating legacy code. Maintenance is a huge cost that is rarely adequately planned for. Taking short cuts, and writing code the “just works” almost ensures that whatever you budgeted for maintenance won’t be enough, because skipping things like unit tests and code reviews practically ensures that you are actively creating legacy code.
But all of those little bits are easy to skip when you’re part of a small company. Creating that initial product is faster, and in most cases “easier” when you skip them. Landing that venture capital cash is all important, so you create content as quickly as possible. You think “we need to land this VC quick – then after we get the funding we’ll be able to rewrite it properly and fix all those problems”. In that situation you’re almost worse off if you do get the funding. No VC is going to give you $1M to rewrite the same thing you just showed them. You can’t go to your investors and admit that the thing you just sold them doesn’t actually work. They expect that you’re going to build upon what they’ve seen, not rebuild it.
Let me return to a point I glossed over previously. Software projects that fail without delivering any value are devastating to small companies. The resources just aren’t there to scrap an entire project and start over. But modern ALM espouses continuous value delivery; implementing requirements incrementally, the completion of which creates a unit of value. This means you can start seeing returns on your project before it is “complete.” Then if (when) you need to pivot, you don’t have to start back at square one, and all that work wasn’t a complete waste.
One final aspect of ALM utopia to discuss. Tech startups quite often become victims of their own success. Someone has a great idea, a team of development ninjas throw it together as quickly as possible. Cash starts flowing in, as do the customers. But then the customers start clamoring for new functionality. And they want it now. So your dev team grows, throwing legacy code on top of legacy code to keep that feature deployment rate high. The original ninjas start whispering that the infrastructure can’t support the weight, but the process is more or less still working. Right up until it stops working. And in another month you end up another MySpace because you are unable to pivot. Unable to control the exponential growth of technical debt.
The easiest time to implement the complete set of ALM best practices is before you start your project. Or as close to the beginning as possible. The longer you’ve been piling legacy code on top of legacy code the harder it is to implement process changes. So the next time you hear yourself saying, “we’re too small for that” take a step back and reconsider. No matter where you are in your development life, there won’t ever be a “better” time to modernize you practices and processes. It won’t get any easier, it will only get harder. Of course, wait too long and it won’t be an issue at all.