Slashdot Mirror
Is Process Killing the Software Industry?
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.'"
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.
I used to deplore meetings; listening to some preening jackass and thinking about how far we were getting behind by this. It isn't just the time sitting in the room, but depending on how bad it was, focus could be lost for the rest of the day.
Then I became freelance. Meetings took on a whole new significance. These jackasses paying my rate because I'm good at a few things; but rather than have me do those things, I'm sitting in a meeting, bored, but well paid.
Look at your contractors in the next meeting; if they aren't in the scapegoat chair, they are the only happy ones in the room.
I feel sorry for all you guys. I've worked in "no process" companies before and it sucks. No requirements, no process, no cohesion. Politics were rampant. It was just plain elementary.
These days I work in a company that's been CMMI level 3 certified for years and we have a process in place for each level of necessity; light, medium, heavy, manned-flight. All of our requirements are part of the contract, before any design even begins, and if they change the customer must pay for the change. It's a joy and my creativity is unleashed, not restrained.
Process is not your enemy. It's the lack of buyin. Everyone must participate and ensure the process is held. Requirements definition is part of process and if you don't have stable requirements, you aint got shit.
Again, I love working within our process, whether it's the light one or the manned-flight one. It's well defined and provides a schedule, but doesn't tell me how to write my design/code/test, just that I get it reviewed at all of the proper phases.