Every Team needs a Goaltender

It’s been my experience that just like in sports where you have a goal tender, every development team needs a gate keeper or goal tender for their VCS to ensure nothing gets in that they don’t want.  The role of the gatekeeper in the team is not only to manage the promotion/demotion of DEV code to QA on through to PROD (production), but also to ensure the code meets syntax standards, and more importantly architectural standards or conventions.

Even if the standard way of doing things is less than optimal, consistency is king.  If a slower evolutionary method of evolving the code is not possible, at least with consistent code, you can transform it en masse at the beginning of a release cycle and dedicate a lot of QA time to ensure you didn’t break anything.  Developers who understand the “normal” way of doing things can maintain and write code comfortably, with confidence that it will work.

I have seen consultants brought in to author a new system and use it as an opportunity to play with new architecture and methodologies.  While they usually deliver the results, the code most often cannot be effectively supported by on-site developers because it is so radically different from what they know.  The same thing can happen on a team with developers at different skill levels, and different views on the latest design patterns and methodologies.

The important thing is that ‘there is no “I” in TEAM’.  Everyone needs to be able to understand and support all the code.  If an architectural pattern makes software harder to understand, then the benefits of using that pattern may be outweighed by the maintainability of the code by the team.  The team needs to decide as a whole on coding standards and practices.

One example of this is the heavy use of interfaces.  Interfaces are great for decoupling code, but at the same time it makes it harder to follow since the implementer of the interface is “disconnected”.  Using the Delphi IDE to navigate through code, by Ctrl+clicking in order to understand it, doesn’t work as it does with classes.  This isn’t a shortfall of the IDE.  There is simply no way it can know what objects are used to implement that interface (especially if you use injection).

The quality and maintainability of your code is directly related to the strength of the gatekeeper and the cohesion of the team.  Better teams build better code…

5 Responses to “Every Team needs a Goaltender”

  1. Stefan Glienke Says:

    “but at the same time it makes it harder to follow since the implementer of the interface is “disconnected”. Using the Delphi IDE to navigate through code, by Ctrl+clicking in order to understand it”

    IME this is only the case if the code is not designed properly. If you feel the need to jump into the implementation of some interface method there most often is something wrong (either design wise or the implementation has a bug). The second can be assured by proper unit testing of the implementations. The first one by following things like the SOLID principles (mostly the OCP and the LSP) because then it does not matter what the implementation does as long as its property working according to the API specs.

    Jumping through the code Ctrl+clicking from one place to another is really the workflow of someone that is used to hardcoded things everywhere (been there, done that)

  2. Larry Hengen Says:

    @Stefan,

    That is a good point. The code that prompted this post was completely undocumented both from an architectural point of view and there were no in-line comments. I was drilling through it and dropping breakpoints at strategic locations in order to trace it, as part of my code archaeology. Pretty bad considering it was new code that it was already “Legacy Code” as defined by Michael Feathers (no unit tests). I wish this situation was atypical.

  3. Marjan Says:

    “This isn’t a shortfall of the IDE. There is simply no way it can know what objects are used to implement that interface (especially if you use injection).”

    Yes it is.

    The IDE has the ability to know which classes implement the interface and could therefore bring up a list of these classes for you to select from. It could even limit the list by inspecting assignments to references of an interface that use a constructor on a class. And if there is only one implementing class in a project it could go straight to it.

    When you are debugging, the debugger _should_ most certainly know which class is behind the interface reference and send ctrl-click straight to the right code.

    The IDE could do a heck of a lot more to support SOLID development.

  4. Stefan Glienke Says:

    @Marjan:

    You are thinking only of a monolithic application. There the IDE might have the chance to present the available classes. If you are using different even dynamicalls loaded modules that won’t work. Putting any effort into such a feature would be just a waste of resources.

    During debugging iirc ctrl+click does not work at all. F7 will lead you there just fine. But that was not his issue but doing that while reading the code rather than tracing through the code.

    I agree that the IDE could do more to support SOLID jumping from abstractions to implementations is certainly none of them imo. Coding against abstractions is about NOT caring about the implementations. So as I said before if you find yourself trying to jump into interface method calls something else is wrong.

  5. Marjan Says:

    @Stefan

    No I am not thinking of a monolithic application. We have a projectgroup with 50+ projects. The IDE knows all projects if they are in a projectgroup, so even for non-monolithic applications it can do a lot more than it currently does.

    But hey, what should I expect of a tool that crashes every time I try to do a build all? That loses its marbles every time it encounters an IFDEF? That doesn’t know enough about project groups to give me the right project in the title bar when a unit appears in more than one and just happens to appear in a project before the active one? Want me to go on about how the Delphi IDE is not supporting developers like it should? Don’t worry, I won’t. Suffice it to say that I am not a happy camper.

    Whether Ctrl-Click works during debugging is IIRC dependent upon an IDE setting - off by default, but I may be wrong. It should work though. There is absolutely no reason why it shouldn’t.

    F7 will lead me there just fine? Who said I wanted to step into the code? I often don’t. I may just want to check that the instance behind the reference is of the right class.

    (Have you used the Visual Studio IDE lately? it’s not perfect either, no IDE is, but it does a heck of lot better job of supporting OO development than anything the Delphi IDE has to offer).

    And if coding against abstractions is about not caring about the implementations, coding against abstractions IS about caring about the contract for those abstractions. When faced with a lack of documentation (even if only unit tests) in that respect, where do you think might turn?

    Unfortunately, I live in an imperfect world. Working with a tool that only supports the “theoretically pure” use of its language constructs does tiddly squat to make my life easier.

Leave a Reply