Slashdot Mirror
Avoiding Mistakes Can Be a Huge Mistake
theodp writes "No doubt many will nod knowingly as they read Paul Graham's The Other Half of 'Artists Ship', which delves into the downside of procedures developed by Big Companies to protect themselves against mistakes. Because every check you put on your programmers has a cost, Graham warns: 'And just as the greatest danger of being hard to sell to is not that you overpay but that the best suppliers won't even sell to you, the greatest danger of applying too many checks to your programmers is not that you'll make them unproductive, but that good programmers won't even want to work for you.' Sound familiar, anyone?"
Obviously you can't go too much in the other direction either. The checks are there for people who write code seen on http://www.thedailywtf.com/ who actually click the flashing banner that says they've just won lots, and for those who open up the .exe they found in the email that contains 'instructions on how to get a bigger pen15 2day'.
It's like anything else in life. The sins of one hurt everyone.
There will always be people who get shampoo in their eyes, and because of that these checks will always exist.
From the article:
So bureaucracy has a cost in that it places lots of checks on things, and the solution to that is adding more checks?
Sounds like solid bureaucracy to me!
Overclockers
At big companies, software has to go through various approvals before it can be launched. And the cost of doing this can be enormousâ"in fact, discontinuous. I was talking recently to a group of three programmers whose startup had been acquired a few years before by a big company. When they'd been independent, they could release changes instantly. Now, they said, the absolute fastest they could get code released on the production servers was two weeks.
At the big company I worked at, someone added some features to code that I wrote. It broke my code. I wanted to go in and fix it. Why not? I knew how it worked. I couldn't without a defect written by a tester.
On the other hand, if it was reviewed, the feature wouldn't have gone in; at least not without my input - I would hope.
Code reviews teach the reviewers as much as they check on the author. Why would you deny the lesser programmers the joy and experience of looking at good code?
I find the premise of the essay wrong. Go read "Death March" by Ed Yourdon (http://www.yourdonreport.com/). Most of the time problems aren't processes - they're people.
"Programmers, though, like it better when they write more code. Or more precisely, when they release more code. Programmers like to make a difference. Good ones, anyway."
This is a red flag. Coders that just code are part of the problem of a death March. Who has worked with wunderkind that churns out 16 hours of useless bug ridden code? That refuses to write unit tests because they slow him down? And at the end of the project look back, the MetricsReloaded tells you "Yes, that developer wrote the most code, but it is also the most defective and has the least coverage?"
Good processes are adaptive. Good people are agile. You can't build skyscrapers on spec. I am so annoyed by people that push a methodology or ideology that cannot also cite the specific historical evolution of software processes.
/\/\icro/\/\uncher
Anyone else pick up on this -
Programmers are unlike many types of workers in that the best ones actually prefer to work hard. This doesn't seem to be the case in most types of work. When I worked in fast food, we didn't prefer the busy times. And when I used to mow lawns, I definitely didn't prefer it when the grass was long after a week of rain.
Just because YOU didn't like being busy at your other jobs doesn't mean everyone else in the world feels the same way. I worked in fast food and when I did, I liked it a lot better when it was busy. A 10 hour shift flies by when you're making orders non-stop, but once closing time came and it was time to clean up time seemed to stand still. I was still working but the work I was doing was so mundane and slow paced (mopping floors or washing the nights dishes) that it seemed to take forever.
There's also the possibility that you're a hobby programmer and not a career programmer. You might like programming outside of work, but there are people that wrote code just because it'll pay the bills. Those people generally like writing code as much as you liked mowing long grass.
Yeah, I'm pretty sure the best programmers are those geniuses who make lots of mistakes and then throw hissy fits when management creates procedures to find and fix those mistakes. Now that I've I know, I'm going to dismantle all my QA procedures and hire the sloppiest programmers I can find!
To wit:
Excellence can be determined in various ways, often through documentation, the great allergen of programmers. If you can't explain it, it isn't really done.
The benchmarks can also be defined as well. They need to be met. Make the bars well known, and what must be done to meet them.
There are great references for auditors, too. Feeling a little pain, are you? Had to throw in the grammar nazi reference?
---- Teach Peace. It's Cheaper Than War.
What I don't want is:
- To be reprimanded for every little mistake I make, or worse be put in a position where a little mistake on my part can cause a huge, expensive and/or very visible problem
- To be forced to comply with procedures that do not in fact improve quality but do require 90% of my time leaving me with 10% time to program
- To have no creative input into my code.
There are good ways to achieve similar goals without the above antics. Continuous integration comes to mind. Well qualified specialist testers for User Acceptance is good too. Avoiding mistakes in a way that is programmer friendly will actually improve morale and an employer more desirable. The trouble is that too many employers try to equate software manufacture with mass production factory work in every way and treat their programmers accordingly. If you look at the kind of work a programmer enjoys vs the kind a factory worker is expected to do, no wonder they leave or won't join.
These posts express my own personal views, not those of my employer
Perhaps programmers that have consistently good code should have some value placed on them. We'll call it "Karma". Programmers with good Karma get audited less often than others. If they fail an audit, they loose some "Karma" and have to write a bunch of excellent code to get it back.
That's awful in so many ways.
For starters look at how poorly Karma works here. It serves to re-enforce awful sheep mentality. Just try putting down Google, Apple or Linux. Or try praising Microsoft.
Next what you're proposing creates a negative feedback loop. A developer codes well and gets through a few audits. Now they're trusted, they can afford to let things slip for some time before anything is caught. There's less incentive to keep producing good code, and there's more of a chance that an error will slip through. No one is perfect and mistakes will happen. The way to protect against them is to ensure there's some redundancy, and taht is exactly what a code review provides.
Also consider retention rates and the average time a developer spends at a company. Does an expert or lead programmer start off having every little thing reviewed? Who's qualified to do that? Or are they trusted based on heresay and a resume? If so how long will it take to find a dud programmer?
Next consider what effect it will have on the morale of a struggling programmer, or one that doesn't cope well with reviews. Especially a junior one whose abilities can be salvaged. A co-operative might work, but constantly giving more and more high pressure code reviews is just about guaranteed to break such an individual.
Finally, you should realize that such "karma" already exists informally and that making it a more formal process achieves very little. In other words developers very quickly get a feel for what the strengths and weaknesses of another developer are.
These posts express my own personal views, not those of my employer
I've worked for both types of companies and I can say that the more 'checks' to prevent mistakes the more ossified the code becomes. Sometimes big mistakes lead to a breakthrough in understanding the problem. It often seems that slow release-to-server cycles inhibit the ability of programmers to learn from their mistakes.
Today is an ephemeron, doomed to the crypt of yesterday.
Code reviews teach the reviewers as much as they check on the author. Why would you deny the lesser programmers the joy and experience of looking at good code?
I completely agree with this. Also, reviewers get to see code they may not be familiar with, and the author gets alternative views on implementation and design.
As long as everyone remains objective and professional, reviews can be very informative.
Benchmarking is exactly were the problem lies....
Having your code reviewed by a peer who can actually comment on it and understand what you are (or are not) doing is not bad. Either they understand it, or you have to defend your work with actual technical arguments. The end result is that you both have an opportunity to learn.
Having your code reviewed by a mindless idiot comparing it to the official procedure is bad.... Even worse when the idiot is replaced by a program. Forcing everybody to follow a single holy procedure simply reduces all code to be mediocre.
Secure messaging: http://quickmsg.vreeken.net/
(mount soapbox) Having every little thing reviewed is a necessity, not a problem. Expert and lead programmers need to set the example by getting reviews. Always. The tiniest change has the potential for causing chaos. Teaching by example is just as important as producing. (dismount soapbox)
Ultimately, what you're talking about is managed incompetence, and proper identification and utilization of real talent. Most organizations do well enough at the former, and are just terrible at the latter.
The higher the technology, the sharper that two-edged sword.
The time for that was what I missed on my last job. While there was not much oversight of how we actually wrote our code, deadline pressure always created a feeling of "you cannot afford taking that time just NOW".
The ultimate downer was when there was a gap between projects, one release had just been shipped and management hadn't made its mind up about what features to put into the next version. But even then there was no "business justification" for rewriting old crappy code. Instead we ended up writing some middleware for third party closed source software to make management's life easier. IMHO a complete waste of time.
In hindsight, that was a lot more motivation destroying than the development process as such.
C - the footgun of programming languages
Excellence can be determined in various ways, often through documentation, the great allergen of programmers. If you can't explain it, it isn't really done.
Suppose you have a programmer who's 10x as fast as your benchmark standard guy at producing tested, debugged code that meets requirements, but slower at writing docs. Do you make him write docs, or attach a junior programmer to him for that purpose?
Of course, somewhere up the ladder a software engineer's job becomes mostly writing docs (regardless of whether you go management or architect), but still - tying that anchor around the neck of your best dev is exactly the sort of thing Paul Graham was on about.
Socialism: a lie told by totalitarians and believed by fools.
The problem is that what you are describing is nothing at all like what the market actually wants. The market actually wants massive feature lists delivered as fast as possible, and their level of caring for whether or not quality is there is very low. This is very unlike, say, a bridge, where the primary public concern is going to be that the bridge not fail and kill them. Or an electrical product where the primary public concern is that it not short out and start a fire that kills them.
When things go wrong in other fields of engineering, it can frequently kill you. In most software engineering, not so much, and in the areas where it CAN kill you (think airplane fly by wire control software), you should be unsurprised to find out that many of the quality and testing standards are quite the same as in other fields.
Most software engineering is more like movie publishing. The audience quickly gets satiated, and is mostly looking to the next great thing with better FX, and not so much caring if you have a few flaws in your plot (see recent Batman movie if you are unclear on this).
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
I don't think you're disagreeing with me. Given whatever standard of quality you wish, there is at least a 10 to 1 productivity variance in the creation of software between software professionals. Identifying developers who are on the tail end of that bell curve and removing obstacles from their path is the key to both productivity and retaining your super-programmers.
The guys on the 10x end of the spectrum aren't just more productive - they can solve problems that the ordinary coder simply cannot solve at all. If you're part of the millionth re-invention of an inventory database, this doesn't much matter, but if your business sells software that soves new problems, these guys make a huge difference.
Of course, everyone thinks they're a super-coder when they're young, just like everyone thinks they're an above-average driver, but recognizing (and retaining) real talent is supposed to be a development manager's job.
Socialism: a lie told by totalitarians and believed by fools.
Exactly, what made your company interesting and worth buying was what you DELIVERED! At this point you've missed 8 "releases" spending the entire time essentially rebuilding and re-documenting according to "old and slow" rules. Because of the overwhelming paperwork, your division is now a "loss".
While you needed more structure, your new owners sacrificed ALL your productivity for writing reports!!! They made no money from buying you.. worst is that your employees probably lost the creativity that make the whole thing worth buying in the first place.
The best judge of good code is always other programmers. I also think that once you move into management for a few years, you start to lose the ability to tell good code, because there really is an element of the "best application of current technology" somewhere in there.
The worst place to work would be a place where nobody ever looked at or judged your code. That's like an author with no audience.
"I have never let my schooling interfere with my education." - Mark Twain
We would disagree.
Unless a code set is monolithic, it has to interact with other components. Maintenance and audit mandates basic documentation. Those that eschew it aren't really programmers, because that's part of the job. Instead, they're really good artists, creative people, and not industrial professionals that understand they're part of a larger process. Part of the lone wolf contingent of coders and hackers will always refuse to be a part of the discipline required to work and play well with others. It's been this way since I started using computers 42 years ago. It hasn't changed. Corporate excellence? No, 'plays well with others'. Doing that requires submission to the processes needed by others and being both courageous and disciplined enough to do so.
Playing the machine can be done in many ways. Some of them are safe and sane, others edgy, and clearly, some stupid. You have to demonstrate the difference and be willing to submit to scrutinize your code. Otherwise, in a way, you're like how Microsoft used to be-- ranging from the sloppiest rush jobs ever written to fabulous code with no method to judge the underlying difference until the object blew to pieces. Fie.
---- Teach Peace. It's Cheaper Than War.
Documentation may be necessary; certainly documenting interfaces is, and some amount of internals documentation is prudent. But no amount of documentation will make poor code anything but poor. Nor will any lack of documentation make excellent code poor; it merely makes it undocumented.
Courageous submission... wasn't that one of the Ingsoc slogans?
"The Other Half of 'Artists Ship'" presumes that large organizations are motivated by efficiency and effectiveness. This presumption completely misunderstands large organizations. Large organizations come to exist because they have tapped into a large reliable long-term cash stream that can survive their collective incompetence. With their organizational funding assured, all that is left to do is to divy up the organizational spoils amongst the employees, management, and shareholders. And then the key determinant success in such an organization becomes not to be blamed for making a mistake. No employee will get blamed for inadvertently excluding a superior vendor from an acquisition process; most likely no one in his/her organization will even know it happened. They can get blamed for having too lax an acquisition process, however. No employee will be blamed for having too much testing or too much project management or too many software quality checks. They can get blamed for releasing defective software onto a production system without sufficient checks. So the internal goals of the organizational actors are perfectly reflected in the external behavior of the organization. More checks means less blame for mistakes; fewer checks means more blame. With the organizational cash stream assured, less blame means more promotions and greater compensation.
"You can engineer maintainability. You won't know how successful that effort was until after the maintenance is performed."
You can certainly try your best, but as you say, you only find out later how you did. But getting back to the main argument, programming "goodness" is a multidimensional quality that often can't be fully measured until some time has passed.
There is rarely any attempt to measure it in the real world beyond the misleading metric of LOC/time.
If 3x developers are common, then what is the baseline you are comparing them against ? The very worst programmers ?
So, since the baseline seems to be less than zero, and the best developers are three times that, are you trying to say that the most productive developers produce enormous piles of crap ?-)
But seriously, unless you can quantify productivity numerically in an objective fashion, saying someone is "three times" or "ten times" as productive as someone else is 0.961x as meaningless as "devolved systemic projection".
Yes. Specifically, real engineers and their companies get hauled to court if the product they designed blows up in the user's face. Software engineers don't; they and their company get paid more to help the users deal with the errors they made - this is known as "support".
Just a little bit cynical here ;(...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
"Common" as in: "you've probably met one". When you can't measure something well, you can still measure it a little - a half order of magnitude isn't exactly overspecifying. However, when when you know you can give a team of 5 engineers N days, or your good programmer N days, and get the feature delivered on time, that's a pretty good basis for comparison!
There are plenty of software development jobs (even outside of life safety) where there's no room for serious errors. Sure, GUIs can be poorly designed and crash, and some CRUD programming has room for mistakes (or at least crashes), but any time you're handling customer data you don't really have any room for corrupting that - MySQL jokes aside.
Socialism: a lie told by totalitarians and believed by fools.
And I think the lesson is: The developer who cares is much, much more valuable than the developer that doesn't. So if your company is not inspiring your developers to care, you're going to hit a brick wall.
Maybe your "docs" isn't the same thing as his "documentation". The former sounds much like "write a MS Word document full of boilerplate crap just to make the process people happy, not to actually be helpful to anyone". I think a useful guideline is: if you can delegate the documentation, it's not worth doing.