Comment by draz | Hacker News Reader

Comment by draz | Hacker News Reader

Parent Full thread

I am Product in a large corporation, and it's a certainly a fine balance. In a previous life, I was a developer, and I dealt with similar issues. I have a lot of respect and empathy for the the Tech team. Therefore, I asked my Tech team to inform me when things are getting out of hand -- that's the responsible Product thing to do. I instituted that technical debt is part of our KPIs. If it's not captured, it's not actionable. A few examples: - Documentation: required when method's cyclomatic complexity is high or method is just plain long (we defined what we consider "long"). Every customer facing method has a working usage example (%), etc. - Test Coverage: % unit tests (defined by modules) -- higher is not necessarily better, but it gives us a sense of where we stand. % of test automation: manual vs. automated. - Refactoring delays: # of TODO comments, # of compiler and static code analysis warnings (e.g., “this method is deprecated”) --> that is a sure sign that things will break in the future and an investment is needed.

There's some development work to be able to capture these things, but it gives visibility and power to Tech to inject some maintenance work into normal sprint development. I'd love to hear what other people are doing.

> technical debt is part of our KPIs. If it's not captured, it's not actionable

This is where I suspect manager-types and developers have a vigorous divergence in values.

Professionals routinely encounter situations where something is wrong and needs to be "actioned" but its wrongness isn't effectively measured by any metric (other than the opinions of the experienced people looking at it).

There is a certain species of manager who has taken Taylorism a bit too far and says that anything not reflected in the KPIs is not real and not getting acted upon. I hope this isn't what you're expressing here, but oh man is that mindset frustrating.

On the other hand, at the end of the road - or the rewrite - something should have been gained in terms of money, risk or time.

Being shitty is not reason enough, but it's almost always possible to reason and quantify and weigh the cost versus the benefits.

Of course something should be gained, but that doesn't mean you can always tell how much would be or was.

There is no mature "actuarial science" of software development. The market can provide concrete pricing for new feature development; engineers can't tell you how many dollars of tech debt you're in or give three significant digits on the probability of a major outage tomorrow.

That doesn't make money/risk/time costs which are difficult to measure any less real and it doesn't make them smaller than the ones which are easy KPIs.

Nor can you necessarily look at the movement of measurable KPIs and say "man, that rewrite was a waste of money." Who's to say things wouldn't have been worse without it?

> it's almost always possible to reason and quantify and weigh the cost versus the benefits

I don't think so. As a pretty good analogy, can you quantify the benefit of replacing knob-and-tube wiring in an old house? Now consider that the house across the street keeps its old wiring for the next twenty years without anything bad happening.

Senior staff in pretty much all organisations are given some latitude with respect to performing tasks that they believe will be beneficial without needing to produce a specified cost-benefit.

We have one-on-one catch-ups with staff, we have all-hands meetings, we visit clients, read books and articles, attend industry functions, issue press releases, meet with potential investors, etc.

There's value in all those things, but very rarely do we need to account for the fact that we spend time on them.

Senior engineering staff need that same freedom - it should be totally appropriate for them to make that call that "I'm accountable for the technical quality of this code, and I've decided that this needs to be done".

That requires some sense of business acumen - there needs to be an appropriate balance of technical investment to business investment - but that's part of the role of being a senior dev / tech lead / architect / whatever-your-organisation-calls-them.

I agree.

I am not saying that you always need a detailed balance sheet, just that it's good to reason about the benefits.

It's especially hard to quantify risks - that's where you really need the expertise.

What I wanted to point out is that there seems to be quite many developers that actually do not have a sense of business acumen, and are willing to spend alot of money on low priority tasks, just for their own personal pleasure.

The problem with raising issues with a framework like Scrum is that despite many share references, most people are in environments which apply Scrum in a slightly different way.

We talk about organisations applying Scrum but what we're really referring to are groups of people, and depending on those people, their mindset, their history and their current role requirements - they will use the Scrum model in their own idiosyncractic way.

Take the point about technical debt and running so fast with an Agile development workflow that you never get to refactor code or properly document etc.

Even if you just took that in reference to one specific company, the value of, cost of, and importance of these things could be different at different times.

When a startup is running to get MVP out to get customer feedback, it's usually much more efficient to set the basic expectation that the first version of your product will get thrown away once you've learned all the important aspects of what you need to deliver. With that in mind - startup development is a completely different beast than when your product is established and you have paying customers with expectations of up-to-date documentation etc.

Some managers are do not have good people skills and manage by just holding developers to account based on the expectations set in their Scrum planning day. Discussions about whether refactoring should be done yet or not may not even be something they want to know/talk about and they rely on engineers to factor that into their sprint estimates.

Depending on whether the company is being driven by sales/demo opportunities, or feature roll-out timescales etc. then the call about whether to do something 'quick' or 'right' may drop either way.

For developers it's important to understand the dynamics that are driving the business and what their role is (sometimes you have to 'JFDI'). If you have a good engineering team with a strong leader then these things shouldn't be that visible to anyone else. It's also important to be able to meet the expectations you set. If you keep delivering late then you'll also struggle to get people to let you do more than the minimum required at the time.

For the business as a whole it's all about the big picture and understanding the decisions you make and what their impact (short and medium term) is.

If you want quick releases and don't have the resources for that to allow for good documentation and/or scalable code, then you need to understand that technical debt is building up and at some point it will need to be paid.

> despite many share references, most people are in environments which apply Scrum in a slightly different way

Exactly. In fact, the linked text is a prime example: it professes to address the "standard Scrum as described in the official guide", and then goes on to condemn the notion of story points. Now, I happen to agree with those story-points criticisms, but guess what: that official guide says nothing about story points at all! :o

Reply on news.ycombinator.com