Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Avoiding Mistakes Can Be a Huge Mistake

ScuttleMonkey posted more than 5 years ago | from the joys-of-corporate-overlordship dept.

Programming 268

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?"

Sorry! There are no comments related to the filter you selected.

First duh! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25952345)

Duh!

Perhaps (5, Interesting)

Thelasko (1196535) | more than 5 years ago | (#25952367)

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.

Re:Perhaps (5, Insightful)

Anonymous Coward | more than 5 years ago | (#25952461)

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?

Re:Perhaps (1)

Samschnooks (1415697) | more than 5 years ago | (#25952507)

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?

Good point. Many professions have you observing and learning from more experienced people before you dig into the important and sometimes life threatening procedures.

Re:Perhaps (2, Insightful)

kybred (795293) | more than 5 years ago | (#25953199)

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.

Re:Perhaps (5, Funny)

YourExperiment (1081089) | more than 5 years ago | (#25952477)

Do programmers also loose karma for being fast and lose with their spelling?

Re:Perhaps (4, Funny)

Anonymous Coward | more than 5 years ago | (#25952547)

Do programmers also loose karma for being fast and lose with their spelling?

/irony

Re:Perhaps (0)

Anonymous Coward | more than 5 years ago | (#25952587)

/woosh

Re:Perhaps (0)

Anonymous Coward | more than 5 years ago | (#25953391)

/woosh

/irony

Re:Perhaps (5, Funny)

kbrasee (1379057) | more than 5 years ago | (#25953443)

/irony

/woosh

/irony

Error: Cyclic Dependency

Re:Perhaps (0)

Anonymous Coward | more than 5 years ago | (#25953505)

/irony

/woosh

/irony

Error: Cyclic Dependency

/woosh

Re:Perhaps (5, Funny)

ChromeAeonium (1026952) | more than 5 years ago | (#25952711)

Do programmers also loose karma for being fast and lose with their spelling?

/irony

They can be docked karma that way, but when they're not sure about something, they can cover their asses and submit anonymously. That way, if something totally whooshes over their heads, they're in the clear. They can later correct their own dumbass mistakes unanonymously and whore karma instead of losing it. What a perfect system!

Re:Perhaps (4, Funny)

ScrewMaster (602015) | more than 5 years ago | (#25953271)

Do programmers also loose karma for being fast and lose with their spelling?

/irony

They can be docked karma that way, but when they're not sure about something, they can cover their asses and submit anonymously. That way, if something totally whooshes over their heads, they're in the clear. They can later correct their own dumbass mistakes unanonymously and whore karma instead of losing it. What a perfect system!

Huh. Too bad Slashdot doesn't have a system like that.

Re: loose karma (3, Funny)

macraig (621737) | more than 5 years ago | (#25953875)

Yes! Free Karma... right after Willie! I'm starting a grassroots movement to save the Karma from untimely demises.

Re:Perhaps (1)

BlackBerry8700g (1397101) | more than 5 years ago | (#25952553)

Did you mean fast and loose?

Re:Perhaps (1)

k-vuohi (973009) | more than 5 years ago | (#25952581)

Or fast and *whoosh*?

Re:Perhaps (1, Funny)

brez180 (832822) | more than 5 years ago | (#25952881)

You *lose* at spelling.

Re:Perhaps (0)

Anonymous Coward | more than 5 years ago | (#25952979)

Had you noticed the other "mistake" in his post ("fast and lose"), you would have got the joke. You *lose* at humour AND proofreading.

Re:Perhaps (1)

andrikos (1114853) | more than 5 years ago | (#25952977)

But they gain good karma for their "insightful comments"

Re:Perhaps (1)

SpaceLifeForm (228190) | more than 5 years ago | (#25953437)

No, but they usually get compiler errors for being loose with their spelling, so they lose productivity.

Re:Perhaps (0)

Anonymous Coward | more than 5 years ago | (#25952483)

all teams need checks, not because you do not trust them but ultimately the code may need to be supportable by other people and there are no glaring holes or potential back doors.

There are many reasons for the checks, from political to financial, but they both form a risk factor which is then available to upper management.

Re:Perhaps (4, Interesting)

Pogue Mahone (265053) | more than 5 years ago | (#25952583)

That's exactly the kind of check that is harmful, according to the article. Who determines what is "excellent"? Against what benchmark? Who performs the audits? Who checks that you have spelled "lose" correctly?

Re:Perhaps (3, Insightful)

postbigbang (761081) | more than 5 years ago | (#25952705)

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?

Re:Perhaps (3, Insightful)

pe1rxq (141710) | more than 5 years ago | (#25953221)

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.

Re:Perhaps (5, Interesting)

enjo13 (444114) | more than 5 years ago | (#25952661)

How do you identify "good code"? That's one of the great problems we have as software developers. Quantifying 'good' code is extraordinarily difficult. Code reviews do an excellent job of identifying clever code, but rarely capture the full utility of what is being written. You may think you know good code when you see it, but over the course of my career I've become convinced that is not true at all.

Really the problem is that the only way to truly measure code quality is by seeing how it runs in a production environment. Even then I can easily quantify the quality of the teams overall output (does it work? does it work consistently?), but tracing that back to an individual programmer is often nearly impossible. Systems tend to interact with each other, and placing blame is not an exact science. The gulf between 'good' and 'good enough' is not nearly as wide as it seemed when I was a novice programmer.

Great code almost never breaks. Good code works most of the time. Poor code is another matter.

Poor code is easy to spot. Poor code never works. It's ugly. It's complex. It's stateful. It's jump off of the screen and practically begs to be put out of its misery.

That's precisely why companies have processes and checks. They are an attempt to catch marginal code and make it 'good enough'. The problem, as the article points out, is that in the process they often inspire great coders to deliver marginal code themselves.

The secret is to spot (through some mixture of science and art) great programmers and provide them with the freedom to write great code. If circumstance requires you to hire marginal programmers, then by all means put the process in place to make sure that what they do doesn't detract from the work your best and brightest are doing. Separate them as best you can. Limit how their systems interact.

But whatever you do... don't limit your best programmers, as they are far more valuable than hundreds of poor ones.

Re:Perhaps (3, Funny)

mevets (322601) | more than 5 years ago | (#25952989)

The "robustness" test isn't good enough either. Sometimes poor implementations of good ideas spurn enough innovation and demand that its marginal quality is irrelevant. The early web browsers, email programs, etc.. were likely neither robust or well implemented. On the other hand, some solid, robust good implementations of ideas are so intractable, that at best they merely serve the original purpose, and at worst are like an albatross around the necks of future developers ( usb anybody ?).

David Parnas proposed that a poor programmer could create demand for dozens of programmers; a unique software situation, as a poor mechanical engineer doesn't scale nearly so well.

Re:Perhaps (1)

Fulcrum of Evil (560260) | more than 5 years ago | (#25953783)

Sometimes poor implementations of good ideas spurn enough innovation and demand that its marginal quality is irrelevant.

Just because something is valuable in spurring innovation doesn't make it good code.

Re:Perhaps (2, Insightful)

ScrewMaster (602015) | more than 5 years ago | (#25953301)

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.

Re:Perhaps (3, Interesting)

ChrisA90278 (905188) | more than 5 years ago | (#25953857)

I don't think you even need "good code". I worked on a project that eventually failed and all the code we looked at in those reviews was "good". Either that or we made it good. The big problem was that it did the wrong things.

The problem is not with the people who write the code. Most are OK and reviews catch gross errors but in out case we had some basic "big picture" ideas wrong.

Microsoft Vista is a good example of this. Likely the code would pass a review and has few mistakes but the problem is the dumb ideas that got written into the specifications.

It's like the "bridge to nowhere" problem. Good, competent structural engineers build something no one wants or needs.

Re:Perhaps (1)

FishOuttaWater (1163787) | more than 5 years ago | (#25953901)

Great code is easy to spot:
  - When you look at any routine, it's obvious what it does and how.
      - Variables and functions are named in such a way that the functionality is obvious CalculateDestinationIPAddress(&remoteGateway);...
      - Comments are provided to describe overall flow, non-obvious algorithms, and sources of reference information.
  - Stuff that controls like issues is grouped together.
  - It doesn't provide multiple solutions to the same problem.
  - It factors out redundant code so that you don't have to maintain the same information or code in multiple places.
  - It identifies parameters of the design and makes them easy to tweak in a centralized location.
  - It is optimized to an appropriate degree based on the requirements of the design.

Some stuff I have learned the hard way:
  1 - For new code, write the comments first, then write the code to implement what the comments say. The commenting allows me to work out pseudocode to flesh out the design, and the pseudocode gets reused as the comments for the final code. I don't know anybody else that does this, but it has worked very well for me. (Oooh, method patent!!!)
  2 - For old code, before adding a new solution to a problem, look for existing solutions. Follow those or fix them, but for God's sake, don't add a new one if there already is one.
  3 - Find a hardware guy responsible for tracking down bugs. Accuse him of a pretend bug to find out what information he needs to track it down. Add code to collect all that information at the push of a button so that your customers can do it easily.

Re:Perhaps (4, Insightful)

syousef (465911) | more than 5 years ago | (#25952847)

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.

Re:Perhaps (5, Funny)

sammyF70 (1154563) | more than 5 years ago | (#25953089)

Google is evil incarnated, Apple is style-over-function overpriced junk, and "The Year of The Linux Desktop" ain't coming soon.

Microsoft, on the other hand, has some really funny employees [youtube.com] (and Reversi).

/em ducks

Re:Perhaps (2, Insightful)

OFnow (1098151) | more than 5 years ago | (#25953263)

(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)

Re:Perhaps (1)

gnasher719 (869701) | more than 5 years ago | (#25953889)

(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)

I once spent one full week debugging to find a bug when someone made a code change that was unnecessary, trivial, not reviewed, and wrong. (Someone thought that if (! p) looked better than if (p != NULL). Which one looks better is debatable, but one is the opposite of the other).

Re:Perhaps (4, Interesting)

ifdef (450739) | more than 5 years ago | (#25953291)

We have a more informal system where I work. Whenever anybody checks in some code, whoever wants to automatically gets an email to notify them (for example, I am set up to receive notifications for any changes in a few directories where I do most of my work). Anybody who wants to then reviews the change. If there is nothing to comment on, it's completely transparent, and the person who checked in the changes is not even aware that they got reviewed. If there IS something to comment on, most likely someone will talk to the original coder (or send them an email), saying something to the effect of "by the way, did you consider such-and-such?", or maybe even "good idea!"

The system keeps track of who reviewed what change. As a check on the process, if there is any change that has been in the system for x days but has not been reviewed by at least m developers and n testers, the original coder gets an automatic email saying "please arrange for someone to review your code."

This is, of course, in addition to the automatic emails that get sent if a change actually BREAKS something. Those get dealt with right away.

So the review process does no harm to anybody's morale, except in the cases where that person really is producing bad code.

Strangely enough, it seems to work quite well.

As for your other point, about "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": I don't want anybody with that attitude in my group, period. I am not in any kind of supervisory position, but if there is someone on the team who only produces good code because of some "incentive", and the team lead doesn't do anything about that, then I don't want to work for that team lead, either. I will vote with my feet, and I don't think I would be the only one. And then this would become, no doubt, a much more "normal" software department, instead of an amazing one.

Re:Perhaps (0)

Anonymous Coward | more than 5 years ago | (#25953559)

Next what you're proposing creates a negative feedback loop.

You probably want to say "positive feedback loop". In control engineering, negative feedback corrects mistakes, and results in a stable system. Positive feedback enhances mistakes, creating instabilities.

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.

Then again, here you are actually describing a negative feedback loop. This is exactly how a feedback loop should function. With no mistakes, no corrections. However, when deviating from the desired target, observed mistakes will lead to corrections. The instability your are implicitly predicting isn't due to the positive or negative sign in the feedback loop, but due to a too long time delay between making the error and getting corrected. A classic cause of instabilities in otherwise stable negative feedback systems.

Re:Perhaps (1)

digitalhermit (113459) | more than 5 years ago | (#25952875)

Interesting idea..

There's a (probably apocryphal) story about the US car manufacturing industry. When some Japanese companies decided to build over here the company execs wanted to make sure that the same level of quality from the Japanese plants were retained in the USA. To that goal they implemented a bunch of newer controls and QA methods. The result was that the USA factories ended up putting out better cars than the Japanese factories. The controls were then put in place across the entire company.

Code is not like cars however, but you can still use tools to gauge the aspects of the relative quality of the code.

Imagine a scenario with a karma system: the more veteran programmers get assigned to the more critical projects. Alas, because they are "vetted" their code is not scrutinized as often as someone else working on a lesser project. The potential for failure is increased which is opposite of what was intended.

I'm not saying that will happen; the idea of a karma system is good (hehe, a similar one exists called the "salary" system where better programmers get better pay), but there are pitfalls in any system.

Re:Perhaps (1)

andrikos (1114853) | more than 5 years ago | (#25953029)

Just when I was thinking that this article went too far without a car analogy

A fine balance (4, Insightful)

pwnies (1034518) | more than 5 years ago | (#25952371)

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/ [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.

Re:A fine balance (0)

Anonymous Coward | more than 5 years ago | (#25952545)

And for people that fail at life, you have failblog.org http://failblog.org/2008/11/28/employee-intelligence-fail/ [failblog.org]

Take that picture for example. You can only guess the story behind it and how many times it had to have happened for them to put up a note about it.

Re:A fine balance (0)

Anonymous Coward | more than 5 years ago | (#25952575)

So, maybe by getting rid of the checks, better programmers will be willing to work.

Then, the people who get shampoo in their eyes won't be an issue, because then the companies can just replace the programmers who write bad code with ones who write better code.

With the better programmers, then, you should see better products released on a faster cycle, and it provides an incentive for the bad programmers to improve their skills as opposed to relying on the checks that hurt everyone else.

Let it be known that your software is flawless (1)

Anonymous Coward | more than 5 years ago | (#25952395)

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.

It's official (3, Funny)

Anonymous Coward | more than 5 years ago | (#25952439)

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.

Re:It's official (0)

Anonymous Coward | more than 5 years ago | (#25953831)

Actually the best ones make their work even harder than it needs to be. That is why they like Linux.

More checks! (5, Insightful)

I.M.O.G. (811163) | more than 5 years ago | (#25952443)

From the article:

Whenever someone in an organization proposes to add a new check, they should have to explain not just the benefit but the cost. No matter how bad a job they did of analyzing it, this meta-check would at least remind everyone there had to be a cost, and send them looking for it.

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!

Re:More checks! (1)

naetuir (970044) | more than 5 years ago | (#25952531)

I like this idea.

Send the politicians politicking the politicians.

Meanwhile, the programmers will be busy actually getting some real work done!

Re:More checks! (1)

Retric (704075) | more than 5 years ago | (#25952537)

The check is on adding bureaucracy not doing your job. Bureaucracy can be a good thing, but when you assume it's a good thing and has zero cost it's going to bite you in the ass.

Re:More checks! (1)

gatesvp (957062) | more than 5 years ago | (#25953077)

From the article:

Whenever someone in an organization proposes to add a new check, they should have to explain not just the benefit but the cost. No matter how bad a job they did of analyzing it, this meta-check would at least remind everyone there had to be a cost, and send them looking for it.

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!

Building a check on your production line is very expensive. It automatically slows down the line. It comes with the overhead of modifying the production line, re-instructing the people on the line, etc. Building a check on the "verification process" is far less expensive. Management is already just overhead, increasing their overhead to protect productivity is way cheaper than the alternative.

Re:More checks! (1)

GravityStar (1209738) | more than 5 years ago | (#25953275)

Management will then ask the programmers to do the verification.

Re:More checks! (1)

Fulcrum of Evil (560260) | more than 5 years ago | (#25953833)

Building a check on your production line is very expensive. It automatically slows down the line. It comes with the overhead of modifying the production line, re-instructing the people on the line, etc.

And yet, Toyota does just that [toyotageorgetown.com] . But why are you talking about production lines in the context of software?

Re:More checks! (2, Funny)

woodrad (1091201) | more than 5 years ago | (#25953305)

Oblig Yes, Minister quote:
Jim Hacker: Twenty three thousand. In the Department for Administrative Affairs. Twenty three thousand people just for administering other administrators. We have to do a time and motion study, see who we can get rid of.
Sir Humphrey: We did one of those last year.
Jim Hacker: And?
Sir Humphrey: It transpired that we needed another five hundred people.

I have mixed feelings. (2, Insightful)

Samschnooks (1415697) | more than 5 years ago | (#25952447)

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.

Death March (4, Insightful)

micromuncher (171881) | more than 5 years ago | (#25952467)

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.

Re:Death March (1)

Retric (704075) | more than 5 years ago | (#25952555)

If you have a bad coder fire them don't hamper everyone with a bad process so idiot's can become mildly productive.

Re:Death March (1)

story645 (1278106) | more than 5 years ago | (#25952755)

If you have a bad coder fire them don't hamper everyone with a bad process so idiot's can become mildly productive.

If a person fires every bad coder working for him, soon enough he'll be the only one left to work on code. If the company is sufficiently large, maybe he'll be lucky and have a handful of coders whose skills could probably be utilized better if they had bad coders to pass on tasks to (and who hopefully can eventually become good coders.)

Dunno, I'm in my 4th year of computer engineering and what I see is that most students are somewhere between mediocre and horrible programmers. I assume weeding has made the industry scale a little better, but those programmers do come out of school so they have to be picking up skills somewhere.

Re:Death March (1)

Retric (704075) | more than 5 years ago | (#25952937)

This seems like great advice, but bad coders reduce productivity. If you have 7 people working for you and you fire the worst 4 of them you now have cash flow pay you good people enough to stay and can add 1 more competent person.

PS: Look at the development history of Mac OS X to see what can happen when you remove useless people.

Re:Death March (2, Insightful)

skribe (26534) | more than 5 years ago | (#25953155)

How much does it cost to find, vet and hire a replacement coder? Both in real money terms and in loss of productivity. How does it compare to bringing the 'bad coder' up to speed through better training strategies?

Just some thoughts,

skribe

Re:Death March (0)

ifdef (450739) | more than 5 years ago | (#25953365)

It probably does cost a lot to find, vet and hire a good coder. But it's well worth the effort.

Let some other company bring the bad coders up to speed.

And also consider that just because someone is a bad coder, they may still be an excellent manager, or sales person, or documentation writer, or tester, or customer relations person, or project scheduler, or whatever. They don't necessarily have to be writing code. If they are a bad coder, and don't care enough, or have the ability, to become better coders, they SHOULD be doing something else.

Re:Death March (1)

GravityStar (1209738) | more than 5 years ago | (#25953329)

Agree, I've encountered bad programmers that had a net negative contribution to the team. Not often, but I have seen it happen.

Re:Death March (0)

Anonymous Coward | more than 5 years ago | (#25953009)

Yeah, but your one of teh idiot's.

Re:Death March (0)

Anonymous Coward | more than 5 years ago | (#25953791)

True, that's why I became your manager.

Re:Death March (2, Informative)

Anonymous Coward | more than 5 years ago | (#25952795)

if you use metrics to understand how hard someone is working, then you fail before you have begun.

metrics == management

Re:Death March (2, Interesting)

wideBlueSkies (618979) | more than 5 years ago | (#25953245)

And some of us like to program just for the sake of programming. And create applications and solve problems because to do so is interesting and fun, and one gets to work with other smart people.

The premise... (0)

Anonymous Coward | more than 5 years ago | (#25952611)

of this suggests that there are good programmers out there...

Please don't hit me, signed sysadmin ;)

...Perhaps the author is a little biased? (2, Insightful)

Zakabog (603757) | more than 5 years ago | (#25952619)

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.

Re:...Perhaps the author is a little biased? (1)

cowscows (103644) | more than 5 years ago | (#25952813)

Yeah, his examples are pretty stupid too. Comparing writing commercial software vs. cutting yards? One's a career and the other's a way for a high school kid to make money over the summer.

That's not to say that there aren't professional landscapers who take their work seriously, or that there aren't programmers that aren't lazy beyond words. Take any job position, heck take almost any individual company, and you'll probably find a handful of relatively lazy and unmotivated people, and a handful of super-motivated, 60hours+ per week people picking up all that slack. Then in the middle is a bunch of people who put in their eight hours a day, and maybe a little overtime for the occasional deadline crunch.

The IT/software world is not particularly special or different from any other career that's ever existed. At a larger scale, it's a bunch of groups of people working together to make things, and so it ends up with all the social, political, and cultural issues that every other field has to deal with.

Re:...Perhaps the author is a little biased? (1)

sleeponthemic (1253494) | more than 5 years ago | (#25952905)

I think most people quickly realise that moderate workload accelerates a working day and thus, gets them out of there quicker.

Having done a few jobs in my time, I can testify programming is among the easier jobs I have done - in terms of getting through the day. Sure, sometimes it is incredibly frustrating, but sitting at a desk, listening to music and coding is for the most part, great.

(Especially when you're not debugging).

Re:...Perhaps the author is a little biased? (1)

evil_aar0n (1001515) | more than 5 years ago | (#25953055)

Amen, brother. I pretty much don't care what I'm doing - as long as I'm engaged, and can't think about the drudgery. Ennui kills me.

Re:...Perhaps the author is a little biased? (1)

ifdef (450739) | more than 5 years ago | (#25953405)

... 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.

Those people should find a different line of work that they DO enjoy.

Re:...Perhaps the author is a little biased? (1)

ifdef (450739) | more than 5 years ago | (#25953477)

And there are several other jobs that I also feel very strongly should NEVER be done by someone who is only doing it for the money. A religious minister, for example.

Or a girlfriend :-)

I'd like to include teaching as something that should only be done by those who are passionate about it, but I can see that there would be practical problems with this. And yet, a good teacher can change a kid's life. I had several great math teachers, and that's how I ended up in this field. I've heard of great English teachers that made a difference to someone who ended up being an author. A great music teacher or art teacher could easily be the deciding factor in someone's further education and eventual career choice.

Re:...Perhaps the author is a little biased? (0)

Anonymous Coward | more than 5 years ago | (#25953421)

Found this other day and thought it absolutely perfect here: http://www.guardian.co.uk/books/2008/nov/15/malcolm-gladwell-outliers-extract

The best ones are the best ones precisely *because* they worked hard, at whatever job it was they worked at.

True, most of the guys mowing lawns for a few bucks hate the job, but it pays the rent. But for every few of them, there's some guy who's got a $5000 riding lawn mower, complete with gps navigation and robotic seed/fertilizer spreader, and a yard the size of a city block that he spends 10 hours every Saturday turning into the fairway at Pebble Beach. He may not be a professional lawnmower now but I bet that'd change in a heart-beat if he was paid as much as one of "the best" programmers.

Re:...Perhaps the author is a little biased? (1)

Matthew Weigel (888) | more than 5 years ago | (#25953485)

To me, it's weird that you would separate programmers who enjoy doing the job away from career programmers. In my experience, it's most professional programmers, and certainly the best ones I've worked with love doing it. But biased towards programmers who enjoy programmers? Hell yes, it's an article talking about tech startups, of course it's going to make some assumptions about programmers in the audience.

Re:...Perhaps the author is a little biased? (0)

Anonymous Coward | more than 5 years ago | (#25953767)

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.

Those people certainly exist, but they are almost by definition not "good" programmers. Programming is a creative job, because there are a nearly infinite number of ways to solve any particular problem, and there's a nearly infinite number of ways to express each of those infinite number of solutions in code. People who choose the job knowing they like coding as much as they like mowing grass are like the "painter" who does caricatures at the mall for 6 hours a day, and goes home to watch TV. Sure, you can show up and put some standard pieces together and get a product that looks like something, but it's never going to stand up next to a work done by someone who actually loves the process of creation. And it won't do you a lot of good, either, when your group is on the hook to deliver the Mona Lisa.

obviously (1, Insightful)

nine-times (778537) | more than 5 years ago | (#25952621)

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!

Re:obviously (2, Insightful)

Anonymous Coward | more than 5 years ago | (#25952781)

Now that I've I know, I'm going to dismantle all my QA procedures and hire the sloppiest programmers I can find!

How about I take every little thing you say and take it to the farthest possible extreme without any regard for the subtleties in what you originally said?

What you said sounds like a great idea! Why don't we KILL ALL THE PEOPLE WHO DO QA, like you are clearly suggesting, rape and torture their families and then hire pedophiles and trained gorillas to do the work?! Isn't that exactly what you were saying just now?! Isn't it?!!

Re:obviously (1)

GravityStar (1209738) | more than 5 years ago | (#25953409)

I see you've written a setter in your code there. Could you please document the need for this method in the procedure review document and defend its addition at the next code review meeting? Thanks.
-- Your Boss.

My point is; sometimes procedures appear to exist only to drive people insane.

Black Swans (1)

alexander_686 (957440) | more than 5 years ago | (#25952627)

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.

Re:Black Swans (1)

tmarthal (998456) | more than 5 years ago | (#25952863)

I think he is more thinking about competition, not about how big a company is.

Why do people use your "highly regulated complex industry" software over someone else's? Because it has more features? My bet is that you don't have any true competitors. Now seriously ask yourself why you don't have any competitors.

One of the reasons that you might not have any competitors, is because of the checks that are put in place by the regulations. Companies that could compete with you on a per-capability basis will not compete because the cost of the regulation "checks", which is the whole point of the essay.

Cyber "security" is in the same boat. (1)

Mesa MIke (1193721) | more than 5 years ago | (#25952681)

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.

Re:Cyber "security" is in the same boat. (1)

SpaceLifeForm (228190) | more than 5 years ago | (#25953549)

You can LART or hang a lot of Nazis with cat-5.

Unplug, and become a BOFH!

Agreed, Too Much Oversight Kills (5, Interesting)

cgifool (147454) | more than 5 years ago | (#25952699)

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.

Re:Agreed, Too Much Oversight Kills (2, Informative)

cgifool (147454) | more than 5 years ago | (#25952741)

Forgot to mention, morale is in the toilet, because after 2 years of effort we're about to release a new, fully standard-compliant version of the application with -0- new features, and even less compatibility with external applications than before.

Most people here have told me the only reason they have not left is because we'd never be able to get the same money or even half the vacation elsewhere.

Re:Agreed, Too Much Oversight Kills (1)

mdf356 (774923) | more than 5 years ago | (#25953023)

If you're talking about HAL...

I fired them because they weren't paying me what I was worth to them. I'm getting paid more now (but the benefits are less, so it probably balances out).

I did get to write a lot of code that skipped as much of the process as I could (mostly the parts outside my group; it still went through design and code reviews). I was one of those guys making constant, iterative improvements in the guts of my component, that had no "business justification" because the only thing it made better was future development and bug investigation. But in the process of that hacking I also identified dozens of real bugs that I wouldn't have found otherwise.

Re:Agreed, Too Much Oversight Kills (1)

ITEric (1392795) | more than 5 years ago | (#25953143)

It never ceases to amaze me that big companies put up the money to buy a productive company, then turn around and destroy the very processes that made the company productive in the first place. If all the company wants is a key product, why not just buy the product? Otherwise, leave the structure that made them an attractive acquisition in the first place alone and let them do what works. If anything, the processes should be incorporated to streamline the operations of the whole company.

Re:Agreed, Too Much Oversight Kills (1)

Surt (22457) | more than 5 years ago | (#25953635)

But, but ... they're a big company, they MUST know how to do things. After all, a big company never fails, but a lot of small ones do.

Re:Agreed, Too Much Oversight Kills (0)

Anonymous Coward | more than 5 years ago | (#25953459)

So.. Scuttle it. I'm sure you like your income, but aren't you sick of being someone else's Atlas?

Give them the crap that they want. dont test it. make it meet "standards" and fail at function. convince them that they can revise the way out of it.

As a programmer I want to avoid mistakes... (4, Insightful)

syousef (465911) | more than 5 years ago | (#25952773)

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.

Nothing changes. Really. (5, Interesting)

onescomplement (998675) | more than 5 years ago | (#25952849)

Paul, as usual, backs into the key argument.

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.

Creativity (1)

Vituperator (863044) | more than 5 years ago | (#25952941)

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.

Been there, agree with that (3, Interesting)

blake182 (619410) | more than 5 years ago | (#25953007)

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.

Re:Been there, agree with that (1)

Shados (741919) | more than 5 years ago | (#25953075)

Well, I was going to post something similar, but you put it in much better words than I could have!

Help wanted, male (0, Flamebait)

westlake (615356) | more than 5 years ago | (#25953063)

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.'

They may not want to work for you, but, in the present climate, that weekly paycheck counts for something.

Re:Help wanted, male (1)

JackassJedi (1263412) | more than 5 years ago | (#25953265)

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.

Mistakes can mean breakthroughs (3, Insightful)

mdrplg (680070) | more than 5 years ago | (#25953157)

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.

I don't care who wrote the article (2, Funny)

Joe Snipe (224958) | more than 5 years ago | (#25953267)

This sort of thinking does not justify the new userpage.

Split roles (0)

Anonymous Coward | more than 5 years ago | (#25953293)

Team 1 Conceptual development and ideas team

Team 2 Code monkey team (often outsourced)

Team 3 QA team (often outsourced to a different company).

With team 1 reviewing and guiding the work of 2 and 3.

Next question.

Master Oogway said it best: (1)

darth dickinson (169021) | more than 5 years ago | (#25953331)

"Many a man meets his destiny on the road to avoid it."

pure silliness (0)

Anonymous Coward | more than 5 years ago | (#25953423)

anyone else notice that the basic premise "that to get rid of checks we have more checks about what we make as checks" is an exponential growth of checks and not the limitation of checks in their own right.

Over simplified world modeling is the key (1)

kentsin (225902) | more than 5 years ago | (#25953851)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?