[HN Gopher] Code Red: The Business Impact of Code Quality
___________________________________________________________________
Code Red: The Business Impact of Code Quality
Author : rbanffy
Score : 17 points
Date : 2022-10-28 14:48 UTC (8 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| smodo wrote:
| My main take away from this is the importance of getting to grips
| with the codebase first. This may seem completely obvious but
| right now I'm in a context where the codebase is spread across
| different dev teams whose code 'meets in the middle' through an
| API but is never considered in a holistic fashion. In other
| words, there is not even a coherent codebase to review. The
| project is overdue and over budget by 100%, of course.
| retrocryptid wrote:
| I like where this is going. Most projects I've been on recently
| have a "hurry up and get something out" mentality. Which... I'm
| not completely opposed to. It's important to get some early
| design wins out. But the flip side of this is as you go on, you
| learn more about the problem domain and whether specific
| solutions are appropriate. You _should_ be okay with throwing out
| bad code or code that internalizes old requirements that didn 't
| survive into the present.
|
| I once had a conversation with a "Business Guy" and I brought up
| the concept of "technical debt." Their response was "Oh! Great!
| We have lots of cash right now and can add more programmers later
| to pay down the debt, but only if we release something very, very
| fast!" -- While the concept of technical debt make sense to me, a
| software person, the business guy's response was "debt is
| something that can help you if used strategically." We changed
| over to using the phrase "Delivery Molasses" because the more of
| it you got, the harder it was to move through it.
|
| And rather than silently stew about how "business people" don't
| understand software, putting it in terms they understand so you
| can have a grown-up conversation is worthwhile. So... happy to
| see someone's doing that here.
| ahepp wrote:
| > I once had a conversation with a "Business Guy" and I brought
| up the concept of "technical debt." Their response was "Oh!
| Great! We have lots of cash right now and can add more
| programmers later to pay down the debt, but only if we release
| something very, very fast!" -- While the concept of technical
| debt make sense to me, a software person, the business guy's
| response was "debt is something that can help you if used
| strategically." We changed over to using the phrase "Delivery
| Molasses" because the more of it you got, the harder it was to
| move through it.
|
| To continue the analogy, perhaps the disagreement was what the
| interest rate is on technical debt? Or that viewing it as
| "debt" makes you think throwing money at the problem can fix it
| quickly, when it has to be paid down through labor instead?
| retrocryptid wrote:
| Absolutely. I think the "business guy" was mostly familiar
| with non-usurous interest rates. They hadn't heard the term
| "technical debt" enough to understand that interest rates
| increase the more you borrow. Every bit of cruft you add to
| the code adds to the interest rate as well as the principal.
| pjmlp wrote:
| As someone that also deals with security, what I like is that
| memory corruption bug fixes and exploits are being mapped into
| the money spent fixing them.
___________________________________________________________________
(page generated 2022-10-28 23:03 UTC)