5 ms·

[I recall posting this here in the past, but worth re-posting.] The "handy rule" from the book Team Geek -- the newer edition is called Debugging Teams[1]. It'

[I recall posting this here in the past, but worth re-posting.] The "handy rule" from the book Team Geek -- the newer edition is called Debugging Teams[1]. It's from chapter "Offensive versus Defensive work": [...] After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the sexiness of a product (e.g., improved UI, speed, or interoperability). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migra- tion, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them. If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.” We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide. [1] http://shop.oreilly.com/product/0636920042372.do http://shop.oreilly.com/product/0636920042372.do

munk-a 7y ago
This is why I think it's good for technical debt to be partially accounted for by development management types - write down how much offensive and defensive work is required to sanely complete a project or just stay ahead of the curve and let the total of those two parts be reported as the cost of the feature - it's a benefit to the long term health of your company.
WrtCdEvrydy 7y ago
> If you spend all your time on them, people perceive your product as holding still I've always found this hilarious... we spend thousands on hiring developers and one of the primary goals is to find a well rounded person who is okay doing maintenance tasks and ensuring proper code quality and knows how to write effective tests. A short time later, I come on to a project just for a status update and find the developers cutting tests and maintenance tasks at the orders of the PO who then complains that tickets are getting larger and larger.
- jeremyjh 7y ago
  Devs should not ever say the word "test" to a PM/PO. If the question is, "why isn't the feature ready?" the answer is "because the work took longer than I expected." If you say "because I've writing tests" you are sabotaging the team. Tests aren't any of the PO's business, they are just part of the software that supports the feature.
  - Aeolun 7y ago
    This is an ideal reality. If the PO is at your desk every day to ask why the thing isn’t done, most developers are eventually going to drop everything non-essential to the functioning just to get them out of their hair.
ben_jones 7y ago
I think that's a leaky abstraction. Code refactoring can have a huge performance impact that is 100% noticed by the end user.
- tj-teej 7y ago
  I think the OPs paradigm holds. If the Code Refactoring has a huge performance impact then it's Offensive work, if it has no impact, then it's defensive.
  - brightball 7y ago
    IMO you just pointed out the key to selling the work. Reclassification.
    - tj-teej 7y ago
      Not exactly, because sometimes there's refactoring which has 0 customer benefit. Sometimes it doesn't improve the UX/latency/etc. Sometimes it just makes the codebase easier to maintain, the point of what the OP is saying is that this work is hard to justify. If you spend an entire year making a codebase "easier to maintain" but don't deliver anything tangible that is all defensive work and not offensive work and there's no reclassification which can solve that.
    - hinkley 7y ago
      It’s dirty accounting tricks for a greater good. I kinda resent the fact that we have to resort to this.
      - brlewis 7y ago
        A huge performance impact is a shiny thing that is easy to show outsiders and get them excited about. There is no dirty accounting here.
        jolfdb 7y ago
bezoisevil 7y ago
Gotta love it, this is the same dumb ideology Agile spews. Develop develop develop, forget about fixing issues - They'll magically go away... It's clear that these people do not work in Enterprise environments
JamesBarney 7y ago
Sometimes I think that offensive work is always prioritized ovee defensive work. And then execs and stakeholders think when the code is a mess and a simple change takes a day and a half it's the developers fault. And it's difficult to say the least to convince stakeholders to defer a feature for a little bit of refactoring. This why I think it might be useful to allow the stakeholders and pms to decide the % of time spent on defensive work instead of what defensive work to do. And then you have a specific metric on technical debt(we budgeted 30% for defensive work and we've only spent 10% that's a 1000hrs of technical debt) Something to specifically point to when a stakeholder asks why is this taking so long or why is the application buggy. And ideally this caused a company wide increase in the allotted time for defensive work. Bonus:It will also give developers who like working on clean projects a number to ask when being hired.
- MBCook 7y ago
  > instead of what defensive work to do That would solve a problem I saw at a previous job: new features would be described as technical debt, so they could take up tech debt time at the expense of _real_ debt.
  - redisman 7y ago
    That's beautifully absurd. Bravo, management
  - jolfdb 7y ago
    My team spends 80% of our time paying down tech debt...by building a new system that will let us throw away the old system later this year, I mean next year, I mean in 2 years, I mean when the last zombie client with no staffing migrates off of it.
