Net Objectives

Net Objectives

Friday, March 2, 2012


Download the Podcast Part 1
Download the Podcast Part 2



The word acceptance is used in a wide sense here:

  • The developers accept the responsibility for implementing the system
  • The testers accept the responsibility for testing the system




Requirements from the customer



  • Stakeholders
  • End users, of different types
  • Operators
  • Administrators (DB, network, user, storage)
  • Support (field, customer, technical)
  • Sales, marketing, legal, training
  • etc...



In other words, when we do maintenance to the system.

Maintainability is a requirement









TDD is developer-facing ATDD





  1. Okay. I definitely agree with the fundamental tenet that unit test driven development is a way for developers to enforce their standards and ensure a product stays maintainable going forward. I'm going to challenge the "requirement" thing just because... well... because that's what I do.

    I think that, given current trends, putting maintainability up on the requirement pedestal actually may cut away from your goal rather than toward it. The way most people see requirements right now is as things that are weighed against other requirements. You can choose to have this requirement now or that one, then you can have the other one usually after you finish the one on which you choose do to first.

    That's not how maintainability works. Getting it back once you choose not to have it in the first place comes at great expense so we don't ever want to give someone the chance to choose against it.

    Acceptance criteria for a "real" requirement, however work exactly as you describe. The product people can choose whether or not to create a piece of value for the end users of a product but they cannot have it unless the implementation satisfies the legal people, the user experience people, the operations people, and the people who are going to have to maintain the code.

    Note that this is really very consistent with what you said in this post with the only difference being the label that gets applied to maintainability.

  2. I will let Scott chime in as well, but I feel that the sorry state of software development nowadays stems exactly from the attitude that maintainability is not a requirement.

    All requirements are statements of change -- "I want to change X in my system so that I will benefit thusly..."
    When it comes to maintainability the statement is "I want to change the design of the system after I have made all functional changes in it so that I will be able to make the next changes just as easily and safely."

    The developer's work is not complete unless he address this "silent requirement." It is not optional. It is REQUIRED.

  3. Looking forward to read the specific part, especially your take on sustainability of TDD vs sustainability of ATDD (if you plan to cover it). From my amateur point of view, this is a little different, because in case of TDD, I want to attain sustainability by proper encapsulation and introducing "seams" to let me break dependencies. On the other hand, in ATDD (especially in tools using cucumber or other such language) the focus is on step reuse and encapsulating each step as reusable part of code (because I will end up performing some steps in almost every acceptance test), whereas in developer TDD, I want to limit it as much as possible (i.e. when I think about creating new helper method or using Setups, the first question I ask myself is "am I not trying to encapsulate in testing code what I failed to encapsulate properly in production code?" and only if the answer is yes, I would go and create this helper).

  4. I think Max's point was that *other* things we call "requirements" can be de-prioritized and may even be eliminated if the customer decides they are not worth doing, but that maintainability must never be left out. Therefore, the term "requirement" may not be *strong* enough for maintainability. In other words, I think he is saying what you (Amir) are saying, that maintainability is truly required whereas other things we call requirements may come and go. Is that what you meant, Max?

  5. By not treating it as a requirement it moves into the world of the "stuff that the developers do that we don't quite understand but they probably do because they like to play with the system rather than do real work."

    On the contrary - it is a non-negotiable requirement. A *REAL* requirement, as in the adjective - REQUIRED.

  6. My point was that I think Max and you are like minded in saying maintainability is not optional.

  7. Thanks for the post, and I am excited about your podcast versions -- but the iTunes link isnt working for me (says it's not available in the US), and it'd be ideal to just have an RSS/ATOM feed just for the podcasts. Would this be possible? Thanks!

  8. You can download the podcasts directly from us, by clicking on the "podcasts" tab above, then right click/save-as any of the 'casts you want...

  9. Except (Oops) we don't have this podcast up yet. Jim Trott is still producing it. Stay tuned!

  10. Question I have....
    If maintainability is a requirement, how do you demonstrate you product covers and fulfill this requirement?
    Above all when you have a 1st initial release/version.

    I mean, you can know if the product you developed can cover/or not maintainability aspects after several releases/versions but I would like to know how do you demonstrate it contains that property (maintainability) in the very first initial release?

    On the other hand, a product can be very maintainable in some modules/use cases/scenarios while in other scenarios can be very difficult, or perhaps the effort to completely cover the acceptance of new capabilities/functions by the customer can be very large even if yo feel or perceive the code you wrote is well designed, so in that case how can you decide or judge if that module (or product) covers well the maintainability requirement? by just looking at the effort required to change a piece of code?

  11. Maintainability is all about dealing with change. If we encapsulate the change, then the rest of our system will not be affected by it. We can achieve maintainability by anticipating all possible changes to our code and created the ultimate encapsulation. This, however is an unlikely endeavor as there is ALWAYS something new to change.
    So the maintainability of code depends on two things:
    1. The current design
    2. Our skill in modifying that design to accommodate new change.

    The ease with which we modify the extant design to accommodate new change (aka Emergent Design) relates to the clarity and appropriateness of the existing design.

    So, given a design, how do we know it is implemented correctly - that is, that every class and method is doing what it was supposed to do? And after writing the code, how can we understand what the classes are doing, so that we can change where change is called for?

    The answer - TDD. When you are writing the 'tests' first, you are in fact documenting what each entity in your design is supposed to do, which is what we are expanding on in this blog.

  12. When you are adding the podcasts into the blog posts RSS feed, could you please add the podcasts as an "enclosure", instead of just an html link?

    This will allow Android podcast players such as BeyondPod to recognize and download the podcasts for offline listening.

    See this forum post for a brief explanation:

    For a good example see:


    For a bad example see:


    View the XML source to see the difference.

    (if Jim and Alan can add "enclosure" podcasts back into their new feed too, that would also be nice).


    1. We'll look into it, Chris. Thanks for the suggestion.

    2. Chris:

      From what I can tell, Blogger does generate the sort of feed you're looking for. Have you tried pointing BeyondPod to:

      The first is an Atom feed (RSS 1.0) whereas the second is RSS 2.0.

      Let me know if this helps, or if I am still missing the point. :)

    3. Scott,

      Nope, the current Blogger atom and rss feeds don't appear to work.

      There used to be a setting in Blogger to turn on link fields and then to include an enclosure link, but that may have been removed as part of recent redesign "improvements"

      Could you try to set up a feedburner feed with smartcast and see if it will wrap the appropriate link with an enclosure tag so that other non-iTunes podcatchers will work?

      You may also need to create a separate blog entry if you have multiple parts to the podcast, as most podcatchers tend to only grab the first one from a feed entry.


    4. We also have a feedburner feed:

      Perhaps this has the proper enclosures? It is how we end up on iTunes.