Processes work under a certain set of conditions as opposed to being cast in stone. Imposing certain processes on your business without knowing why your business needs it can do more harm than good.
I come across a lot of articles that talk about software process and methodologies in absolute terms. Like they have to always work and they are always the best way to do something. In my experience, I saw that it’s far from the truth. Processes that work for someone evolve under a certain set of conditions, without knowing what those conditions were we’re just inviting more problems rather benefit.
Continuous Integration, everyone knows that it’s the way to be shipping, period. But what about construction? For a team that isn’t trained in writing tests for their code instead does a lot of testing manually, CI can produce more faults in the software and reduce the teams’ productivity. In this case, writing tests becomes a pre-requisite for CI as a process.
ColoredCow recently started working on a healthcare product. The product began being built as a proof of concept and so far was testing the market. It had now been run in production for a year with actual customers using it. The previous team that had built it so far was not very skilled in building applications, a lot of DRY violations, data leaks, and performance issues. When we came onboard to build the next version it would be instinctive to correct the code base and add tonnes of development processes to it. But that was far from what the product needed today.
The product needed to evolve in terms of what the market needs with more users and better features. So instead of investing a lot in correcting things, the best move was to build further and devote a small chunk of time to correct as we build further. In which case we built processes around on those needs.
If you’re interested in exploring more on development processes, do check these out.