CodeMage 7y ago
> If you spend all your time on them, people perceive your product as holding still. This is precisely what bothers me about the vast majority of software out there. It's hard to find software that doesn't suffer from what I call, for lack of a better name, "forced evolution": the devs keep fiddling with the UI and adding new features of dubious usefulness. Meanwhile, the quality slowly, but surely deteriorates: the software gets bloated, runs slower, becomes harder to use, etc.
- ff317 7y ago
  +1000 This was how I said it, buried off in the documentation of an open source project: I'm not a fan of the way most software is developed, where features accrete on features in endless succession like barnacles attaching to the hull of a ship until there's more barnacles than ship. I think most developers don't spend enough time on quality, on refactoring, or on cleanliness, and I think they don't weigh the costs of every new feature (and every piece of old compatibility cruft) as heavily as they should. I'm also not a fan of the kind of personal rigidity where one never questions one's own past decisions and thoughts. I regularly make stupid design mistakes, and I don't want to have to live with them forever. Software projects should at least try to value simplicity and purposeful design, and try to avoid the Second System Effect.
invalidOrTaken 7y ago
Seems like "finding another job" deserves a spot in offensive work: -- it's likely revenue-positive -- it's visible -- it involves understanding customer needs
mikekchar 7y ago
I have a similar idea. I call it the "horizon". There is a certain amount of time where you can go off and do stuff that doesn't result in stake holder visible change. How much time you've got depends a lot on the organisation, but I find that 2 weeks is a good rule of thumb. If you sail over that "horizon" your stakeholders lose sight of you and start to get worried. Ever day you spend over the horizon increases the risk of the stakeholders taking drastic action (from pressing the big, red "stop the presses" button and changing direction all the way to cancelling the project). The key is always to deliver value within that horizon. As long as you keep doing that regularly and predictably, usually nobody will care what else you do.

munk-a 7y ago

This is why I think it's good for technical debt to be partially accounted for by development management types - write down how much offensive and defensive work is required to sanely complete a project or just stay ahead of the curve and let the total of those two parts be reported as the cost of the feature - it's a benefit to the long term health of your company.

WrtCdEvrydy 7y ago

> If you spend all your time on them, people perceive your product as holding still I've always found this hilarious... we spend thousands on hiring developers and one of the primary goals is to find a well rounded person who is okay doing maintenance tasks and ensuring proper code quality and knows how to write effective tests. A short time later, I come on to a project just for a status update and find the developers cutting tests and maintenance tasks at the orders of the PO who then complains that tickets are getting larger and larger.

jeremyjh 7y ago
Devs should not ever say the word "test" to a PM/PO. If the question is, "why isn't the feature ready?" the answer is "because the work took longer than I expected." If you say "because I've writing tests" you are sabotaging the team. Tests aren't any of the PO's business, they are just part of the software that supports the feature.
- Aeolun 7y ago
  This is an ideal reality. If the PO is at your desk every day to ask why the thing isn’t done, most developers are eventually going to drop everything non-essential to the functioning just to get them out of their hair.

ben_jones 7y ago

I think that's a leaky abstraction. Code refactoring can have a huge performance impact that is 100% noticed by the end user.

