Where Product and Service Software Development differs
I’ve worked with Service Software Development for most of my professional life. An experience that ranged from multi-year long projects, big multi-disciplinary teams in large organizations, to just myself consulting for small startups and their hyper-focused teams. This background was the base for how I learned to develop software products in all my startups.
Although, the process of building software looks pretty similar in each of these contexts there are a few small distinctions that make all the difference. Being the main one the forces that push each kind of work forward. To explain better, let me first go back in time a little bit.
I come from an era of software development where the pursuit of Order was the main drive. Acronyms like RUP, ITIL, and PMI dominated the way we used to build software, the goal was to eliminate uncertainty early on. As a developer, it was your job to know what to build before you build it. The Agile movement came to contrast this reality and propose that we should embrace change and accept the unknown [1].
It’s not relevant which way is better than the other. Regardless, both ways of developing software, when provided as a service are grounded by the basic need to satisfy its sponsor. It does not matter if you are an old fashion software factory, a big consulting group or a modern software studio, in the end, you need to look good with whoever pays your invoice. This is the one you need to satisfy to make ends meet.
Be it a C-level or any mid-level person, you’d expect that the software being developed to have a user-oriented — or at least a business-oriented — goal. If not, the good practice for a professional service developer is to help its customers to understand their own goals with the software they want to be made. Especially about the intended user and how they are connected with the features to be built. But the reality is most common than not rougher than this. Not all organizations have clear goals, and not all sponsors have goals that align with the organization. Sometimes the sponsor just needs the software to get promoted or to gain some political ground, or even it’s not open to reveal or change its strategy. Maybe you did a good job and your sponsor is open for debate. But if your bets fail the one in the line is you and the continuity of your contract.
The tension between satisfying the sponsor and extending the contract life whilst being aware that this is a temporary relationship creates some unwanted results [2]. It favors short term results instead of long term ones.
Investing in code sustainability seems less important than meeting deadlines. Not that all organizations are not aware that code quality is needed, but usually when paying external — and usually more expensive — coding forces, the expectations are high on both productivity and efficacy. And since being on time highlights more than the inner working of code, it’s easier to focus on delivering fast and jumping into the next challenge, than taking the time to make sure things are properly set.
Conforming to rules is preferred instead of aligning practices and learnings. All organization has rules, even if not written, it’s part of their culture. These rules apply from the way code is written to how the team must adapt and evolve. But when the service team is external, there’s little expectation or desire to expend in improvement in the people. It’s expected that such investment to be done by the contractor itself, and not be the responsibility of the customer.
And the most common of all, accepting the sponsors’ hypothesis as axioms. Instead of taking the time into proving or disproving them. This always depends on the interests behind the project itself. But it’s safer to follow the strategy of the one paying and fail, than taking part in the risks and be dragged along when things fall apart.
I’m not saying it’s impossible to minimize these issues. I’ve seen many successful projects in such a context. Also, I’ve seen many more unsuccessful ones. Here I’m just pointing that this tension exists and is a force to be fought.
A product team, on the other hand, is bound to nurture a long term relationship. Given that the product is core to the organization, balancing short term results and long term sustainability is an underlying need for developers. As an example, a quick, hacky solution can be used to achieve a short term goal, but with the agreement that it’ll be properly fixed over time. Paying technical debt is seen as needed hygiene, not as paying twice for the same thing. Questioning goals and strategy should be easier since both developers and management are in the pursuit to extend the longevity of the company through the product been developed.
I’ll not run from the fact that I’m biased in my opinion here. More than a decade ago, I was well established in the software service industry. For me, it seemed to dominate the market. Most of the companies building software back then didn’t have software as its core, but just as a catalyst for a well-established business. Over the years, with the rise of apps and startups, the software-centric business has more and more become the norm. So, the change in mentality for developers seems natural in this context.
I’m also, not saying that good relationships and results can come from using external development services. Nor even, I’m advocating that having the benefits that I’ve pointed out are impossible to flourish in such context. My main point is that the tension I presented is real, and accepting and understanding it is key to minimizing its effect on the software being built. Knowing so allows the parties involved to address it and use the service as a catalyst for your intents and better avoid the issues along the way.
[1] This is such a broad topic and so well explored that I won’t take my time on it. Regardless to say, I think both ways of thinking have their merits. 🤷♂️
[2] I consider every contractor as temporary since, if the intention is to have a long-lasting relationship, the best way would be for the company to have a proper team to do it (if it’s key/core to its strategy).
