Another excuse to stay up until 3 AM.

10 Myths of “Brownfield” Development

This presentation about 10 myths of “brownfield” development by Josh Graham of ThoughtWorks seemed very relevant to me, considering how often we find ourselves working with legacy code as developers. It’s well worth taking a look at:

http://www.infoq.com/presentations/Brownfield-Software

Here are the 10 myths with my brief notes:

  1. Brownfield development sux – greenfield development is teh awesum
    With proper resources and sufficient support, great opportunity for renewal.

  2. An OO implementation is slower than a procedural one
    Not with proper domain modeling.

  3. It needs a complete rewrite to scale 100-fold
    Proper domain modeling -> a smaller, manageable object graph -> less need to hit the DB, with immutable value objects enabling safe concurrency and parallelism.

  4. It needs a complete rewrite to perform 99% faster
    Performance testing, business activity monitoring, profiling, etc. make this easier. They leveraged AOP to implement monitoring.

  5. An XP team can’t work concomitantly on the code with Waterfallers
    Good communication between teams enabled teams to work together well.

  6. You can’t complete in 10 months with a team of 10 what a team of 20 can’t complete in 20 months
    In fact, fewer developers meant greatly reduced overhead, greater agility, and greater speed.

  7. This 10-year-old pile of JaBOL won’t be winning any awards
    I.e., Java written procedurally, like Cobol. In fact, the software in question was an extremely successful product, and worth working on.

  8. Those outsourced developers will never get “the Agile”
    Even developers used to “bug-driven development” can be brought into the fold with pairing, TDD, etc., and the relief experienced by dealing with well-crafted code.

  9. DBAs won’t work with the developers to evolve the database
    Devs being proactive in aiding the DBAs mitigates this: pairing with DBAs to refactor the database, helping to write migration scripts, etc.

  10. Architects don’t code
    If the implementation isn’t matching the architecture, then the architecture is of no use. Architects’ involvement in implementation gives them the feedback they need to know that their ideas are actually valid and working.

One Response

  1. Awesome write, I will be viewing back frequent to watch out for posts.

    April 5th, 2011 at 1:43 PM

Leave a Reply to Josef Cancel reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">