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.'"
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.
I'm all-too-aware of this issue and how quickly it sucks the life out of you and prevents anything from getting done, but at the same time obviously having no process doesn't lead to stellar code either. My question is, do any of you work in a place where you think you've struck the right balance? What are you doing?
Dislike the Electoral College? Lobby your state to join the National Popular Vote Interstate Compact.
Karma be damned, this is relevant to TFA:
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.
I think may be the guru-disciple system of education practiced (allegedly) in ancient India might bear better fruits. Guru lead teams with disciples learning from them might turn out better quality code, but the system would be expensive in the short run and takes a while to take root. The quarterly bottom line obsessed corporate world is as far away from the system of stoic ascetic guru living in a hut in a jungle accepting princes as students romanticized in Indian mythology.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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.
The main issue is that measuring whether code is good or not is impossible. I promise you that I can write code that has the prescribed level of unit testing and complexity that also doesn't work. Software reliability/dependability was a problem in the 1960s. It's still a problem today. No silver bullet, and all that.
This is really the key insight of most Agile methodologies. Development should own the process and change it to suit their needs during regular retrospectives. The team (not the whining individual) should be able to say, "You know what, I think we're not getting bang for our buck out of this many unit tests, let's shift to 50% coverage." As long as that same team is taking ownership of the regression failures and making an informed trade-off their comfortable with, all is well.
If you get a good team together, you're going to get good code. You'll get better code if you empower them. Experienced and good teams will usually have a lot of these processes and tools in place because noticing things like high code complexity automagically alerts them to "bad smells" that can be examined and either accepted as necessary or invested in to address or test more thouroughly.
Generally, I think development is most fun when you're on a new project and don't give a damn about breaking things. Then it's pure creation. But once an app is older and there's some weird code you're staring at you have to decide, "is this probably a bug, or is this a bug fix for some weird situation or platform?" That's when you wish that the guy having fun three years ago had written some damn tests.
your comment is mostly wrong.
Only about 2% of programmers in a large company actually do most of the real work.
20% are good for chit chat.
78% should be fired immediately.
You can't handle the truth.
the problem is always the same:
how can manager get bonus lowering staff costs?
they get cheapo developers and throw the top notch methodologies at them in the hope those will make up for the devs inexperience and plain incompetence.
that gives in turn a bad name at methodologies and tools, because cheapo devs cannot understand nor benefit fully from them. what use is a pmd output to a guy who's never got the difference between passing by reference and passing by value?
and there are, lots of them. just check any java forum.
yet, the truth is that some of the methods and tools are a good helper for good and also top notch developers. if you work with the tools, and not by the tools, you can catch way more common errors, be notified of piece of code that may need some attention because grew too much in scope and features and lot of other small things that make your life easier.
but it has to be a cereful choice, based on your experience and knowledge, not something imposed because it's the last buzzword.
In most engineering disciplines, the process of actually building something is long, hard, expensive, and persistent. If the project is build a bridge, you spend a lot of time making sure the design is right; why? because the process of actually building the bridge takes months or years, costs many millions of dollars, and once built is not easily replaced. There is no room for error, so process is taken very seriously as a central part of ensuring timely cost-effective correctness.
In software, the process of actually building something is instant, easy, free, and transient. Type "make all" and go get some coffee; find a bug? tweak a couple lines and do it again. This distorts the development process; "process" gets snubbed as a costly distracting annoyance instead of the means of assuring that what gets delivered is correct, because it's just so dang easy to fix and rebuild in seconds ... losing sight of the long-term cost of not doing it right the first time.
Can we get a "-1 Wrong" moderation option?
TDD is a painful waste of time that at best serves as a crutch for unskilled or insecure coders and at worst a smokescreen behind which serious bugs remain unfixed because they aren't picked up by any test cases.
No, TDD is painful, but it's a long-term investment. If you code once and never have to touch it again, you can get away with making it work right without tests. But if you want to be able to grow your system, you want something to make sure that you don't kill the old functionality in the process of building the new. And sometimes it's just helpful to spell out the expectations of new functionality ahead of time so that you know when you've achieved it.
Process for the sake of process is pointless. And if you have good reason to work around or jettison a given process, go for it. As I told the other programmers at my job, the only piece of our process we would probably consider an absolute necessity is source control. Code review is highly recommended, tests are very strongly pushed, formatting standards are there for good reasons, but there are times when they are not helpful.
The problem always comes down to whether or not your developers are adults with good decision-making capabilities. Process is too often employed as a way to allow you to get stuff done with people of average or less ability, but process also hurts them because they can't figure out when the process is unhelpful. And if process is imposed by fiat, those who could figure that out are frustrated by having to go through the motions. But if you have trustworthy people and you actually trust them, you institute the process for their benefit, and when it's not useful they know not to use it.
I firmly disagree. Passion is key. People who don't give a damn and people who don't enjoy coding tend to write crap. We try to hire for passion and smarts (knowing both are hard to interview for).
Passionate people given good processes and tools are ideal.
My problem with process has always been budget. Folks higher up budget on the basis of minimal process and expect full process. If you want 70% unit-test coverage, that is twice the time the code would have taken if you did not write unit test. Add 3 times the time if you want good integration tests to go with it.
Unfortunately, this makes a project costly. The problem occurs if the PM then demands full process when the time is not accordingly budgeted for it.
Release cycles also become long.
And if you kill the passion, your cost (of hiring new developers because you drove the old ones away) and risk (of losing corporate knowledge in process) increases. So you can say "my money, my rules" all you like, but actually, it's reality that dictates the rules. And reality says if you burden people under a weight of bureaucracy disproportionate to what that bureaucracy is intended to accomplish, they'll leave. And if they don't leave, they're probably afraid of not finding another job, indicating that they're not good enough at their job to be confident in their abilities.
Like pretty much everything, it's a balancing act. You need to provide direction, or the goose is going to go wandering around the yard instead of laying its damn eggs, but if you stifle it too much, the thing's going to croak.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
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 work in engineering, not software, still, the last time I encountered a passionate IT employee, he got fired for taking long, passionate lunches at the hotel down the street with an electrical engineer and fixing their timesheets to cover up their absence.
On a more serious note, you don't have to choose between passion and apathy. I'll take conscientiousness over passion any work day. Passion can at times be dangerous to objective thinking, partner relations, or a professional standard of care.