A Few Signs That Your Project May Be In Some Serious Trouble

Posted by on 18 February 2013
  1. Lack of leadership in developer operations
  2. A lack of reporting of improvements in code reuse, coverage, test cases, and stability.
  3. Underutilization of frameworks and libraries used within the project.
  4. Lack of disposable runtime environments [for development and testing].
  5. Build times are unknown.
  6. Long and detailed documentation is required to build your product.
  7. Dead code is left in the code base to rot for years.
  8. Bugs are being reproduced as unit tests.
  9. Third Party dependencies are not being upgraded.
  10. Code is badly organized. Models are placed anywhere, packages aren’t organized, etc.
Related Posts Plugin for WordPress, Blogger...
Uncategorized, , , , , , , , , ,
  • Eric Hydrick

    I don’t know about the third party dependencies not being updated. We take a “if it ain’t broke, don’t fix it” to our third-party dependencies. Unless we need to upgrade to fix problems we’re having in our code or for security reasons, we try not to do it. 

    Depending on how your code is set up, upgrading to a dependency could be a high-risk affair that requires massive re-writes to (and a lot possible new bugs in) your codebase.

    • crash025

      That’s more of an issue that hints at maintenance being a regular thing. Technically you’re right. However bugs are fixed in third party dependencies as the time goes on. 

      Being stuck with a component that changes how they do things may leave you stuck with a bug or a security issue down the line and there would be nothing you could do about it. 

      Lets say for example: You use a large web component library that generates complex images of cats [SVG] amongst other things. Then one day the library is retooled to be much more generic. The interface for working with cats is gone, but you can put together the pieces with the library to do the same thing. You’re happy with the interface to the dependency and you don’t want to upgrade. Well the old code now allows for a privllege escalation technique. Which is worse? Fix it earlier through upgrades, or later and frantically try to upgrade or circumvent the issue down the line?

      • Eric Hydrick

        We upgrade 3rd-party components to fix bugs that occur in our workflow, or if there’s a major security problem that needs to be addressed. We just don’t upgrade simply because the library upgraded.

        • crash025

          Fair enough, however I suspect that minor updates are rare, unless you’re paying for support. 

      • Andrew Muraco

        Well there’s two types of updates (minor/fixes/improvements or major/breaking/changing) and many established projects are good at being distinctive about an update being minor or major. It’s hard to say that minor updates shouldn’t be regularly included (maybe not every single release, but often enough to be ‘current’)

        Major updates on the otherhand should be evaluated to see how much pain/change is involved and scheduled accordingly, including a migration to a different library if it ends up being a better use of time (more features/better performance)

Better Tag Cloud