If you have been in the software development industry for a
while, like me, you probably heard a lot about the term “technical debt”. When that
is mentioned, people refer to all those details on the code side that were not
done or tested properly – which may cause problems that will cost way more to be
solved later than if they had been avoided earlier.
What we typically do not talk about, though, and which I
mean can have even bigger impact on the life of developers and companies alike,
is something that we could call “portfolio
debt”, for the lack of a better term.
What I am talking about is all those things that make
(business) people in a software company decide to go ahead with requests that
should not have been accepted in the
first place. It includes all the lack of ground work on requirements (therefore
“portfolio debt”), which result in developers spending lots of time doing
things that smells like nobody is going to ever use them – or at least not use
it in the way features are being done.
Do you feel my pain?
My feeling is that this is the single main source of waste
of resources in our branch. Waste that not only costs companies a good deal of
opportunities and revenue but that, in more severe cases, can make the whole
thing go bankrupt. Even when a company is seating on a position that could
otherwise be very profitable.
There are several reasons, I think, for why this happens. To
name a few
- Calling things the wrong name – or all sorts of mental biases. Saying, for example, that this request comes from “Company A” instead of saying that it was mentioned in a meeting by “Mr. Smith, who happens to work at the department X of Company A” – that alone can make people treat a request differently, as if it deserved more credit and, in consequence, making it hard to challenge its content.
- Too shy to show lack of technical understanding – nobody knows everything. A portfolio or product manager typically makes the bridge between business needs and the technical side. If he or she do not understand the technical aspects involved in a certain request, the assessment of cost/benefit in implementing it is compromised. In environments where there is no space to ask “silly” questions, however, one can go along forcing wrong views on a requirement, even despite eventual protests from developers.
- Big companies, big egos – related to the previous case, but more into all those portfolio people that want to build their careers, and quickly jump up to the next position – so that winning an argument in a meeting means more, in the internal political grand scheme of things, than actually aborting a request whose returns are questionable.
- Small companies, big dreams – in search of being the “next big thing”, portfolio personal in some small companies make bold assumptions about how the world is or will be soon, and get hooked on requirements that has very little to do with the current or potential revenue streams right here, right now.
These are just some examples, but there are many other
reasons why requests get into the backlog, when they should simply have been
rejected – or, at least, better negotiated/understood. Not doing so may not
cost anyone’s salary at the end of the month, but certainly affects the
sustainability of the company – and everyone’s salaries – on the longer term.