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.'"
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.
Only about 10% of programmers are "artistes" who create new things of beauty...process stifles those.
80% of programmers come to work more-or-less on time, sit where they are assigned, work using the tools and processes given, and produce most of an organizations output. Process is beneficial to those, in that it makes their work useful in the overall "whole."
10% of programmers should be fired before they do any more damage. A better HR process would help with those.
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.
The usual problem is bosses who either don't want you to follow a process, or they don't want to have to bother with the work that they would have to do.
How many times have you been told to forget updating the documentation or specs (or worse, "what documentation?"), or you're told to "just make it work"?
Or you've sat in a meeting during a review of the current project, and it's just a waste of time because it's like management is just filling up their buzzword bingo card by spouting various processes that could be used to improve things - and you should implement them and then tell them how (or if) they work. (as long as THEY don't need to be part of it beyond reading a half-page summary every once in a while)
Often, these are the same guys who will demand a 120-page report on the current state of the project "and it needs to be in my inbox in 48 hours" - and then "tl;dr" it.
In many cases, their reluctance to follow process is because it would show that they don't have the understanding to make a meaningful contribution to the process. If they don't tell you what to do, it's not their fault when the horse pucky gets into the HVAC. They'll blame you for not following their ad-hoc "management process."
Like the boss who dumps 3 different emergencies on you at the same time, and then gets all snarky because you didn't fill in the detailed spreadsheet of what you did every 10 minutes ... because now he can't use it to figure out how to fill in his time sheet of what he did all day, because he never keeps track of his time - just works it out backwards from yours.
Most developers would be more appreciative of processes if they weren't used as a weapon by the same management who refuses to adhere to sane processes themselves. For them, it's just CYA all the way down ...
Let's call it what it is, Anti-Social Media.
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?