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

Comments

Perhaps

[Thelasko]

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

[Anonymous Coward]

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

[YourExperiment]

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

Re:Perhaps

[Anonymous Coward]

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

[Samschnooks]

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

[Anonymous Coward]

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

/irony

Re:Perhaps

[BlackBerry8700g]

Did you mean fast and loose?

Re:Perhaps

[k-vuohi]

Or fast and *whoosh*?

Re:Perhaps

[Pogue Mahone]

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

[Anonymous Coward]

/woosh

Re:Perhaps

[enjo13]

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

[postbigbang]

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

[ChromeAeonium]

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

[syousef]

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

[digitalhermit]

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

[brez180]

You *lose* at spelling.

Re:Perhaps

[andrikos]

But they gain good karma for their "insightful comments"

Re:Perhaps

[Anonymous Coward]

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

[mevets]

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

[andrikos]

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

Re:Perhaps

[sammyF70]

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 (and Reversi).

/em ducks

Re:Perhaps

[kybred]

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

[pe1rxq]

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

[OFnow]

(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

[ScrewMaster]

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:Perhaps

[ifdef]

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

[ScrewMaster]

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

[Anonymous Coward]

/woosh

/irony

Re:Perhaps

[SpaceLifeForm]

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

Re:Perhaps

[kbrasee]

/irony

/woosh

/irony

Error: Cyclic Dependency

Re:Perhaps

[Anonymous Coward]

/irony

/woosh

/irony

Error: Cyclic Dependency

/woosh

Re:Perhaps

[Anonymous Coward]

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

[Fulcrum of Evil]

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

[ChrisA90278]

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

[gnasher719]

(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

[FishOuttaWater]

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

[pintpusher]

ISTM that the "karma" system should be turned upside down. Those that produce quality code should have it lauded to the group at large. There should be great publicity surrounding the good code. Maybe have the team (and management? don't know) vote up the best code so that everyone knows about it. The reward is having your code announced as the best code of the week/library/project/whatever. Those who don't produce good code are motivated to do better so that they get the praise too...

Thus those top coders are *not* motivated to slack off, because if they do they don't get the notoriety and lose their reputation.

just thinkin' aloud

Re:Perhaps

[lgw]

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.

Re:Perhaps

[postbigbang]

Fools trade quantity for quality. Productivity without regimen isn't cost-effective in the end run.

Re:Perhaps

[DogAlmity]

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.

/irony


I think I'm starting to get the hang of this!

Re:Perhaps

[lgw]

While agreeing with you, I'd summarize it thusly: good code is easy to maintain. Great code is easy to support in the field.

The importance of good logging cannot be overstated, nor the importance of programmer-developed unit tests run before any check-in.

In the code itself, I'd add: good code minimizes dependencies, minimizes internal assumptions (design dependencies), and doesn't abstract or optimize at the cost of simplicity and clarity (the last is very hard for many devs to grasp). As Knuth said: premature optimization is the root of all evil.

Re:Perhaps

[lgw]

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.

Re:Perhaps

[postbigbang]

There's some truth to your logic. Productivity is key. Using components and techniques that enable productivity are good steps. Solving problems at the possible sacrifice of audit, scrutiny, and even safety aren't good ideas, however. I don't believe in slowing people down for bureaucracy sake. And I believe that some coders are basally more productive. Identifying them is good, but the basics of standards, QA checks, review, and audit are still necessary, and perhaps even mandated by law.

We all want the best for the moneys spent. But incredible coders that pass quality audits are still necessary; I've seen any number that don't, but sure look good on the surface.

Re:Perhaps

[RobinH]

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.

Re:Perhaps

[russotto]

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.

Wrong. Once the program is written, it has been explained in detail to the party which will be executing it. Namely, the machine.

If you want to determine the excellence of a program, you have to examine the program -- if not the code, then its behavior. The documentation tells you little. If you just want a check box for your corporate "excellence" program, however, go right ahead and examine the documentation.

Re:Perhaps

[Anonymous Coward]

*whoosh*

Re:Perhaps

[lgw]

My fundamental point is not that documenation and paperwork should be avoided, but that in some cases it's just a stupid allocation of resoruces to have certain developers do that work. In the old days, IBM would pair a tech writer with *every* programer, so that really good docs could be produced with a minimum of distraction to the coding. It's hard to know whether that produced the best code (though there's a lot to be proud of in 70s mainframe code), but it produced lots of *really* good documentation.

Re:Perhaps

[postbigbang]

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.

Re:Perhaps

[Anonymous Coward]

Companies that have the resources to go through this process are very lucky. Even so, code is as code does and the best way to invite "bad" code is to constantly put your development team behind the eight ball. HURRY UP! A sure fire way to get bad code even if it is "nicely written".

"Good code" among shoddy requirements, stupid deadlines and management pressure is about as effective as giving a hottie you dont know a hallmark card in the parking lot of the mall that says, "How delightful it would be if you laid in my bed and allowed me to very respectfully and with the utmost care probe your anus". Happy Anus Day!

Re:Perhaps

[networkBoy]

wow, a Beowulf cluster of /irony

Re:Perhaps

[PPH]

In a perfect world, that would be nice. But try working for a company hamstrung by process and held prisoner of the matrix org chart. The coders and testers don't interchange functions. They don't even work for the same chain of management. Same thing happens in engineering (non software) organizations. The Project people do the design. The Staff organization does the checking, analysis, testing, etc. necessary to comply with quality standards, federal regs, etc. Project hates Staff, because Staff keeps exposing Project's f*kups. Staff hates Project because they get all the credit for designs, innovation, etc. and they keep making the same idiot mistakes. Management says that the division is mandated by the federal regulator, but the feds could care less, so long as the company produces a QA plan and works to it. The reality is that one chooses one's career as a new employee and gets stuck with it due to the inter organizational animosity.

Gee. That certainly was cathartic. I'm feeling much better now.

Re:Perhaps

[networkBoy]

to wish I had mod points...
I really like igw's post http://developers.slashdot.org/comments.pl?sid=1047369&cid=25954607 about attaching a tech writer to a dev. While it may play to the primadonna set (in a bad way) there is some sense in getting those lone wolf types, especially when they have the combination of difficult to teach skills and the unteachable knack of genius for a particular type of problem you may have. I (senior tech) have been attached to such an engineer (hardware dev) who was simply a genius on analog design. His gut feelings for circuit design and layout were closer than most peoples second and third approximations for a PLL or transceiver. Downside was his documentation skills were essentially expressed by 1/(analog design talent). As a result a tech writer and I worked very closely with him when he was nearly done having him walk us through *everything*. I wrote the test plan and the Tech Writer wrote the docs. Worked great, even though he was a stuck up ass.
-nB

Re:Perhaps

[russotto]

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.

Doing that requires submission to the processes needed by others and being both courageous and disciplined enough to do so.

Courageous submission... wasn't that one of the Ingsoc slogans?

Re:Perhaps

[Anonymous Coward]

what's wrong with usb?

Re:Perhaps

[Anonymous Coward]

That's a great idea! Perhaps we should do the same thing with pilots and flight crews. When a plane drops out of the sky, then they have to start getting audited again. If no planes are dropping out of the sky, then we can let them skip all those checks.

Re:Perhaps

[Pogue Mahone]

Had to throw in the grammar nazi reference?

Yes, sorry, couldn't resist. :-)

Re:Perhaps

[ryry]

Do you make him write docs, or attach a junior programmer to him for that purpose?... somewhere up the ladder a software engineer's job becomes mostly writing docs (regardless of whether you go management or architect)

Really? Have you never heard of a technical writer? We write great documentation so developers don't have to :-)

Re:Perhaps

[Anonymous Coward]

Dontcha think.

Re:Perhaps

[mevets]

usb combines design talents of microsoft and intel. Have a look at it sometime.

Re:Perhaps

[pitchover]

perhaps in the future source code versioning will have this karma feature available :P

Re:Perhaps

[lgw]

Sadly, I've never worked at a job where the tech writers helped with design docs or other internal documentation - only user-facing docs. Small companies seem not to employ tech writers at all, more's the pity.

Re:Perhaps

[Anonymous Coward]

wow, a Beowulf cluster of /irony

Yeah, it substitutes Big Irony through power of parallelism!

Re:Perhaps

[Anonymous Coward]

by the federal regulator, but the feds could care less, so long as

For the love of $deity, its "couldn't care less" !

Yours sincerely,
QA.

Re:Perhaps

[Anonymous Coward]

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.

You talk like it is a bad thing... but I see where are you coming from. Modern trends in quality management actually goes at lengths to assure steady mediocrity over uncertain/occasional excellence (see ISO9001). It makes their job easier, predictable. In industrial environment, anything non-repeatable is a liability. They would be thrilled if they could obtain a program to churn out mediocre code without programmer intervention.

Place for code excellence is in CS academia, if anywhere. Even there, it will be used to make another set of rules and procedures to be forced upon everyone else.

Re:Perhaps

[VeryLargeNumber]

Yes, one mistake the first time and your bad karma never wears off. And you can't get over it no matter what code you write, because noone reads it anymore.

Karma sux.

Re:Perhaps

[redscare2k4]

Nor will any lack of documentation make excellent code poor; it merely makes it undocumented.

I disagree. The moment you need to maintain that code and make a couple little changes, undocumented code becomes a PITA and a drain of resources to upgrade and maintain.

Cos I assume you DON'T want to have that genius programmer doing maintenance tasks each time his code needs a minor adjustment, right? You want him doing new, interesting, profitable things.

Re:Perhaps

[Anonymous Coward]

It's not "its" it's "it's"!

Re:Perhaps

[SillyNickName4me]

What you express is the difference between what I'd call a 'code factory' and a 'tech company'.

The first doesn't produce technology, they implement it. For that, an industrial process is often very useful because of its predictability.

The later is the kind of company that actually gets us 'new' things, the results are not always easy to predict.

And I rather disagree with your statement about code excellence belonging in CS academia if anywhere. Any place where mediacore is not 'good enough' is a place for this, that includes many 'mission critical' applications, any place where getting those few % better performance is important (and don't tell me those don't exist, I work for one, and I know many examples of places where this can be a really big competative advantage), or any similar requirements.

What you describe is the method used for producing 'consumer' and 'commodity' software. Your process has no place outside those areas because it can never achieve the above mediacore quality required.

Attaching a real technical writer to a really good technical programmer however can quite do the trick. Its a bit more expensive, but it can easily overcome the mediacore barrier.

Not to mention, I am amazed by your 'one size fits all' kind of reasoning. Doing the same as everyone else is a guaranteed way of having a business that will only survive for as long as the market is good to excelent, or stuck on your standard due to cost of moving to something else. It will never ever survive in an environment where you actually have to compete on product quality, hence in the long term it is doomed.

This all isn't saying that documentation and QA is not important, but it is saying that there are many ways to achieve this, and that the result is what counts, and being stuck in one way to achieve this result is a sure way to miss business oppertunities.

Re:Perhaps

[MadKeithV]

/stack_overflow

Re:Perhaps

[MadKeithV]

Cool, that's a typical TOBAS* error.

(*Taken Out Back And Shot).

Re:Perhaps

[Aceticon]

The ability and willingness to use and produce documentation demonstrates awareness of the life-cycle of software and the need for ease of evolution, support and maintainability of software.

I don't care how fast you are at coding, if you're not aware that most of the time spent working in software is spent on post-release bug-fixing, performance improvements, new feature development and upgrading then you're not the expert developer you believe you are.

If you can't see that by not producing either a user manual or a technical manual, in the future people will need to reverse engineer to code to actually figure our the details of what the software does, then you're not the expert developer you believe you are.

If you're not aware that 5 months down the line after release, you or the poor sod that was brought to maintain the software you developed will struggle to fix/upgrade it because you didn't even documented the code, then you're not the expert developer you believe you are.

If you're not aware that over the life-cycle of a piece of software, the least documented code is the one that ages the fastest (as people change a badly understood piece of code it becomes spaghetti code faster and is hacked more often in strange ways), then you're not the expert developer you believe you are.

The only reason for a real Software Engineer not to document when given the chance is to create a situation where they become irreplaceable 'cause they're the only person that can maintain a certain application or system - hardly an ethical thing to do, although understandable in the current economic climate.

That said, as with everything there is a balance between documenting enough and documenting too much - too much mandatory documentation is just bureaucracy and a waste of time.

Re:Perhaps

[Chapter80]

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

/irony

/wooch

Re:Perhaps

[Thelasko]

Who performs the audits?

Programmers with good karma are selected at random. You must be new here.

Re:Perhaps

[greed]

IBM also had stringent specification and test planning requirements. An I0 begat the I1, the I1 begat the I2 and IT1, the IT1 begat the IT2. We usually cheated and called the code the I2 and automated testcases the IT2.

Even the brilliant 10x programmers--and we for sure had a few--got to go through the specification, design and review phases. Frankly, it doesn't matter _how_ brilliant the code is, but if it doesn't work with the rest of the product, we don't need it.

You actually wanted these guys looking at other specs and plans; they could point out things that other people didn't even know could exist and cause a problem.

That doesn't mean every line they wrote was gold; I remember one guy, you'd go ask him about something, and he'd look at the problem and code up a fix, and commit it, you'd say thanks and head back to your desk. By the time you'd got there, he'd committed two bug-fixes on his original commit--just because you thought he was done didn't mean he had stopped thinking about the code, or poking into the corner-cases that customers love to find.

Re:Perhaps

[Golias]

by the federal regulator, but the feds could care less, so long as

For the love of $deity, its "couldn't care less" !

Yours sincerely,

QA.

Usage defines language.

"Could care less" is a frequently-used sarcastic inversion, and is a legitimate expression to mean "I don't care at all" in American English.

Don't like it? Learn Espiranto, or some other language that isn't used enough for illogical-seeming quirks and exceptions to creep into it.

Re:Perhaps

[jmh224]

Whether you call it "karma" or discipline, or wisdom the point is well made. The worth of a thing is often reflected in what it costs. The cost for excellence is rarely as expensive as the loss for the problems caused by "good enough".

Re:Perhaps

[hesaigo999ca]

I code things much quicker and better managed then others around me, yet when they ask me for analysis on paper, I tend to give them less then par documents. It's not for me to start trying to "sell" myself or the code or the project to them, I just have to let them know what I think, yet someone else who does a great job doing this gets more credit then i do, because they were able to write up nicer documents using powerpoint or word. Seriously, I have no problem, with having someone assigned to me to get my point across on paper, when all I need to do is change over the fault tolerance of a server in code in less then 6 lines because of space constraints. The guy can do all the bells and whistles he wants, Ive already solved the problem by the time he is finished making things look pretty.

Re:Perhaps

[jgrahn]

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?

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.

Re:Perhaps

[jonaskoelker]

Code reviews for the win, absolutely.

They don't do everything, though.

They don't tell you why the code was written as it is, or why the code is good.

This can be remedied by good comments. A very interesting remark by one of my lecturers is that cache-oblivious algorithms are competitive against IO-algorithms. Submitting your cache-oblivious disk sorting program for review would require comments as to why you chose the cache-oblivious algorithm over the IO one (explanation below).

But there's more to being a good programmer than knowing how to write a piece of code well. There's also knowing which code to write, and which code not to write.

The decision to write the reviewed code may be obvious, say "this feature is on the checklist", but it may also not be. It may be a good to split your application into a server and client, and have a library for talking to the server used both by a command-line tool and a GUI tool, but none of the code that implements this decisions talks about why the decision is good.

Most importantly, there's knowing what code not to write.

In synergy2, there's a function that's given a list of rectangles in the plane and wants to find an intersection. The current implementation has two for-loops and "// XXX O(n^2)". For the fun of it, I implemented a line-sweeping algorithm that did the same thing in O(n log n) time. No matter how I tweaked the parameters (including adding lots of very small rectangles), I couldn't make the damn line-sweeper faster than the trivial algorithm. I would never submit that for review.

And that's a damn shame. The hypothetical reviewers would learn some important lessons: that theoretically better algorithms aren't always better in practice, and that you should always measure time when you optimize for it.

[You may say "yeah, but we all know this"; as a response, I would ask: do you? Do you always measure? Do you do the comparisons? Knowing something and putting your knowledge to use is two different things.]

Back to the line-sweeping example: I think it would be useful to have a practice of "submitting for rejection". That is, go through the review process, commit the code to your VCS in a branch of its own, and mark the branch as "rejected". That way, your knowledge of what doesn't work (well) is stored in the VCS, for you to refer to when people who don't read it suggest implementing old ideas. In the ideal world, people would also read the rejected commits and the comments stating why it's submitted for rejection ;)

Of course, not everything should be submitted for rejection; a good rule of thumb, I guess, is that the code should work correctly, but not desirably.

Re:Perhaps

[jonaskoelker]

They can be docked karma that way[...] they can cover their asses

Is that why they call it Dock and Cover?

Re:Perhaps

[svank]

/[svank@slashdot /]$ ./thread
^CTraceback (most recent call last):
    File "./thread", line 403, in
        dead_horse.beat()
KeyboardInterrupt

Re:Perhaps

[jonaskoelker]

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.

That depends. A requirement that all committed code should build from a clean checkout and should pass all unit tests is perfect for automation. It's also a fairly reasonable requirement.

What's the cost? (See, I read the article, learned something new, and applied it straight away.) Developers have to wait for the build-and-test cycle to run between successive commits. If I have two distinct commits that I want to commit at the same time, I have to queue them up, and wait and see if they pass. If my commits get rejected due to a test bug, I have to file a bug against the test, get it disabled, and commit again.

Could the cost be cut down? (as an addendum to the article: ask how much you can cut the cost while still getting most of the benefit.) Possibly.

Accept all commits up front and pull them back out when tests fail; send me a mail letting me know this. Cache the test results, such that if the only change is the removal of a buggy test, the commit goes through straight away.

If you commit on top of my test-pending commit and mine gets pulled out, the tests should automatically run on your commit against the code with my changes backed out. If it goes through, commit it automatically. (This works well for linear progress; I'm not sure exactly how it would work for merges.)

Re:Perhaps

[jonaskoelker]

/riony

Re:Perhaps

[ebuck]

You're for loop was kicked back, -1 flamebait!

Next time don't use the index variable Adolph, and stop incrementing by the constant SIEG_HAIL.

Re:Perhaps

[lgw]

I make no argument that code should not be documented. There's room for specialization however. For example, I've worked with several competant coders who spoke very poor English. The team would ensure documentation during code review. When working on a time-critical project leading an extremely productive developer, I simply did all of the docs myself and kept him free to code.

The ability to write *good* design docs before coding begins is a remarkably rare skill, which I guess is why "architect" is a specialty. The job of producing good header files and other as-you-go docs can be done just as well by the code reviewer as the coder. And please, please leave the job of writing user-facing text to tech writers! The overlap between good coding skills and good English prose skills is quite small indeed.

Re:Perhaps

[lgw]

If only one person understands the code being written, you're already doing something wrong. Useful docs can be produced by code reviewers, or by otherwise-useless technical management types.

And, back to the point of TFA - merely letting someone other than your top coder do the "MS Word document full of boilerplate crap just to make the process people happy" can double the productivity of your team at a large company. Not having the crap to begin with would be better, of course, but as TFA points out, large companies have that crap for a reason.

Re:Perhaps

[jafac]

. . . nice. I just wish that I had been through A SINGLE code review in my entire career, where everyone didn't fall asleep. Just ONE!

Re:Perhaps

[kybred]

. . . nice. I just wish that I had been through A SINGLE code review in my entire career, where everyone didn't fall asleep. Just ONE!

Oh, wait... maybe that was a dream I had while sleeping through a code review. :-)

Re:Perhaps

[Anonymous Coward]

Some time ago people frequently expressed the thought that the earth was flat and the sun circled around it.

That didn't make it right either.

There's no such thing as "sarcastic inversion", "couldn't care less" is sarcastic by itself and "could care less" is just the lazy version of it.

Don't like it? Well just keep using whatever version you want... it's not like anyone's gonna get hurt by it... and it's *YOUR* language, after all ;-)

Re:Perhaps

[Hognoxious]

Usage defines language.

Usage doesn't define correct language, you kredgid jarwepper.

A fine balance

[pwnies]

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.

Re:A fine balance

[Anonymous Coward]

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

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

[Anonymous Coward]

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.

Re:A fine balance

[Chandon Seldon]

The checks are there for people who write code seen on http://www.thedailywtf.com/

At a small company, it's frequently possible to find those people and stop them from writing any more code.

Let it be known that your software is flawless

[Anonymous Coward]

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.

Re:Let it be known that your software is flawless

[Z00L00K]

You will be amazed how much bad code and how many bad working habits there exists out in large companies.

It's not surprising that there are those that calls for more stringent methods of testing and analysis of code.

But coding a solution is only part of a bigger problem. Managers wants to be in control, and the larger the company is the more layers it has to provide for (generally dead meat) and the tighter the bulkheads between the departments. This means that there is more need for advanced processes in a larger company than in a small. Further there are a lot of slack in the process from decision to the issue of the task in a large company. This also means that the time left to do actual coding is sometimes really cut down to almost nothing.

It's somewhat like piloting a supertanker. You have to plan the turn long before it's time to turn. And you can't stop when you see something ahead - it's too late.

But to write software that's reliable and with as few bugs as possible it's also important to educate the developers in various methods of keeping at least the simple bugs at bay. It's not that hard to avoid compiler warnings. Using tools like FindBugs and PurifyPlus are also very useful.

It's official

[Anonymous Coward]

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

[Anonymous Coward]

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

More checks!

[I.M.O.G.]

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!

[naetuir]

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!

[Retric]

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!

[gatesvp]

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!

[GravityStar]

Management will then ask the programmers to do the verification.

Re:More checks!

[Fulcrum of Evil]

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. But why are you talking about production lines in the context of software?

Re:More checks!

[orkysoft]

The bureaucracy is expanding, to meet the needs of the expanding bureaucracy.

Re:More checks!

[chthon]

Well, as a build manager in a certain large European electronics manufacturer, I can say that we indeed do have a software production line.

It consists of 5 steps :

1. Problem report and change request dispatch
2. Software development
3. Nightly builds
4. Testing of nightly builds
5. Releasing of nightly builds after testing has found them OK

Re:More checks!

[Fulcrum of Evil]

That's not a production line - production lines produce large numbers of similar items, which you almost never do in software.

I have mixed feelings.

[Samschnooks]

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.

Re:I have mixed feelings.

[russotto]

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.

Annoying, but easy to handle. Testers love to find bugs, whether it be for the joy of crushing a young programmer's spirit, or for the look of fear in the eyes of the product manager as the release date approaches. Point a tester towards the bug, and he'll go right ahead and write a defect, possibly cackling evilly as he does so.

Re:I have mixed feelings.

[jonaskoelker]

Testers love to find bugs, whether it be [...]

It could also be because they want things done right. I've spent some time finding memory management bugs in a piece of open source C code; it was a good way of getting to know that piece of software, and I felt some kind of satisfaction knowing that I've made the program better.

[I also found some non-memory-management bugs in the process; they weren't expressed without my changes due to luck and the way malloc works].

I've also reported a fairly large amount of bugs against compiz in a short amount of time; they're not causing breakage or anything, it's just that little extra polish that makes software nice to work with.

Death March

[micromuncher]

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

[Retric]

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

[story645]

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

[Anonymous Coward]

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

metrics == management

Re:Death March

[Retric]

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

[Anonymous Coward]

Yeah, but your one of teh idiot's.

Re:Death March

[skribe]

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

[wideBlueSkies]

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.

Re:Death March

[GravityStar]

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

[ifdef]

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

[Anonymous Coward]

True, that's why I became your manager.

Re:Death March

[Anonymous Coward]

Good advice, but I don't see how that relates to what the GP wrote.

The interesting part of the discussion is what is a bad coder and what is a bad process.

I would say when you think tests are a bad process you definetly are a bad coder. And given your clever advice I would fire you.

Re:Death March

[tomhudson]

A good coder should enjoy their work enough that they can help bring others up to speed. Everyone benefits. The good coders benefit from better communications with their co-workers, as well as knowing what can and can't be handed off to others, and how much supervision they'll need.

Projects don't fail because of bad coders. They fail because of mismanagement, poor resource allocation (the biggest problem being time constraints), lousy communications, lack of trust, and a willingness to take shortcusts "just this once."

Besides, it's a real ego boost when a former co-worker tells you that they really learned a lot working with you. Makes you feel good having done some good in the world. Sure beats the usual "pissing contests" that go on all too often.

Good. Fast. Cheap. Pick ONE. The person who said "Pick two" was an optimist.

Re:Death March

[Anonymous Coward]

Apparently on average it takes 1 years salary to recruit, induct, etc a new staff member.

Karl

Re:Death March

[PMBjornerud]

Programmers, though, like it better when they write more code.

I clearly prefer to write less. Noting better than cleaning up code and ending up with deleting a third of it while making it work better than before.

The premise...

[Anonymous Coward]

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

Please don't hit me, signed sysadmin ;)

...Perhaps the author is a little biased?

[Zakabog]

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?

[cowscows]

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?

[sleeponthemic]

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?

[evil_aar0n]

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?

[ifdef]

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

[Anonymous Coward]

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?

[ifdef]

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?

[Matthew Weigel]

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?

[Anonymous Coward]

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.

Re:...Perhaps the author is a little biased?

[Anonymous Coward]

To me, it's weird that you would separate programmers who enjoy doing the job away from career programmers.

By career programmer I mean someone who is only programming because they heard it would bring them lots of money. I don't mean someone who is doing it as a career. There really are people out there who know nothing about computers and became programmers because they knew it could bring a big paycheck. A friend of mine was like that, he never saw a point in programming outside of work or school. When he needed a program to do something small, I tried to convince him to write it himself just for practice, he just asked why anyone would want to program for fun.

obviously

[nine-times]

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

[Anonymous Coward]

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

[GravityStar]

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

[alexander_686]

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

[tmarthal]

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.

Re:Black Swans

[alexander_686]

Well, I am an internal resource tackling internal problems. So, yes, completion is limited. The point that I wanted to get across is that if you have read what Paul Graham has been writing over the years, his advice has been simple. Start small, lean and hungry. Get something - anything - out fast. Experiment. Get feedback from your clients. Improve. Mistakes are o.k. Better to make dozen of mistakes, get honest feedback, and improve. If you have something worthwhile, the early adopters who need it will stick with you if you have a truly innovated idea. In this case, black swans, rare events, are good. The more black swans you have the better. Most will blow up. One will be a home run that pays for the rest. This does not always work. My "Customer" is the IRS - which requires a single complex report once a year. It needs to be perfect. It needs to tie out multiple different ways. The IRS does not care about innovation. You can extend this to a host of other industries where failure is not allowed. Banking [my industry], Aircraft, Medical, etc. Here, black swans must be killed. Now, that being said, we have outsourced a lot of our software. We don't compete on having the best software, we compete on having the best products. software is a utility for us.

Cyber "security" is in the same boat.

[Mesa MIke]

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.

[SpaceLifeForm]

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

Unplug, and become a BOFH!

Agreed, Too Much Oversight Kills

[cgifool]

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

[cgifool]

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

[mdf356]

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

[ITEric]

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

[Anonymous Coward]

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.

Re:Agreed, Too Much Oversight Kills

[Surt]

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

[/dev/trash]

Piss poor reason for staying around. remember the highest paid do nothings for a company get laid off first.

Re:Agreed, Too Much Oversight Kills

[Anonymous Coward]

Sounds almost like you are talking about my company.

We have not been acquired, just some investors decided to push the management to "optimize the process" to be more "market-driven", "JIT", "ready-for-customer" and some other stereotypical marketing bullshit. The methods to do that were what the "controlling is everything" consultants told them, i.e. pervasive tracking of work hours and accomplished tasks, enforcing a crippled version of Feature Driven Development (i.e. clueless managers talk about feature lists and how the new icons should look in 80% of the time before we can start the development work), replacement of all established work-flows with uber-hyped technologies; e.g. replacing good OpenSource VCS with an expensive commercial one (P...), forcing everybody to switch and spend many manweeks dealing with its quirks and changing everything to work around its limits.

Result: the new release is much worse (feature- and quality-wise), the development cycle was not shorter, a lot of developers left the company RSN after facing all that PAIN and stupidity. The remaining colleagues are permanently pissed and either borred by stupid tasks or are close to burning out.

Re:Agreed, Too Much Oversight Kills

[mabhatter654]

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.

Re:Agreed, Too Much Oversight Kills

[Anonymous Coward]

There are no standards in software. Period. Your description is one of being railroaded and ass punched. Find a better job.

Re:Agreed, Too Much Oversight Kills

[Anonymous Coward]

IBM or SAP? I can tell you from personal experience that the latter is exactly as you've described. It's not a very satisfying place to be an engineer.

Re:Agreed, Too Much Oversight Kills

[ITEric]

*grins**nods*

Right! That's why so many companies are asking for that bailout money...they're not BIG enough:)

Re:Agreed, Too Much Oversight Kills

[dcollins]

Lesson #1 I learned as an engineer: When your company gets bought, go. Go as soon as possible. The principals know this (leave the day after they're contractually allowed).

Other lessons: When your bank gets bought out, go (as soon as possible). When your doctor moves away and hands you off to a partner, go (as soon as possible). Generally whenever decisions get handed to a body you didn't initially make an agreement with, you need to go.

Re:Agreed, Too Much Oversight Kills

[Anonymous Coward]

"Then we got acquired by a giant 3-letter company..."

May I guess? It should be HP or Dell...

Re:Agreed, Too Much Oversight Kills

[Anonymous Coward]

Perforce really is *significantly* better than CVS. It does branching and merging *well*, and it does atomic commits. You might want to reconsider disliking this particular change.

Re:Agreed, Too Much Oversight Kills

[Anonymous Coward]

It's funny how many companies are actually shooting themselves in the foot because they're too damn risk adverse. There's actually a huge talent pool out there that they could tap into, but since they only seem to desire experience over all else, they're never going to see any excellence. (Especially when they want experienced people for what should be starter positions.) If H.R. wasn't so damn afraid of hiring TFNG-types for their company, they might have more chance of getting innovation or insight that could be beneficial in a downturn economy.

But then again, this comment is coming for a guy that's been posting resumes at job sites for longer than he has actually worked since graduating college. So I'm not sure how relevant my opinion is...

As a programmer I want to avoid mistakes...

[syousef]

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.

Re:As a programmer I want to avoid mistakes...

[raw-sewage]

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

I added emphasis to ask the question, why not? Granted, no one wants to be the person whose slight goof caused a major problem. But if your little mistake can truly have such massive repercussions, then you are either (1) in way over your head or (2) in a position of high responsibility (which should imply high pay).

My job consists of writing code that provides algorithmic trading logic connectivity to the exchanges on which we trade. The programs simply have to be right; a slight error can cost us lots of money (missed executions, sending orders at the wrong price, sending too many orders, etc). The "team" I'm on consists of one other guy and myself. Somewhat to my chagrin, we basically work independently. My previous position (at another company), while not perfect, at least had team-based collaboration: the little "gotchas" were harder make it into production, only because there were more eyes looking at the product.

I've lamented this situation considerably; the whole "no-one-is-looking-out-for-me", or "release-and-hope-for-the-best" method of development. I'd like to think that I'm at worst an average programmer, but I recognize that even the best programmers make mistakes. Certainly I'm no exception to this rule of humanity. But such is life; the upside to all this is that I'm making more than I would in pretty much any other development role. This "it's all me" approach, combined with the facts that it's very hard to test these applications, while stressful, has made me a more cautious, careful coder. I'm slowly getting better at running test cases in my head. And I'm making bank.

So... long story short, if you're at a position where a little mistake can have massive repercussions, it may be an opportunity to grow as a developer and/or make more money.

Re:As a programmer I want to avoid mistakes...

[syousef]

I added emphasis to ask the question, why not? Granted, no one wants to be the person whose slight goof caused a major problem. But if your little mistake can truly have such massive repercussions, then you are either (1) in way over your head or (2) in a position of high responsibility (which should imply high pay).

If it's THAT important to the company I should not be the only one testing my code. I do not want to be the fall guy, because for the product to get into production I shouldn't be the last and only line of defence.

What you're implying is that there exist people out there who are capable of writing perfect software, and that those who can't are either way over their head or irresponsible. That's just a boat load of bullshit.

Writing code is, quite fortunately, not a real time activity like say brain surgery or piloting an aircraft. ie. a mistake made in real time (like a typo) can be picked up later when you're coding, whereas if a pilot makes a mistake people die right away. The flip side is that a pilot or brain surgeon gets immediate feedback if they make a mistake, and if they've planned well will often have a chance to correct in real time. A coder may not even realize the mistake has been made until years later when an obscure corner case crops up in production.

My job consists of writing code that provides algorithmic trading logic connectivity to the exchanges on which we trade. The programs simply have to be right; a slight error can cost us lots of money (missed executions, sending orders at the wrong price, sending too many orders, etc). The "team" I'm on consists of one other guy and myself. Somewhat to my chagrin, we basically work independently. My previous position (at another company), while not perfect, at least had team-based collaboration: the little "gotchas" were harder make it into production, only because there were more eyes looking at the product.

If your company wants to take the risk of having critical software written by a team of 2 guys, that's their choice. Regardless of how good you are at some point mistakes will occur and something undesirable will make it into prod. I work on critical code too. The difference is we have a team of programmers who write and unit test and a separate test team who write their test cases based on business specs having never seen the code. I still lose sleep over it. No matter how good your testing procedures are there's always room to improve them and always something that could be missed that would make the difference.

So... long story short, if you're at a position where a little mistake can have massive repercussions, it may be an opportunity to grow as a developer and/or make more money.

Not if you work in a culture where your first mistake sees you fired with a reputation as a developer whose incompetence led to the downfall of a system.

The only saving grace is that its your company that's made the choice to be in this position, not you. You should make sure your bosses are aware of this.

Nothing changes. Really.

[onescomplement]

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

[Vituperator]

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

[blake182]

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

[Shados]

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

Re:Been there, agree with that

[Anonymous Coward]

I'm in the middle of exactly what you describe. The big problem with small successful startups is that they don't scale.

As soon as you start adding more programmers you dilute the talent pool. Management responds by increasing project management and QA in a mad rush to mediocrity. Somewhere along the line the top programming talent leaves in frustration.

Re:Been there, agree with that

[Anonymous Coward]

you're so awesome man!

I wish they developed the space shuttle that way.. they'd save so much money if they only had a few competent engineers that never made any mistakes!!

Wow.. I really feel stupid now.. I always thought that bugless code was hard to do.. but it turns out that I just suck at programming. It turns out that most programmers NEVER create bugs and their code JUST WORKS the first time.

Paul Graham is a genius, lets ditch all those useless QA people!

Help wanted, male

[westlake]

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

[JackassJedi]

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

[mdrplg]

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.

Re:Mistakes can mean breakthroughs

[misfit815]

I've worked for both types as well, and I've become convinced that all organizations lie on a continuum. At one end is a guy in his basement writing the next Napster. At the other end is a publicly-traded Fortune 500 making products for the automotive, financial, and pharmaceutical industries. There's a "sweet spot" somewhere in the middle, but most organizations sail right past it on their way to a bureaucratic nightmare.

I'm also convinced that the sweet spot can never be hit once you fall under Sarbanes-Oxley, 21 CFR Part 11, or QS-9000.

J

I don't care who wrote the article

[Joe Snipe]

This sort of thinking does not justify the new userpage.

Split roles

[Anonymous Coward]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Master Oogway said it best:

[darth dickinson]

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

Re:Master Oogway said it best:

[MoFoQ]

"One often meets his destiny on the road he takes to avoid it."

Re:Master Oogway said it best:

[darth dickinson]

Yeah, that :) Our work proxy was having issues and I couldn't get to IMDB to get the exact quote.

pure silliness

[Anonymous Coward]

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

[kentsin]

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.

Re: loose karma

[macraig]

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

Don't forget opportunities to redo stuff

[Lonewolf666]

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.

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.

Re:Don't forget opportunities to redo stuff

[mabhatter654]

that is the difference everybody keeps trying to put a finger on. It's the artist that wants the code to be "right" for it's own sake... the businessmen just want it done so they can sell it.

Re:Don't forget opportunities to redo stuff

[Lonewolf666]

Exactly. But there are degrees of unpleasantness and stupidity. Back to topic:
Process used to make things slower and was sometimes annoying, but it also helped to structure things and find bugs for release. So it was not all bad. Doing something completely unrelated instead of making the code "right" was much worse.

Real Talent?

[ClosedSource]

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.

Re:Real Talent?

[lgw]

No, there really are programmers who are 10x as productive as "normal", and of course programmers who contribute negatively. You'll know either extreme when you work with one.

Boss: we've had a team of 5 on this problem for a couple months now, and they're way behind - could you take a look?
Dev: sure, give me a couple of weeks.

Two weeks later.

Boss: so, can how's that project going?
Dev: oh, I'm done.
Boss: Done? Great - what was your analysis; how can we speed things up?
Dev: No, no, I'm done with the project. The approach that team had was crap, so I just did it right. I'm running my unit test now, but it looks good so far.
Boss: -speechless-

You may not believe it until you work with someone like that, but they're out there (and large companies do a terrible job of retaining them - as Paul Graham suggests, the main thing devs like that want is to not have obstacles to their productivity).

Re:Real Talent?

[ClosedSource]

"No, there really are programmers who are 10x as productive as "normal", and of course programmers who contribute negatively. You'll know either extreme when you work with one."

This is the most common programming myth of our time. We don't have any comprehensive definition of what "productive" means when applied to programming yet we know that some are 10x better at it. Or is it 30x? Or 100x? I've heard all of these figures claimed with no real proof.

Why when it comes to methodologies and productivity we drop out of objective programming mode and accept wild claims without proof simply because it gives us an ego boost. It's really a negative boost anyway - raising ourselves by pushing the other guys down.

Re:Real Talent?

[lgw]

I know what "productive" means. Knowing that is part of my job. "Productive" is delivering features in a maintainable, supportable way, per unit time. Sizing features and defining "maintainable" and "supportable" in terms of concrete rules and best practices is a large part of the skillset of a very senior engineer. Finding the hyper-productive programmers and twisting management's arm to retain them at all costs is another.

Again, the 10x developer sounds like a myth until you work with him -- I'd say it's the top 1% -- but 3x developers are common. The "contributes negatively" programmer is someone you've met, though the hallmark of bad management is to encourage that guy to work more.

There's a reason that "real" engineering companies have fellowships and Distinguished Engineer titles to recognize, empower, and retain the top 1% engineers on other fields.

Re:Real Talent?

[Chandon Seldon]

What's your contention, that there's no such thing as skill or ability and anyone who's been sufficiently trained to perform a task is equally good at it? If so, that's obviously bullshit.

Re:Real Talent?

[Nefarious Wheel]

Boss: so, can how's that project going?
Dev: oh, I'm done.
Boss: Done? Great - what was your analysis; how can we speed things up?
Dev: No, no, I'm done with the project. The approach that team had was crap, so I just did it right. I'm running my unit test now, but it looks good so far.
Boss: -speechless-

You may not believe it until you work with someone like that, but they're out there (and large companies do a terrible job of retaining them - as Paul Graham suggests, the main thing devs like that want is to not have obstacles to their productivity).

Oh my yes, that happened to me almost verbatim. I'd outsourced 3FTE x 4 weeks to a team who let me badly down -- they spent their dev money trying to invest in their own answer to CSS, instead of what I'd contracted them to do. The aftermath of that was rather ugly (mostly for them. Let's just say not all lawsuits are frivolous.)

However, in the mean time, I took the best of our contractors and asked if he could work back a bit and see if he could bring that part of the job back in house. It was very non-trivial, many and complex functions. He worked the weekend and finished the entire piece of work and the sucker worked flawlessly. I wasn't able to bring him on full time (he wanted to remain a contractor) but we became good friends afterwards and he's seriously way up there on my anti-trouble list.

Yes, there really are people that good out there, who can generate perfect code as fast as a fast typist can type. I think he has trouble finding the right sized hats. Documentation? I didn't really care, my arse was out of the fire, and we came in just $500 under a rather large budget. I told him I would do anything possible to keep people off his back before he started, and he definitely appreciated that.

Re:Real Talent?

[ClosedSource]

The flawed arguments just keep on coming. Is there nothing between 1x and 10x in your thinking? Of course some people are more skillful than others, but when you state numbers over 3X its starts to push common sense.

If I told you that I developed a new sorting method that is 10x faster than any known method, would you accept it on faith or expect some proof? Why should we get sloppy about these productivity claims?

Re:Real Talent?

[ClosedSource]

"I know what "productive" means. Knowing that is part of my job. "Productive" is delivering features in a maintainable, supportable way, per unit time. "

Maintainability can't really be determined during initial development, you have to wait until maintenance actually begins on a released product. Do you evaluate a project years later and trace its maintainability back to the individual programmer? If you do, you're certainly on the leading edge because I've never seen that done in my 20+ years of experience.

Re:Real Talent?

[nonsequitor]

You can engineer maintainability. You won't know how successful that effort was until after the maintenance is performed.

Good clean design with tight cohesion, loose coupling, and all those other best practices that were invented over the years can be applied to achieve high internal code quality. Of course if you have a monkey write something as fast as possible and start shipping it as soon as it appears to work, you will pay through the nose later when it comes time to build on that initial code base.

Re:Real Talent?

[ClosedSource]

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

Re:Real Talent?

[ultranova]

Again, the 10x developer sounds like a myth until you work with him -- I'd say it's the top 1% -- but 3x developers are common.

If 3x developers are common, then what is the baseline you are comparing them against ? The very worst programmers ?

The "contributes negatively" programmer is someone you've met, though the hallmark of bad management is to encourage that guy to work more.

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

There's a reason that "real" engineering companies have fellowships and Distinguished Engineer titles to recognize, empower, and retain the top 1% engineers on other fields.

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

Re:Real Talent?

[lgw]

Maintainability damn well can be designed in from the beginning! Knowing how to do that is one reason I'm surviving the "up or out" world of older software engineers. Of course, you can't measure maintainability if no one on your staff has ever maintained a successful commercial product with a 10+ year old code base (or better, several for different companies with different cultures), coupled with enough years of personal experience with what works and what doesn't, but there are plenty of such fellows out there, and some of us even remember how to code.

Re:Real Talent?

[lgw]

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

Re:Real Talent?

[lgw]

Yes! The "he finished it over the weekend" stories are the hallmark of the few great programmers out there.

Re:Real Talent?

[donscarletti]

A 10x multiplier means that a really good programmer can solve a problem in an amount of time that a team of 10 average programmers could solve it. This is not unlikely at all in my reckoning because the thing that you are forgetting is that programming skill doesn't scale linearly. A team must discuss, debate, divide and delegate the problem so that the individuals in it can each cover a part, often with either overlaps or gaps, because it evolves the solution becomes far more complex and it causes even more problems for the group to understand. If a single individual can understand an entire problem this means that they can create a solution that covers the entire breadth of it in a single directed effort, the solution will be simpler (if they are truly good) and can be completed faster.

The problem may only be a tiny bit too big for an average developer but that can be the difference between understanding and misunderstanding. Humans may be all quite close to each other in intelligence, but a tiny difference in brains can make a huge difference in the final applications. Good developers aren't ten times as smart as an average developer, but they can still outdo ten regular ones in productivity.

Re:Real Talent?

[SillyNickName4me]

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

May I point out that for example IBM has quite a few 'software engineers' that have the IBM follow title? And the same applies at for example HP. So this is definitely not limited to 'physical engineering'.

I've been reading through many of your posts in this discussion. Many of the things you say are true in certain kinds of environments, but definitely not true in other environments.

I find the 'one size fits all' kind of reasoning you express rather disturbing, 'one size fits all' is a well known management trap that inevitably results in (long term) failure. Yes, it makes management easier, but it makes your competitive position a lot worse in any market where perceived quality plays any role (that is, where the perception of the customer of delivered quality is important)

Re:Real Talent?

[MadKeithV]

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.

Re:Real Talent?

[ultranova]

I've been reading through many of your posts in this discussion.

That's a pretty impressive feat since this is my second post in this discussion.

Re:Real Talent?

[SillyNickName4me]

whoops, me bad. Was following the posts from someone else (closedsource) who was using virtually the same argument, and failed to notice the name above your post.

Re:Real Talent?

[SillyNickName4me]

If I told you that I developed a new sorting method that is 10x faster than any known method, would you accept it on faith or expect some proof? Why should we get sloppy about these productivity claims?

No, but if you claimed you on your own implemented some very complex system in less time then a competing group of 10 programmers did, I'd at least consider it possible.

Not to mention, you are comparing apples and oranges. 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.

Re:Real Talent?

[ClosedSource]

Certainly there are cases where the nature of the problem doesn't lend itself well to a group effort, but that has nothing to do with a particular individual's productivity.

Re:Real Talent?

[ClosedSource]

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

What happened to the 10x? is it 5x now?

Re:Real Talent?

[ClosedSource]

Yes, and all the experts of the era said the Titanic was unsinkable. There's nothing wrong with designing for maintainability but you still have to measure the real-world outcome if you are serious about it.

Re:Real Talent?

[G00F]

"Of course, if programmers who post on Slashdot were representative, we must all think we are über-programmers."

No no, I fully admit I can only do script level of programming.

Re:Real Talent?

[lgw]

Do you evaluate a project years later and trace its maintainability back to the individual programmer?

I've been doing for most of my career. All you have to do is work on production code that's more than 5 years old, and look at what's painful to maintain and what's easy to maintain. How else do you form your personal best practices? Once you have the experience, you can evaluate the maintainability of code as it's written. Similarly for supportability, which requires years of experience fielding crashes from the field to develop the right best practices there.

Sadly, university programs seem to pay so little attention to these areas that I have to fight to convince junior programmers that they even *exist*. Of course, forcing those guys to do nothing but maintenance and support code will teach the lesson, but these days people just quit if you ask the to do real work. :\

Re:Real Talent?

[lgw]

I wasn' thinking of code that's 10x as fast at all when I started this thread. That's a totally different topic.

I have implemented a complex project in 1/10 the time with a smaller team - just this year in fact. And the first team never did finish - we had to give up and fire them all with very little time left in the project, forcing the "1/10th time" deadline as we only had 2 months remaining in a 20 month effort (OK, we could only get away with slipping 2 extra months on a "12 month effort" that was already 18 months old, but the point is the same).

Re:Real Talent?

[ScrewMaster]

Maintainability damn well can be designed in from the beginning!

I agree, it most certainly can. Seriously, what is the point of a clean, well-engineered design, if you're not attempting to build a solid foundation for future work? Why not just crank it out any old way so long as the spec is met? Rhetorical question.

Learning how to code for maintainability up front is more a matter of experience (having been burned enough times by not having done it, and tried enough possible solutions until you've found those that work) that it is talent. It's also something that many programmers I've worked with over the years (almost three decades at last count) deem unnecessary, because they honestly don't know how. That, and the fact that thinking about maintainability requires actual forethought, as well as some extra bureaucratic/recordkeeping overhead. If you're not planning on being around for more than a few years in a given job, and don't give a flying fuck about the poor bastard down the line, then why waste a neuron on maintainability? That's how a lot of people look at it, I'm afraid.

I ran my own software business for, oh, fifteen years or so. I started out not concerning myself about maintainability because I was only worried about delivering the product on time. Then, after being in business for a few years and having to maintain my own code I changed my tune pretty quick. I mean, I got really tired of asking myself the same question over and over: "what the hell was I thinking?" And I mean that literally: when the code was written, what was I thinking? 'Cause it wasn't always obvious from the code itself, and I wasted a lot of time refiguring things out from scratch. Wasted even more time refactoring code because I hadn't bothered to think ahead, either. Now to be fair, I wasn't very experienced then and didn't really know what kinds of things for which to plan. That excuse doesn't wash anymore, I'm afraid.

Right now I'm responsible for several hundred thousand lines of code much of which is over a decade old. If you don't constantly work towards maintainability in an environment like that, you'll founder quickly. Matter of fact, several years ago I went through a major refactoring of that codebase (took a couple of months) just to make it into something that could be dealt with, long-term. Nobody had bothered until that time: the damn thing just kept growing like some amoeboid monstrosity. Reorganizing that project was a thunk of gruntwork that I don't want to ever have to do again, but I did it because not doing it was even more frustrating.

I used to talk to myself a lot more back then.

Re:Real Talent?

[lgw]

You know, there's a real culture change in our field. When I got into software development (back when mainframes roamed the Earth on the backs of dinosaurs) you didn't become a programmer unless you "had the religion". It was a very anti-social sort of career, and there were better paying engineering degrees, so you did it becuase you lived to code.

Now in India being a developer pays better than being a doctor or lawyer, and puts you at the top of the social ladder. Last summer I asked our three interns (all India, naturally) why they got into this career. I was amazed when all three replied "my parents chose it for me". I guess that's no different from kids being bullied into becoming doctors or lawyers in America.

But it's a real challange as a leader. It used to be you'd give people interesting (and hard) work as a reward. Now, not so much. And what's worse, doctors and lawyers expect to get shit work for the first few year - it's seen as a rite of passage. Developers *need* this - working on field support and maintaining old code is the best kind of experience! But the job market is so hot that the best devs will just quit is not given work that looks sexy on their resume.

It's not so easy to make people care about the work itself these days.

Re:Real Talent?

[SillyNickName4me]

And I was pointing out to ClosedSource that this 10x faster code HE brought up isn't anywhere similar to a programmer being able to produce code in 1/10th of the time.. so I think your reply should have been to ClosedSource instead?

Re:Real Talent?

[MadKeithV]

In my 10 years experience, I've seen that most companies don't even *try* to let developers care.
No attempt is made to grow "teams" dedicated to the product or project. People are treated like expendable resources that have to be flexible and reassigned at the drop of a hat.
Hell, most of the time I think the company doesn't even care about the project or product itself. It's just a means to earn a living.
That doesn't really inspire great software.

Re:Real Talent?

[Hognoxious]

Seriously, just because there are programmers out there who think they are better than most of the others, doesn't make it true.

There's quite a lot of studies supporting that PoV. But maybe the authors of those studies post to slashdot so they're automatically wrong and your right...

Re:Real Talent?

[Anonymous Coward]

You're probably acting dumb on purpose, but it ought to be obvious that you'd baseline against the average.

Re:Real Talent?

[lgw]

Ahh - you need to work for a company that sells software as it's primary source of revenue. There at least the managers are permitted to grow teams tied to specific code and try to get people to care.

Re:Real Talent?

[Hognoxious]

ClosedSource is a troll or an idiot - given his nick, I'd say the former. Given the content of his posts, I'd say the latter.

One sure way to find out

[Anonymous Coward]

What is good code or bad code, we need laws that reflect normal consumer warranties and apply then post haste from some date forward for software alleged "products". Once cash changes hands, then "good" code will be subject to much less frequent recalls or cash changing hands back. Lather, rinse repeat until coding is up to the minimum standards of manufactured tangible items today. Nothing is perfect, nor will it ever be, but you can get it to the point you aren't going bankrupt every other week by shipping "bad" code. If it isn't suitable for purpose and free from glaring defects, it is "good". If it isn't, no financial reward, you go broke as a coder or coding concern. Simple fix. Works in every other industry out there. If you claim to be an engineer, claim to be highly educated and skilled technicians and professionals who demand very good salaries, then prove it in the market place under similar legal conditions to other engineers and technicians and professionals. If you are too afraid to offer a barebones minimum warranty, it is bad code, if you can, it is most likely good code, and there is your exact dividing line, nothing arcane about it at all.

  It might be *difficult* for you, but nothing really good is *easy* either, and "you" as an industry are claiming the big brains and big expertise, so prove it. We might as a society lose the "ship fast and furiously and who cares, we have the get out of all responsibility EULA protection!" type of software development and releases model that exists today, but the code consuming public would reward you better in the long run if you followed normal product styled warranties and guarantees. And your guild would be better off as well, as the ones who couldn't cut it would be weeded out faster, individuals and corporations. As it is now, it is the last remaining "legal" snakeoil business left. Well, OK, I'll let you skate one notch down the snakeoil scale, investment banking is much much worse, but they aren't incompetent at all, they know exactly what they are doing, because they are just plain vanilla outright thieves.

Re:One sure way to find out

[Surt]

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

Unfortunately, there isn't a magic bullet

[Anonymous Coward]

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.

Big car companies are not NASA

[cniebla]

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.

Better to make a video

[tomhudson]

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.

Anyone?

[Kooty-Sentinel]

If avoiding mistakes is a huge mistake, you are not making that mistake because you are making a mistake by avoiding mistakes.

A better idea ...

[tomhudson]

I'd be willing to put up with more checks provided that there are checks put on:

1. Non-coders, people with only a superficial knowledge of the project, and code wannabes;
2. Stupid ideas that have to be coded RSN, without any analysis of either the market or the impediments involved;
3. Requirements to implement an idea in the stupidest fashion possible;
4. Feature creep, and the creeps who push them;
5. "Don't take the time to do it right" mentality

Current Slashdot quote

[Anonymous Coward]

Currently, the quote at the bottom of the Slashdot page reads:

Never make any mistaeks. -- Anonymous, in a mail discussion about to a kernel bug report

PHB Solution

[PPH]

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

Re:PHB Solution

[Chandon Seldon]

Fine. Then we'll hire twice as many bad programmers and pay them half as much.

I love it when they do that. It takes bad programmers off the market, which is good for everyone else.

Re:PHB Solution

[pavera]

I also love it when they do that because 6-12 months from now I get the job anyway and get paid 150% of what I would have been paid in the first place to come in and clean up the mess :)

Re:PHB Solution

[Chandon Seldon]

Blech. Then you have to deal with the PHB *and* the mess. I'm not sure if I'd be up to dealing with that for only 1.5x standard pay, personally.

Re:PHB Solution

[Anonymous Coward]

Fine. Then we'll hire twice as many bad programmers and pay them half as much.

Oh, so you're going to outsource it then? Except you will be paying them two thirds as much.

An alternative rendition... (programmers as swarm)

[Anonymous Coward]

self-organizing, that is...

http://www.zoion.com/~erlkonig/writings/programmer-beekeeping.html

Cheers!

  -Captain Fairly-Obvious.

The appropriate question

[DaveAtFraud]

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

Re:The appropriate question

[russotto]

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.

If the procedures were followed, there would have been an Interface Control Document (ICD) which would have specified the interface, including the units. The ICD requirements would have fed into the Software Design Documents (SDDs) for each side of the interface. These requirements would have been traced back from the SDDs to the ICD and ultimately back to the System/Subsystem Design Document (SSDD), via the requirements traceability matrix. Theoretically, all this paperwork would have prevented exactly that sort of error.

In actuality, of course, the process of verifying software requirements is error prone as well. Not to mention extremely tedious.

(it's been a long time since I suffered through government software design, so some of the TLAs above may be wrong or superceded. But you get the idea).

Re:The appropriate question

[Anonymous Coward]

Or they could've just made a coding standard to include units in all variable/parameter names:

void moveForward( double distanceMeters );

Or even better they should've made such concepts that contain more than a single attribute a class:

class Distance
{
public:
    double asFeet();
private:
    double m_meters;
};

Re:The appropriate question

[DaveAtFraud]

I spent 12 years working for a defense contractor (TRW Defense Systems Group where I wrote several B5s, C5s, PPSs, SRSs, SDDs and a SDP and a SSS) so I agree that there was probably an ICD that specified the units. Unfortunately, nobody seems to have verified that the code matched the specification which is exactly my point. The code that didn't match the ICD was probably absolutely correct for the wrong units of measure. Only a person reviewing the code against the ICD would have seen the flaw. That is, it would take a code review to notice the error.

The original article argues that great programmers don't need code reviews and, worse, code reviews bring their code down to the level of the mediocre code. My point is that there is a level of correctness outside of just the code executing correctly. The code has to match some outside expectation of what it is supposed to do and how it is supposed to behave. I've seen some really good programmers miss on that. They produce absolutely perfect, elegant code that does not do what the customer wants. Thus my argument in support of code reviews for everyone.

Cheers,
Dave

Dear Paul,

[sootman]

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

Sounds familiar? Yup = strawman=

[thoglette]

Another whiney "but my software is art" diatribe which tries to use the strawman of The Ossified Bureaucracy to deprecate all process and procedure.

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.

• Are you writing a proof-of-concept prototype?
• Are you putting together a demo user interface?
• Are you writing flight control software?

• Most importantly

• Is your product mature or still a twinkle in your eye?

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.

Large organizations don't care about efficiency

[branchingfactor]

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

yeaaah

[roman_mir]

so, what is happening? How about those new covers on the TPS reports? I'll just go ahead, and send you another memo...

balance urself.......

[Anonymous Coward]

u need checks to verify
juz not too much or in another way
u like checks that prove u r right
but
u dun like checks that prove u r wrong
juz normal human
all guys can be creative....
but not all guys can be correct...
see ur target/purpose of programming
serving ur own satisfaction
or
meeting user requirements....
or in another way
it's noway to meet user requirements anytime anywhere actually

Not only programmers...

[Anonymous Coward]

From TFA: "Programmers are unlike many types of workers in that the best ones actually prefer to work hard."

Porn actors prefer to work hard, too.

Shit!

[Migity]

I fucked up this post!

The balance

[jandersen]

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.

One huge oversight...

[JetScootr]

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.

The author makes one mistake I can't pardon:

[Anonymous Coward]

He spends several paragraphs talking about hidden costs when it comes to supliers, but then fails to realize that if you don't have a dedicated Q&A testing team that your developpers will be doing that testing work which is exactly one of those hidden costs.

Re:An alternative rendition... (programmers as swa

[onescomplement]

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.

Not just programmers

[Drakkenmensch]

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

Speaking as one, programmers again show laziness

[Money for Nothin']

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

OO Karma!

[uncledrax]

What's the Karma hit if I blow up the studios because Mister Riccitiello told me too ?

Not spotting a mistake can cost you your business.

[wiedzmin]

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

Processes galore

[raw-sewage]

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.

Regarding your sig

[Dareth]

Duck-->Quack-->SMACK!

can't say you didn't warn him!

You didn't avoid the mistake...

[Dareth]

... but did you learn to click "Post Anonymously" next time?

WTF?

[ClosedSource]

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?

Re:WTF?

[Hognoxious]

Because he's replying to you, and you did?

Re:WTF?

[ClosedSource]

No. He's contradicting himself.

I was just trying to get him to realize that he doesn't apply the same healthy skepticism to this productivity claim as he would to other claims. The choice of a sort as an example was completely arbitrary, I didn't establish any linkage between productivity and sorting.

Re:WTF?

[SillyNickName4me]

If experience would tell me you are a brilliant programmer often finding novel and much faster ways of doing something, and you'd now claim that you invented a 10x faster sort algorithm, I'd likely believe you on faith. Lacking that experience however I'd like to see your thing in effect to gain such experience.

Re:WTF?

[SillyNickName4me]

http://slashdot.org/comments.pl?sid=1047369&cid=25955783

is where closedsource, not anyone else, brought up a n arbitrary claim about 10x faster code. The only place where I ever mention it is in saying it is not a comparable claim.

So excuse me?

Bigger pens?

[jonaskoelker]

instructions on how to get a bigger pen15 2day

:(

Why are there no penis enlargement 0-days?

I would deny them, sometimes

[ebuck]

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! :)

Fire the inept!

[lanner]

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!

ClosedSource is a liar

[Hognoxious]

The choice of a sort as an example was completely arbitrary

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.

Re:ClosedSource is a liar

[ClosedSource]

I don't understand what you mean by "see the link below.."

If you claim that I said something you should be quoting me, not somebody else.

Re:ClosedSource is a liar

[Hognoxious]

I don't understand what you mean by "see the link below.."

See post number 25979817. Do you have your screen the right way up, Einstein?

Re:ClosedSource is a liar

[ClosedSource]

His interpretation of what I wrote is simply wrong. I didn't suggest any relationship between a programmer who is 10x more productive and a programmer who can write a 10x sort.

My point was that we should be as skeptical about unproven programmer productivity claims as we would be about other unproven claims. I just chose a sort routine as an arbitrary example of another kind of claim. I could have chosen something else and the point would have been the same.

Is it really so hard to understand?