tj-teej 7y ago
I think the OPs paradigm holds. If the Code Refactoring has a huge performance impact then it's Offensive work, if it has no impact, then it's defensive.
- brightball 7y ago
  IMO you just pointed out the key to selling the work. Reclassification.
  - tj-teej 7y ago
    Not exactly, because sometimes there's refactoring which has 0 customer benefit. Sometimes it doesn't improve the UX/latency/etc. Sometimes it just makes the codebase easier to maintain, the point of what the OP is saying is that this work is hard to justify. If you spend an entire year making a codebase "easier to maintain" but don't deliver anything tangible that is all defensive work and not offensive work and there's no reclassification which can solve that.
  - hinkley 7y ago
    It’s dirty accounting tricks for a greater good. I kinda resent the fact that we have to resort to this.
    - brlewis 7y ago
      A huge performance impact is a shiny thing that is easy to show outsiders and get them excited about. There is no dirty accounting here.
      - jolfdb 7y ago

bezoisevil 7y ago

Gotta love it, this is the same dumb ideology Agile spews. Develop develop develop, forget about fixing issues - They'll magically go away... It's clear that these people do not work in Enterprise environments

JamesBarney 7y ago

Sometimes I think that offensive work is always prioritized ovee defensive work. And then execs and stakeholders think when the code is a mess and a simple change takes a day and a half it's the developers fault. And it's difficult to say the least to convince stakeholders to defer a feature for a little bit of refactoring. This why I think it might be useful to allow the stakeholders and pms to decide the % of time spent on defensive work instead of what defensive work to do. And then you have a specific metric on technical debt(we budgeted 30% for defensive work and we've only spent 10% that's a 1000hrs of technical debt) Something to specifically point to when a stakeholder asks why is this taking so long or why is the application buggy. And ideally this caused a company wide increase in the allotted time for defensive work. Bonus:It will also give developers who like working on clean projects a number to ask when being hired.

MBCook 7y ago
> instead of what defensive work to do That would solve a problem I saw at a previous job: new features would be described as technical debt, so they could take up tech debt time at the expense of _real_ debt.
- redisman 7y ago
  That's beautifully absurd. Bravo, management
- jolfdb 7y ago
  My team spends 80% of our time paying down tech debt...by building a new system that will let us throw away the old system later this year, I mean next year, I mean in 2 years, I mean when the last zombie client with no staffing migrates off of it.

CodeMage 7y ago

> If you spend all your time on them, people perceive your product as holding still. This is precisely what bothers me about the vast majority of software out there. It's hard to find software that doesn't suffer from what I call, for lack of a better name, "forced evolution": the devs keep fiddling with the UI and adding new features of dubious usefulness. Meanwhile, the quality slowly, but surely deteriorates: the software gets bloated, runs slower, becomes harder to use, etc.

ff317 7y ago
+1000 This was how I said it, buried off in the documentation of an open source project: I'm not a fan of the way most software is developed, where features accrete on features in endless succession like barnacles attaching to the hull of a ship until there's more barnacles than ship. I think most developers don't spend enough time on quality, on refactoring, or on cleanliness, and I think they don't weigh the costs of every new feature (and every piece of old compatibility cruft) as heavily as they should. I'm also not a fan of the kind of personal rigidity where one never questions one's own past decisions and thoughts. I regularly make stupid design mistakes, and I don't want to have to live with them forever. Software projects should at least try to value simplicity and purposeful design, and try to avoid the Second System Effect.

invalidOrTaken 7y ago

Seems like "finding another job" deserves a spot in offensive work: -- it's likely revenue-positive -- it's visible -- it involves understanding customer needs

mikekchar 7y ago

I have a similar idea. I call it the "horizon". There is a certain amount of time where you can go off and do stuff that doesn't result in stake holder visible change. How much time you've got depends a lot on the organisation, but I find that 2 weeks is a good rule of thumb. If you sail over that "horizon" your stakeholders lose sight of you and start to get worried. Ever day you spend over the horizon increases the risk of the stakeholders taking drastic action (from pressing the big, red "stop the presses" button and changing direction all the way to cancelling the project). The key is always to deliver value within that horizon. As long as you keep doing that regularly and predictably, usually nobody will care what else you do.