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.'"
This is why I left development. After 5 years working at a software company I found that only 10% of my time or so was spent writing new code, which is the only thing I really liked about the job. The rest of the time was spent in meetings, wading through red tape, reviewing others' code, doing maintenance on the (junkpile) legacy system, doing remedial training for the front-line tech support staff, and the 5 million small tasks that have nothing to do with why I went into the career field.
Where I used to work, (I posted elsewhere here why I left development), part of the problem is that the attitude was always "another small task won't hurt engineering". "Another step in this process is not a big deal"... until there are so many of these tips and checks that you aren't doing anything else but these microtasks.
I think that most places have big problems going cheap on staff. They cheap out on testing staff. They cheap out on training for the support people. They cheap out on resources for environments. All of these things cause more weight to be placed on the developers.
And it's all by design... develppers are replaceable, in many companies' view - more are churned out of college annually and they only have a 2-5 year lifespan on average. Rather than expand budgets to reflect what development really should cost, they simply treat developers as disposable resources on a burnout/replace cycle.
My thoughts exactly.
I worked basically in the skunkworks for an ISP's call center. We developed the CMS that handled all of our policy and procedure documentation, we developed neat tools that interacted with our IVR for outages, displayed coverage maps with said outage data, and various little tools here and there.
When we started, we weren't bound by our IT department's change management process. As our tools grew and as their usefulness permeated our business, we started to get noticed and before we knew it, we were being held to the same standards for process as teams who developed tools like our CRM and our internal ticketing system.
The whole point of our skunkworks was to be nimble, efficient, and effective on smaller projects those teams didn't have the ability to take on due to commitment to other projects. Yet, as IT's demands for compliance grew, all of our advantages went away. Soon, i found myself having to answer, "Why is late?" and invariably the answer would be, "Oh, it's held up by IT's Process. It'll be three weeks." Managers weren't happy. I REALLY wasn't happy and stressed and my user base wasn't happy either(Although my user base had a certain degree more sympathy than management did).
It sucked the life and effectiveness out of our team.
When layoff time came a month ago, on paper, we looked like were banging rocks together, and bunch of us were laid off, with those teams that didn't have the time or resources to build these tools in the first place having to absorb yet more work.
(note: I didn't mind the particular IT policies, they made sense, but, I felt like a sense of scale was lost when it came to our projects. Oh well.)
Non impediti ratione cogitationus.
I've come to understand this. When I go to my boss for a performance raise, he evaluates me based on me compared to everyone under him. It is my advantage to have the 78%. When he sees this and he says that we need to break the company policy on raises over x% so we keep this great employee, his boss evaluates his request based on my bosses perspective of best one out of 62 rather than one of 11. It is my advantage to have the 78%. Not to mention that bigger groups need bigger funding, so when I need something to do my job I'll have a bigger funding pool to draw from.
I am disappointed too. I have lost count of the times that my coworkers (or direct reports) decided to skip documenting a design because of pressure to get the code done, only to have that come back and bite them (and the project manager who was applying the schedule pressure) later. Then there is one coworker who made commits to reindent and reformat every source file in a project -- mixing that with functional changes. Another coworker decided to write his own not-quite-XML parser.
I probably annoy my coworkers occasionally with my insistence that we define and follow certain (usually minimal) processes. I know there are one or two people who hate our code review system. However, I have never advocated for a new process unless it was meant to fix a recurring problem and I thought it was close to the most efficient way we could mitigate the problem.
80% code coverage costing less than 10% development time? Only if you're either ignoring all errors, or have massive try catch blocks that catch everything generically (which means your code coverage numbers are garbage- if you aren't testing each way of generating each type of error, you only have a fraction of that coverage).
I'm not going to deny the usefulness of unit tests, but in my experience writing a good unit test suite takes 50-200% of the time to code the function, depending on the complexity of the code being tested.
I still have more fans than freaks. WTF is wrong with you people?