Slashdot Mirror

← Back to Stories (view on slashdot.org)

Is Process Killing the Software Industry?

Posted by timothy on from the about-those-tps-reports dept.

blackbearnh writes "We all know by now that Test Driven Development is a best practice. And so is having 100% of your code reviewed. And 70% unit test coverage. And keeping your CCN complexity numbers below 20. And doing pre-sprint grooming of stories. And a hundred other industry 'best practices' that in isolation seem like a great idea. But at the end of the day, how much time does it leave for developers to be innovative and creative? A piece on O'Reilly Radar argues that excessive process in software development is sucking the life out of passionate developers, all in the name of making sure that 'good code' gets written. 'The underlying feedback loop making this progressively worse is that passionate programmers write great code, but process kills passion. Disaffected programmers write poor code, and poor code makes management add more process in an attempt to "make" their programmers write good code. That just makes morale worse, and so on.'"

4 of 460 comments (clear)

  1. "Creative" by Anonymous Coward · · Score: 5, Insightful

    If you want to go off and do your own thing, fine. Have at it.

    But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

    1. Re:"Creative" by heathen_01 · · Score: 5, Insightful

      This is dead on. Every software-developing business needs to decide its own process needs.

      This is just another cargo cult problem. Managers, seeing that another company/team use process X on a successful project, decide to implement the same process for their team. However no process will make a difference if the developers have been directed to build the wrong solution in the first place, even if the code is 100% bug free.

  2. The one process to rule them all by Tribaal_ch · · Score: 5, Insightful

    Karma be damned, this is relevant to TFA:

  3. Re:Over my head by Derkec · · Score: 5, Informative

    70% Unit Coverage:
            -- You've written code level tests that flex 70% of your code checking for regression failures.

    CCN:
            -- Technical term you can look up, but basically it's a measure of how many decision points are in a block of code. Less decision points is simpler. Too many and you may have something difficult to test and difficult for a programmer to understand. Higher complexity generally means more risk and a higher need for testing of various types.

    Presprint grooming:
            -- A "sprint" is a time block set aside for development. Usually 2-8 weeks. The goal is declare what you're going to get done in that time and not change the requirements during that time. Between sprints, you can change your processes, "groom" stories (tasks that describe things in a user experience way generally).

    Test driven dev:
            -- When writing a new feature, right a test for that feature first and you're close to done when the test passes and you haven't broken other tests.