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?"
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.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
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.
If your company writes great software, I want to work for you. I don't care how you do it. I want to write great software and if you have found the way, teach me.
From TFA: "Programmers are unlike many types of workers in that the best ones actually prefer to work hard."
Thanks for telling me I suck, Paul. Now excuse me while I loaf.
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.
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!
So, do you write perfect code, which takes too long and is too expensive? Or do you write quick and dirty code, and let it blow up in somebody else's face a few years down the road? Or do you write it just right? Working in a highly regulated complex industry, the rare blow up is very very bad. We work hard to avoid them. On the other hand, there are a few quick and dirty things that I write because I know that I will be able to toss them soon. I think the question that you need to ask the end user first - what do you need. Having read the author for quite some time, I expect he would disagree. I think he would go quick and dirty. But then again, he thinks like a start up. They are smaller. And when things blow up it is less important, affecting only a few people and a few bucks.
Where I work, the Network Nazis have made our computing environment so secure from cyber-threats that we might as well just unplug our CAT-5 cables altogether.
My group is a prime example. We all worked for a startup that generally released a new version of our application about 3 times per year. Over a few years we had developed a nice lean development process that involved documenting our design, but only in enough detail to be able to fairly accurately estimate the development effort (in X days, X weeks, or X months).
Based on the estimates, the biz dev group would then pick and choose features to make up 3 months dev + test time.
This worked great, and we pretty much never had a late shipment and few bugs.
Then we got acquired by a giant 3-letter company with huge amounts of development process and tons and tons of "standards", and immediately were ordered to begin a 16 month release consisting of removing all open source and complying with standards. All their architects routinely veto our decisions and our design documents must be very very detailed and approved via heavyweight process before implementation can begin. 24 months later we're still in development, only recently the last design document was finally approved; at the moment it seems we'll be about 12 months late in total.
Now they're asking us why we have so many tests planned, and making us remove half of them. Supposedly quality is a major priority, but they have no testing group; only people to enforce standards. All tests and test cases are written and implemented by the developers themselves.
Dont even get me started about the outsourcing issues.
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
This keeps coming up in various shapes and forms but the fact of the matter is that brilliant, high producers aggregate in places; and so do idiots.
Tom DeMarco ran a study of this in the 80s wherein teams were asked to solve the same problem. He expected a scatter-plot. It was a 45 degree line between the people who knocked the problem off and those who were clueless.
What didn't matter:
Platform. Language (except assembler, those folks were _lost_.) Operating System.
What did matter:
Team coherence and capability.
Design and planning; raw ability to design and plan as a coherent team. And not just a bunch of losers following a Pythonesque "Book of Common Knowledge."
(I have been to many "Does the witch weigh less than wood" meetings...)
Look at the back cover of Boehm's "Software Engineering Economics." What he _measured_ was that team capability overarchs everything. Period.
I would also ask you to look at the surface exposure of development. Folks who develop on the shoulders of many giants can and should be trying lots of stuff, because that's why platforms are built.
Folks working closer to the core (the OS, drivers, fundamental code) don't change as quickly, nor should they.
I've worked as a hatmaker (sheer, unbridled creativity with fancy ribbons and flowers and such) for high-end ladies and I've sat, confounded by bad documentation for UARTS.
Two different regimes.
You know, I often find that the coolest and most brilliant snippets of code come from momentary flashes of genius (or insanity). Working with more restraints really does squash creativity in the way things are done. Different people have different agendas, and a committee who doesn't see the brilliance in one person's work can throw it out altogether or ruin it completely by trying to do things with it other than were originally intended.
This story hits very close to home for myself -- I've sold two companies to larger companies where they commercialized my software. When you're a scrappy startup, you ship instantly. When you get incorporated into a larger organization, you don't ship instantly, which hurts because your intrinsic motivation (for the A-listers and entrepreneurs anyway) is shipping.
One shocking thing in the article for me is just how much people would give up in order to ship faster -- startups that got acquired would give up some of the acquisition money in order to ship faster in the new company. It's probably a limited sample, but I know I've felt that way. This is a large portion of what I call "suck" -- things that slow down shipping. I'm not anti-QA, but after a particular point all you did was slow down shipping.
One satisfying aspect of the work I did at the last acquiring company is that every time I checked in code, I knew I could with a straight face recommend that we ship it. I mean, it wasn't a full QA pass, but it was code with a supporting set of automated unit tests incorporated into a system designed as an extensible framework. Any negative impact would be isolated to that specific functionality (high cohesion, low coupling). A small group of internal power users and my own server would take the daily builds and give feedback as to how it felt in production and report any major issues.
The message here seems to be "if you can optimize the process in some way, optimize it so you ship faster". And in the meantime, go ahead and pretend like you're shipping every day (a complete, ready-to-go, high quality build). You'll be surprised how much better you feel even with that.
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.
Doesn't work if you know that under such circumstances, you won't be even able to work properly. Some people only work (work as in tick) only the my way/highway way, just in reverse; those are sometimes crackpots, but also quite often very good programmers.
Power corrupts the few, while weakness corrupts the many.
This sort of thinking does not justify the new userpage.
Sometimes, life itself is sarcasm...
Comment removed based on user account deletion
"Many a man meets his destiny on the road to avoid it."
Talking about bugs, and software failure.
It is not human error or develope methodology that matter.
It is the model in our society is too simple! Like we teach students to make a upper to treat string, instead of having a more realistic way to handle culture difference.
All other systems have the same problem, we cut cost by having a simple model of the world, which finally fail in some cases.
However, the whole industral do not recognize this, they continue to work this way. This can not be a normal style of the industry. We need to adapt to a more realistic policy.
Yes! Free Karma... right after Willie! I'm starting a grassroots movement to save the Karma from untimely demises.
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
Perhaps there is no "real talent" to use. Seriously, just because there are programmers out there who think they are better than most of the others, doesn't make it true.
Of course, if programmers who post on Slashdot were representative, we must all think we are über-programmers.
The truth about software engineering is that nobody has THE solution. There isn't a true 3 step fills all the buckets and "everything will be fine" approach. Every environment and every procedural approach will (and IMHO should) be different.
There can be similarities between systems but you can't apply the doctrine of a compiled desktop development cycle to embedded development for engine management systems. It's appropriate for the developers of engine management systems to be very careful and just as appropriate for developers of utilitarian desktop software to release early, release often.
What Paul touches on in the article is the real issue. It's about motivating people to do what you need them to do. When somebody works with their mind, motivation is critical. You can force a factory worker to produce x widgets in an hour, but you can't force somebody to think effectively.
It's not necessarily about having the best people, it's about getting the best from the people you have. And I've got the feeling Steve Jobs would agree.
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
Does anyone had worked for big automotive ones? I understand the need to oversee every process of writing software that runs on CARS, but in a web page? I need to fill about 100 pages of documentation for a little web site... I wonder if you have similar experiencies... and not only that: 50% of IT-related workforce is made from scolarship interns (saving cash, I presume), and the bureucracy involved, not to mention complete ignorance of technologies involved, from marketing to even systems people, gave me more than one headache in the process.
Carlos Niebla
A lot of people who are bored stiff with writing documentation are good with white-boards and q&a sessions.
Make a video of the dev explaining the whys and wherefores (stuff that usually gets omitted anyway - youknow - "wtf did they do it like THAT?"), explaining how it's to be used/deployed, and answering questions from the other coders/reviewers/testers.
If avoiding mistakes is a huge mistake, you are not making that mistake because you are making a mistake by avoiding mistakes.
Your evaluation period for Productivity 1.0 has ended. Please purchase more coffee to continue using this product.
I'd be willing to put up with more checks provided that there are checks put on:
... but that good programmers won't even want to work for you.
Fine. Then we'll hire twice as many bad programmers and pay them half as much.
Have gnu, will travel.
self-organizing, that is...
http://www.zoion.com/~erlkonig/writings/programmer-beekeeping.html
Cheers!
-Captain Fairly-Obvious.
The appropriate question to ask is would a thorough code review of the Mars Climate Orbiter software have prevented its loss? The problem was one of units (metric vs. English) which means the code on either side of the interface was absolutely correct. Only a live person looking at both pieces of code could realize that one piece of code used metric units while the other used English units.
Likewise, the code on either side of the interface may have been a paragon of software virtue. The "quality" of the code was not the problem that needed to be found. The problem was one of human understanding. Only a human reviewing the code could have seen it.
It's nice that code reviews frequently find trivial bugs that would have later been found during test. There is also a certain amount of weeding out of substandard code (obscurely written, poorly commented, bad design, not compliant with group standards for naming and such). Such code will also be found and excised when it passes from the developer to those who must maintain it. That is, the bulk of the things that most people see as the purpose of code reviews are actually a very superficial and unnecessary result. It's finding the design and requirements bugs like using incorrect units that are really the pay off.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
I respect what you've done. Creating
what became the Yahoo! store in Lisp
was pretty cool. "A Plan For Spam"
was awesome. (Too bad Microsoft
gave spammers infinite resources
with which to create infinite variations
of messages and defeat Bayesian filtering.)
But please... it's almost 2009. I don't care
what you once read about optimal column
width. Why not just let the text be a fraction
of the page's width and let the reader decide
how wide they want it to be? I've got a GUI
and resizable windows and a wide monitor
and everything.
Thanks,
- The Internet
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
As usual, the answer is more complicated and has to do with the size of your team, the maturity of your product, and the acceptable risk profile of your market.
Most importantly
Erik Sink gave a wonderful talk on the maturity of software. As he put it - shipping too early is one of the worst mistakes you can make to your teenaged software.
Fundementally, Paul Graham is being a troll. Or he needs to get out in the real world a bit more.
-- Butlerian Jihad NOW!
"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.
so, what is happening? How about those new covers on the TPS reports? I'll just go ahead, and send you another memo...
You can't handle the truth.
Are we talking code reviews here, or checks and controls in general? Code reviews can be very helpful, if the objective is solely to educate and learn, rather than finding excuses for why you haven't performed well enough next time you have a salary review. It could be run in confidence by a group that is independent of management, eg. and external company.
It should be obvious that too little or too much in the way of controlling people is bad, and not just in programming. Social security in many countries is like that, especially in Scandinavia; there are so many checks in place to prevent benefits fraud and ensure that society only spends money on people who actually need it, that not only does it cost far more than what is potentially saved, but it also means that helping those that actually need it most takes very long. And to top it off, it doesn't prevent benefits fraud at all.
In my view, it should be simple and to the point - it shouldn't be possible to simply go and claim unemployment benefits if you are well off and have a good job, but it is a lot more efficient to simply trust most people to be honest and then let the police catch the cheats. Same with tax - make it a fixed percentage, with no loopholes for anybody to wriggle out of it.
In development the same principles apply: the basic assumption must be that people are honest and want to get the job done. In some environments it can be useful to have an "Issue Tracking System", so you don't loose track of what you are doing, code reviews can be helpful too; but only if they are used as tools, not weapons.
If sufficient 'quality' checks are added to avoid the costs associated with mistakes, the process is 'factoring in' the cost as a normal operating expense. If the checks, testing, paperwork cost more hours to perform 'correctly' than a bug itself would cause when it occurs, then the cost of bugs is added to every release whether the bugs occur or not.
This is paying for bugs the hard way. This destroys the value produced by the good programmers by adding back the costs their good code saves. It's much easier to reach this threshold than most (non-programmer) managers realize.
The advantage seen by managers is a 'better' management of the process due to predictable schedules. The predictability comes from slack in the schedule created by low-bug software that doesn't cause delays. Illusionary schedule gain is then used up in the next release that has a (statistically insignificant) increase in bugs. Over time, it looks better but costs more.
Pavlov wouldn't be so famous if he'd used a can opener instead of a bell.
Indeed. Thank you. There's a palpable difference between "what if" and "what if _we_" in the group politique. Once you get to _we_ it gets fun.
This management paranoid fear of mistakes can drive anyone nuts. I used to work for a place where every tiny bit of information created had to be dated and signed, documented, archived and double-verified by both a QC and a QC department. This eventually drove me off the deep end when I was given the lead on a project that was half-assed in its theoretical abstract and previous implementation, ensuring ultimate failure that I was blamed for, no matter how much evidence I brought forward (and got dismissed as "proof of my lack of teamwork")
Dear God!! CODE REVIEWS! Heaven forbid we might be required to *gasp* do our jobs correctly, instead of just whipping-together whatever fancy comes to mind and pushing it out the door!
The developer world has (for the current developer-fad's iteration) been taken over by agilist monkeys who want to rid the developer world of having to produce documentation, having to do QA and rigorous bug-checking and fixing, status meetings, documented and well-reviewed requirements gathering and design -- basically, everything except pure coding.
Everything except, you know, the less-fun work that is necessary to do our jobs properly and to communicate and pass our work on to project non-members...
Is Capitalism Good for the Poor?
What's the Karma hit if I blow up the studios because Mister Riccitiello told me too ?
----- The internet has given everyone the ability to have their voice heard equally as loud.. even if they shouldn't be
Sure, having a strict QC process might make lazy programmers less likely to want to work for your company, but with OS developers learning more and more from their mistakes, and making their products harder and harder to exploit - attacker interest is switching rapidly towards the client applications. Why try to break through the walls, if you can use a window, no pun intended, kindly created by a liberal coder? You have to keep in mind that cost of doing business may be high, but the cost of having a backdoor in your new release can be a lot higher. Because, lets be frank here, how many coders out there think about security at any point before finishing their quota?
Saving money on QC? - Good
Having programmers like you? - Lovely
Having an unsanitized input field in your code cause a leak of hundreds of thousands of PHI/PCI records and put you out of business? - Priceless
Bow before me, for I am root.
In my previous job, I worked for a huge manufacturing company. I developed, maintained and supported an add-on (plug-in, extension, module, whatever) for their 3D CAD/solid modeling application (Pro/Engineer).
When I first hired on, and started working with the application, I learned about the quality process we used: SPQA, or software process quality assurance. This was relatively straightforward, and, in my opinion, didn't add too much overhead. It was basically a checklist of things that a manager went over with the development group. Then we added AQA, application quality assurance. Not only did this add more overhead, but some of the requirements of the two processes conflicted!
The projects my group worked on were fun, cool, and cutting edge, and the majority of the staff was quite engaged in their work. So we worked through all this process nonsense, and basically got used to it. However, lurking in the background all the while was 6 Sigma. The company had adopted this methodology wholesale, and was forcing it to be used in every facet of operation. Now, not only did we have our previous processes, SPQA and AQA, but we had 6 Sigma to contend with.
Looking back, it's sad how much time and effort was wasted just trying to figure out how to integrate all these processes into our development. Literally, the whole section (about 12--15 people) spent many meetings and countless hours coming up with process maps, just to explain how our development would proceed, and comply with AQA, SPQA, 6 Sigma and anything else management felt like we needed to do. I used to eat lunch with the supervisor of another group---he had actually worked in the same group as me, years ago. I'd be moaning about how much of my effort was spent just trying to juggle all these processes, and he'd say, "Back in my day, we just thought up an idea and coded it." I'd talk about the growing queue of bugfixes and enhancements, and how none of them could ever be realized without eliminating all this process nonsense (or doubling the staff and budget) and he'd smile and say, "I remember when so-and-so called me up, asking if I could make the program do such-and-such, and I did it the same afternoon!" Sigh.
Duck-->Quack-->SMACK!
can't say you didn't warn him!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
... but did you learn to click "Post Anonymously" next time?
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
First you say that if I "implemented some very complex system in less time then a competing group of 10 programmers did" you would "at least consider it possible" for me to create a 10x sort without proof.
Then you say: "That someone can do the same as a larger group and needs less time for it does in no way whatsoever compare to someone developing a 10x faster algorithm."
So if they're not comparable, why are you linking them?
instructions on how to get a bigger pen15 2day
:(
Why are there no penis enlargement 0-days?
I would deny them the joy and experience of looking at good code sometimes, because the tendency to bicycle shed.
Everyone wants to put some input into the project to prove that they are involved, working, and generally providing some value for the money they are paid. In less than perfect code, this often means they come up with lots of issues that need to be fixed because the code is flawed.
With very pristine code, this often means that they come up with lots of issues that shouldn't be fixed because the code isn't flawed. This can be mitigated by having a better review process, but it's hard to overcome human nature.
A real world example not in code comes to mind.
My brother bought a day care centre, and with every change of hands, such businesses must be inspected (a good practice). Problem was that this centre had been in operation for over thirty years, and had recently passed inspection in a prior sale less that two years ago. So the health inspector stated that the hot water in the public facing bathroom (for parents, children, and employees in the waiting area, not the centre itself) wasn't hot enough. Never mind that it was one hundred and five feet from the water heater and would be plenty hot in three or four seconds of running, it had to be hot instantly. So he installed an assist water heater right behind the wall of the sink.
You might think that the health inspector has a valid point, but if he did, then why did the centre manage to operating unsafely for thirty years? More likely than not, he had to find something wrong to prove to his supervisor that he was really working. Day care centres are inspected far too often for any issue to go unnoticed; to have an outstanding issue, you need a negligent inspector.
He sold it a year later, I wonder what new miracle "flaw" was discovered?
Very good practices in code review could lessen the risk of bike shedding, but it would be very hard to eliminate it. For quite a few of us, it's human nature to add in your own two cents; right or wrong.
Hence the reason for this post, oh the irony! :)
I'm surprised that none of the responses that I see so far mention the obvious solution that I do; fire the inept. It doesn't matter what your organization or profession is -- every organization has some rules and guidelines to prevent stupid mistakes from happening.
Sometimes these mistakes are not apparent, and the check/rule is there for a good reason.
However, my experience is that most of these checks/rules get put in place because some stupid fool went and did the kind of thing that a stupid fool would do, and it's an attempt to save the stupid from doing what they would otherwise do naturally; stupid things.
"You can't fix stupid."
If you have inept staff around, they are going to do stupid things and there is nothing you can do to stop them, so stop trying, and fire them.
I greatly wish that a couple of guys that I work with would get fired. I like them personally, but they are fark-ups. They just can't manage to consistently do things right. In some cases, they consistently screw things up.
So, as a personnel manager, please do your job. When people fark up, warn them, then fire them. If you don't the talented people are going to get tired of fixing the work of the inept and quit. You end up with the "Dead Sea" affect, where you're only left with the worthlessly inept and your business sinks.
Don't make a new rule/law/check, just solve the root source of the problem; fire the stupid people!
Arbtrary isn't a synonym of bullshit.
YOU equated developer productivity with execution speed, see the link below by SillyNickName4me (760022).
You're also - as of now - a proven liar.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."