Do You Have Feature-itis?

Feature-itis. It's an agile Product Owner game. It's when the Product Owner says, in his or her best George Carlin voice, “Gimme Features. I don't care about no stinkin' framework. I don't care about no technical debt. I don't care that it's going to make your work harder later. I only care about now. I'm short-sighted, focused on today, or this iteration, and that's all I care about. Show me the features, baby, show me the features!”

Now, I bet that you have never heard a product owner or customer say those precise words. But you have heard words like them. If you have, you are suffering from feature-itis. And, you have some options.

  1. Make sure that all your estimates include the necessary architectural work  required to do a good job. I don't know why teams don't do this as a matter of practice. (I suspect that teams do not have access to the architects they need.)
  2. Explain the cost of not looking at the architecture, or at least the local design as you proceed to the PO. Architecture debt is insidious, and builds quickly. Architecture debt is the most expensive debt to pay off, because the longer you go without paying the debt, the more expensive it is. Architecture debt has a high cost of change after the the decisions have been made. And the decisions have been made by many different people in many different ways because of Conway's Law.
  3. Track velocity in a burnup chart. Burnups tell you how many features you have completed in a unit of time, which is the measurement you need to know. Because if you do have architectural and other technical debt, your velocity is going to start to decrease over time.  It might not decrease dramatically the first iteration, but if you continue to have feature-itis, and don't go back to address the debt in your product—especially the architectural debt—your velocity will decrease.
  4. You can placate the PO, swallow your pride and your professionalism, and just do what the PO asked for. Sometimes, this is the right answer.

If you have more options, please add them in your comments.

Feature-itis is a seductive disease, and is a common problem among newer POs. For the first time in their professional careers, they actually see features coming out of the technical teams. It's a heady feeling. No wonder they fall prey to the dark side.

But with that feeling of excitement must come a feeling of responsibility. Not only is the PO responsible for the product features, the PO is responsible for the business value of the product, and knowing that the team is able to continue to extend the system. Without architecture, tests, all of the necessary engineering practices that good software requires, a technical team cannot deliver.

A question for my readers: Is automated testing debt a special form of architectural debt? The reason I'm wondering is that automated tests allow you to know if your changes break anything. They provide feedback to developers. Yes, they are helpful to testers for regression purposes, but they are most helpful to developers. So, I am wondering if the lack of automated tests are a special form of technical debt, and most specifically a form of architectural debt. I would like your opinion on that. Please chime in.

14 thoughts on “Do You Have Feature-itis?”

  1. Thanks! I believe this blog was influenced by the question you were asked yesterday at the meeting of IASA.

    I agree that 4) might be the right answer in many situations. Actually, this might be the right business decision overall.

    The typical Israeli approach, though, will be to do 2.1.5. Here

    5. Spend 12+ hours a day, 6 days a week (thank G-d it’s Shabbat sometimes) to resolve the architecture debt without compromising feature velocity and in spite of 1. having been overruled by the PO.

  2. … and no, automated testing is IMHO not part of architectural debt, unless there are architectonic problems that prevent automated testing. And under the title of “automated testing” you probably do not include unit tests, which are responsibility of the developers, especially in TDD scenario.

  3. Jean-Philippe

    I am strangely confused by Alex replies.

    I do not know if you agree on the typical Israeli approach or not, but it goes against one of the principe of Agile : Agile Processes promote sustainable development. The title says it all and I humbly believe it is one of the key feature of Agile. You need to find yourself a way to develop an application of superior quality (which means tech debts has to be paid sometimes as well) by delivering the right business value for the PO in a sustained and sustainable pace. Unless Quality is not the Business concern and everyone is fine with it, a PO shouldn’t overlook this criteria (and even I wouldn’t recommend walking on that path).

    But to be back on topic, I think it can be branded as architectural debt IF, and only if, the reason why there’s a lack of automated testing is due to a wrong or badly developed architecture. Like if you have to work with some Legacy Code, back in the days where there was no notion of “Unit testable code” or so little of it. But if it was for a lack-of-time reason, it would definitely not be a Architectural Debt.

  4. I’m not sure I’d classify it as “architectural” debt but debt it certainly is. Lack of test automation, particularly at the unit test level, makes it really difficult to refactor with confidence and slows down development. I’ve seen this as a recurring problem on legacy projects where code isn’t adequately covered for a variety of reasons. Interestingly, one of the more common reasons is an architectural one – code isn’t architected in such a way as to allow easy testability. So sometimes the lack of automation is a smell of underlying architectural debt. However, IMO missing tests themselves don’t necessarily constitute architecture debt.

  5. Kevin’s comment about the fact that it may give out the smell of an underlying architectural debt seems fair enough. I rally to that.

  6. Hi Johanna, long time no see 😉 (entirely my fault!)

    In my humble opinion, your suggestion number 1 is in conflict with “complete transparency”, a quality that nowadays often is associated with agile methods even though it was not explicitly stated in the agile manifesto.*

    To me it sounds as if you advocate “a little less conversation” between development team and the demanding party with respect to the technical details – which seems to be in conflict with the second point.

    When in doubt I tend to go with option 2 although I think that option 1 should also be an automatism at higher abstraction level – but I think that option 1 looses validity if the demanding party gets closely involved in the day to day work since the architectural work becomes visible.(**)

    I’m not sure that I understood what your preferred approach would be?


    *(Oh, and – from my point of view – if the team doesn’t have the architectural skills at hand it’s either a question of qualification or an euphemism for politics – the latter in cases where the team has to convince some higher level authority to “sign off” their architecture)
    **(In my experience number 4 is really only sometimes the right answer – and sometimes disastrous)

    1. Michael, why is estimation, including the necessary architectural work a violation of complete transparency? Although I truly dislike comparing building software to building houses, we have external inspectors who insist that we build buildings to code. If I, as a customer, don’t want electrical outlets every 6 feet, or whatever that number is, I still have to have them, because it’s the building code. Why don’t we have the same level of craftsmanship/necessary engineering/whatever you want to call it as part of our estimation?

      I don’t think this violates transparency. I think it says, “Customer/PO, I am not going to let you bully me into producing something less than my best work.”

  7. Is the lack of automated tests architectural debt?
    In my opinion the lack of automated tests should be counted ad debt if the team pays interest for it.
    If it is architectural debt is quite another question.
    I support the point that missing unit tests are not “automated tests”, but a design tool.
    Overall I think that in my last couple of projects we summarized missing tests (on every level) as technical debt that might point to architectural debt (as Jean-Phillipe and Kevin also pointed out)


  8. Thank you for the clarification Johanna,

    I mistakenly understood that by “[…]your estimates include the necessary architectural work[…]” you where implying to communicate only the units (of effort as used in the team) required to complete a certain feature – including the architectural work in the estimation but explicitly not listing it.

    From what I understand now it comes down to the core value of courage, right?
    Stating the architectural needs and standing up to them. And off course trade off considerations with option 4.


    P.S.: About the power outlets:
    I my experience it is easier to stand up to a clearly defined code (any customer can understand “one outlet every feet”) than it is to stand up to architectural principles that are still under discussion even among specialist (e.g. trade offs between coupling and cohesion for certain scenarios).
    I think this lack of lack of a customer approachable code additionally makes it harder for teams to communicate the need for architectural (or technical) maintenance. Which imho leads back to option 2: Educate the customer.

  9. I work on a 10+ year old legacy system. Notions of testability didn’t exist in the organization at that time. Now we’re struggling to retrofit test automation. In this context I believe that yes, it is an architectural issue. If you want to mince words, test automation (infrastructure, etc) is architectural, whereas automated test cases are not. Our current dilemma is that we want the teams to produce automated test cases but nobody is stepping up to provide the test automation to make the cost of those test cases realistic.

    #3, tracking velocity to observe the cost of increasing technical debts is also problematic for legacy systems. The underlying assumption is that cummulative debts incurred during the sprints are a significant percentage of your overall debt. In legacy work, sprint debts are often small compared to the existing debt load.

  10. Pingback: links for 2011-06-23 | Michael Ong | On9 Systems

  11. Johanna, Very interesting! Too much focus on delivering features can lead to accumulation of technical debt. It is necessary to pay off technical debt at regular intervals. Building awareness among POs and other senior stakeholders about this is very critical!

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: