Better Development Through Competition?

theodp writes "Among the tips Derek Sivers offers for how to hire a programmer to make your ideas happen is an intriguing one: hire more than one person to complete your first programming milestone, with the expectation that one will go bad, one will be so-so, and one will be great. 'Yes it means you're paying multiple times for this first milestone,' says Sivers, 'but it's worth it to find a good one.' It's not a new idea — the practice of pitting two different programmers against each other on the same task was noted three decades ago in Tracy Kidder's Soul of a New Machine — but one that never gained widespread acceptance. Should the programming code-off be adopted as a software development best practice?"

Comments

My first employment

[Z00L00K]

My first employment was handled that way.

Re:My first employment

[Anonymous Coward]

And quickly led to your first unemployment?

Re:My first employment

[Anonymous Coward]

No, he's so-so, but had a gook work ethic, so he works in the IT department now.

Re:My first employment

[Anonymous Coward]

correction, he is the CEO now.

Re:My first employment

[GarryFre]

Can you imagine a football, baseball or soccer team going about it each man for himself? People wouldn't have anything to cheer and these sports would be forgotten words. But if you work as a team you get a LOT done, and there' still competition to prove yourself a valuable PART of the TEAM! Programming is a team sport. A good team can accomplish a lot. Think about it. PS, I loved the woodpecker thing!! :D

Re:My first employment

[Barrinmw]

They have one spot open on their team. They give that spot to 3 separate people to duke it out to find who would be best on their team. You are mistaken if you think this small group is the team. The team is the company, this isn't even a squad on the team, they are like mercenaries working for tenure.

Re:My first employment

[Anonymous Coward]

And to follow GarryFre's football analogy, pitting your recruits against each other is called tryouts or training camp. You do this to discover which prospect will fit in best with the rest of your existing team.

Re:My first employment

[furball]

This is how America's Special Forces work. The team gets a mission. Everyone comes up with a plan. The team goes over the plan. The good one emerges. The ones not as good fade out. Everyone pokes and prods the good plans until they figure out which one is going to bring about the mission results.

That is the plan the team executes. But at the beginning, everyone on the team has a plan.

Re:My first employment

[AmberBlackCat]

I don't think that's the same. In a team sport, team members can do things to cause trouble for team-mates in order to make themselves look better. In a programming competition, programmers can make themselves look good but can't easily sabotage the other programmers. Eliminating teamwork is bad for a team, but not bad for competition among individuals.

Re:My first employment

[ls671]

Just a note; they might recycle discarded plans into plan B,C,D... in case plan A fails.

Re:My first employment

[Anonymous Coward]

but had a gook work ethic

Sometimes I think that gook work ethic works to lower a gook's lifespan.

Re:My first employment

[Z00L00K]

Only after a few years - and I resigned.

Re:My first employment

[capnchicken]

Not sure if you were trying to be funny or not, but I worked for a company that told stories about how they implemented something very similar if not exactly Soul of a new machine. It was a small company with 2 large IT departments that competed against each other and would not hand code over to each other, they eventually hired what amounted to an IT saboteur that figured all the code and process' out, rewrote it and fired both teams. Now he runs all of the IT with an iron fist, mad with power, as a big fish in a very tiny bowl.

Things got better than, they deteriorated with time as he used more of his time to secure his fiefdom, rather than learn to code better or become hands off and just administrate the department, but I digress.

Re:My first employment

[Z00L00K]

I wasn't even trying to be funny - it was I and another dude who did compete for one job.

Ended up that the other dude didn't have a clue about SQL statements even though we both attended the same course right before our "competition".

Metrics

[Anonymous Coward]

With some seriously exact metrics this can work.

Not just speed but code quality, test coverage etc. it is viable

unfortunately measuring this impartially can be a pain

Re:Metrics

[obarthelemy]

I used to be the first-line filter for my (small, 2 or 3 interviews got you in, after me you moved on to CEO then CTO) tech company's recruitment. On of the things we did was ask people to clone a 4-ops desktop calculator. Which was a trick, devs had to work out for themselves that they had to handle priorities and /0. About 60% of people failed at one or both, and that rose lotsa flags with us about the required level of hand-holding.

Re:Metrics

[Anonymous Coward]

priorities? If you mean operator precedence, then, a simple 4-ops calculator will not (and arguably should not) handle that.

Type in 2+5*4 on a calculator. Most calculators will return 28. Only math calculators will return 22.

Re:Metrics

[Anonymous Coward]

Furthermore, floating point division by zero is typically handled rather gracefully. On top of that, writing an expression parser in an interview environment is a bit much if you're not Microsoft or Google.

Re:Metrics

[Enleth]

It is not if you know the teory behind finite state manichnes and their use in writing parsers. Just about every Somp Sci and software engineering department in the world includes those in the curriculum.

Actually, any other 4-op calculator implementation than a simple, formal FSM should be a red flag for the recruiter.

Re:Metrics

[Anonymous Coward]

Wrong. Implementing an expression parser (with operator precedence) requires a PDA and not a simple FSM.

--Same AC as above, who just happens to know "the teory behind finite state manichnes and their use in writing parsers"

Re:Metrics

[Anonymous Coward]

data Expr = Number Floating | Expr :+: Expr | Expr :-: Expr | Expr :*: Expr | Expr :/: Expr | NaN deriving (Read, Show)

calculate :: Expr -> Expr
calculate (x :+: y) = Expr $ x + y
calculate (x :-: y) = Expr $ x - y
calculate (x :/: Number 0) = NaN
calculate (x :/: y) = Expr $ x / y
calculate (x :*: y) = Expr $ x * y

-- Do you want the run time too, or should I just use the language's REPL?

main = getStrLn >>= putStrLn . calculate . read

Re:Metrics

[poopdeville]

Agh, it's putLine, not putStrLn. And you would want to include a definition for

calculate NaN = NaN
caluclate (Number n) = Number n

This kind of error (incomplete patterns) is easy to detect with automated tools built into the compiler.

Re:Metrics

[poopdeville]

Argh, it's incomplete and I'm too sick/tired to fix a toy problem like this.

Companies don't know

[Herkum01]

The fact is companies like to treat most jobs, excluding management positions, as unskilled labor. Not unskilled as in 7-11 but as one programmer is the same as any other programmer. This does not apply just to programmers but a large range of positions.

So even though you maybe the best of the group in your company, they will not care because they are not willing to expend the energy to find out. You are all the same as far as they are concerned.

Re:Companies don't know

[LarrySDonald]

This is often true in large corporations, but many smaller companies devote much more time to figuring out who is best for what and who is so bad that they shouldn't be there. This is what's known as "management" which is also a skill. The problem is that there aren't that many skilled managers because it's really hard and it only gets harder in middle and upper management (i.e. figuring out who would be good at figuring out who should do what). There are good managers, but they usually got rich and now run small/medium companies more for laughs.

Re:Companies don't know

[SirRedTooth]

Only if the company doesn't happen to be a tech company.

Re:Companies don't know

[khallow]

The fact is companies like to treat most jobs, excluding management positions, as unskilled labor.

The fact is people make generalizations.

Re:Companies don't know

[tomhath]

The fact is companies like to treat most jobs, excluding management positions, as unskilled labor.

You seem to imply that "managers" somehow spring forth from nothingness to become these godlike creatures. Most places I've worked the managers were once doing the job they are now managing. The exception is when the general manager is promoted up from Sales & Marketing; soon all the other managers are burned out salesmen who have no clue how to manage a project other than set goals and give frequent pep talks.

But back to the original topic, this seems like a bad idea to me. First (as has already been mentioned) the winner will be the person who is best able to sell his/her implementation, this usually means they either went for the "sizzle and not the steak", or they are in bed with the person making the decision. Second, you're unlikely to get a really good, professional programmer to work in that environment; they'll just go someplace else where the development organization is better organized.

Re:Companies don't know

[wonkavader]

The word you want is "fungible" -- one programmer is exactly the same as any other. You can swap 'em around and get the same result.

This worked when you hired 7 year olds to run machines in the 1800's, and since those were the glory days for employers, they keep thinking that way.

Re:Companies don't know

[noidentity]

And companies aim to be stable over the long run, not dependent on any particular employee's special skills. When I write a program, I try to make it as portable as possible, not depending on any special features unless they give a big benefit and outweigh the dependency and inflexibility involved. Maybe some of this applies to running a company.

Re:Companies don't know

[hedwards]

And the job I just quit was being managed by a jack ass with neither managerial nor industry experience. He was literally hired so that his boss wouldn't have to worry about competing with him for his job in the future. It's something which is richly rewarded in the US. Screw things up via incompetence and you'll almost certainly get bought up. With all the executives getting a golden parachute while massive layoffs for redundancy affect the people actually doing the work.

Sucks, but that's what you get for working in a nation with one of the least free markets in the free world.

Re:Companies don't know

[jc42]

That's often true, but there's also another common reason: The managers of software projects often don't have a clue about how to judge the "value" of a piece of software. This can be true even for managers who used to be programmers, if the tools (languages, libraries, etc.) are different that what they were trained on.

You can see symptoms of this in a lot of companies that try to measure their software. It's how you get such things as "lines of code" as a measure of programmer productivity. It's hard to think of a more counter-productive way to quantify software, but it's what you get when there's an official demand for metrics for quantities that nobody knows how to measure.

Re:Companies don't know

[deuterium]

Exactly. My brother, who works for a Dow 30 company, said that during a company seminar on HR, the speaker made an analogy regarding an individual's role in the organization. He asked them to think of putting their hand in a bucket of water, and then withdrawing it, then asked "how fast does the water replace your hand when you take it out?" Instantly. "That's how quickly you can be replaced."

They don't care if you're exceptional, only that you're adequate, because it's a lot of work to identify exceptional workers and there aren't many of them. Unless you're the CEO or a VP, you're not setting policies, you're only following them, so followers are needed.

Re:Companies don't know

[ultranova]

The fact is people make generalizations.

Of course they do, that's what separates them from apes. It's been a pretty succesfull strategy this far.

Re:Companies don't know

[ultranova]

That's often true, but there's also another common reason: The managers of software projects often don't have a clue about how to judge the "value" of a piece of software. This can be true even for managers who used to be programmers, if the tools (languages, libraries, etc.) are different that what they were trained on.

Maybe they should have a degree in computer science, then? One would imagine that that would help them judge the potential of a system.

Re:Companies don't know

[VTI9600]

You can swap 'em around and get the same result.

This is certainly a typical programmer's perspective on management's attitude. But, what you don't often see represented on /. is the reality that many programmers are prima donnas who vastly overestimate their own genius to the detriment of the projects they work on.

These sorts of programmers refuse to write comments (let alone end-user docs) because they say, "my code is self-documenting", while you're looking right at it and can see nothing but spaghetti. They come up with bizarre database schemas and naming conventions, throwing out all rules of normalization, etc., because they think they're smarter than anyone who's methods they could have found with a 10-second Google search. They refuse to write test code because they conveniently recall something someone said one time in a class they took that regression testing alone was not good enough. They proudly declare themselves experts in a technology they spent 3 months dicking around with in their parents basement, while failing to see any difference between themselves and someone who may have had years of on-the-job experience and real training.

The list goes on and on. I'm not saying there aren't programmers out there that don't suffer from ego-overload...I'm just saying that they are a rare and valuable commodity. Self-awareness, maturity and a sense of perspective are things that are more valuable to IT managers than simply posessing the ability to write code.

Re:Companies don't know

[Anonymous Coward]

You seem to imply that "managers" somehow spring forth from nothingness to become these godlike creatures.

The bowels of hell do not count as "nothingness". Close, though.

Most places I've worked the managers were once doing the job BADLY that they are now managing.

Fixed that for you.

The exception is when the general manager is promoted up from Sales & Marketing; soon all the other managers are burned out salesmen who have no clue how to manage a project other than set goals and give frequent pep talks.

See above - Satan's little helpers, as Bill Hicks used to say.

Re:Companies don't know

[mcrbids]

As an employer, I can say with confidence that I'm NOT looking to commoditize my programming team. I WANT developers to be valuable, because when they are valuable, I can charge more for their work. I'm more than happy to pay my developers more, but the difference in value makes it more profitable for me as well.

In my opinion, managers who try to make their programming team lack value are doing the same for their company. And why would you want to work to ensure that your company offers no value?

Better programmers make better software, and better software sells better, for more money. And that means more profits for everybody. Why is this hard to understand?

Re:Companies don't know

[microbox]

Most places I've worked the managers were once doing the job they are now managing.

This is true, but people aren't promoted because they know how to program. Last IT shop I worked at, the most skilled manager didn't understand that DLLs were loaded with the program. The previous guy couldn't grok what encoding was all about, and used & through trial and error.

A famous book from the 80s, "Peoplesoft" talks about some of the insane chronic disconnects between management and developers, and these same problems persist 30 years later. In particular, programmers are in a market for lemons, and HR/management are almost always too stunned to discern the wheat from the chaff.

Consider the following (simple) hiring procedure:

• Applicant sits a multiple-choice exam about programming
• Those who do well spend 10 mins talking to two or more of the senior developers. So that you can't fake not-knowing what you're talking about
• Those who pass this test continue on to talk to the manager/HR person - to work out if they'll fit in.

How simple it would be.

Yet somehow management is confused about how to hire good help.

Re:Companies don't know

[Anonymous Coward]

I worked a a company (non-software) very much like this. Person A was like person B and so on. They hire people, apparently with qualifications. They offer a certain pay rate for certain qualifications. They test on the job whether someone really has the qualifications. If they do, they keep them. If not, they fire them. So long as the minimum qualifications are met, the person is kept. If person A is delivering twice as much product as person B, its generally unnoticed. If person B sucks up and gets attention and adulation from management, then person B moves up. People came and went as widgets. Too many people for too little work? Fire some. Too few people for too much work? Hire some. Employee turnover was high. It did not seem to matter to management. The company has nearly 180 employees, with none outside of management working there more than 5 years. People just weren't important to them. They didn't mind getting rid of 3 or 4 long term employees (3-4 years service) if available work slowed down for two weeks, and would then hire 6-7 fresh faces from off the street and then watch 3-4 of them either leave or get fired within a week or two. People just weren't that important to them. They considered people to be an endless pool, and loyalty didn't matter. One man didn't show up for 4 days and since he didn't call in, was automatically fired. A few days later it was discovered the man had died in his apartment. NEXT!

Re:Companies don't know

[Maxo-Texas]

Also... "best" is a relative term.

If you mean writes code fast, cool.
If you mean writes code that can be debugged by other people later, better.
If you mean code that performs well underload, cool.
If you mean code that can be maintained coo.

And then
Does the person arrive on time (how do you balance, arrives late, leaves early but writes great code on deadlines-- most managers will spike this person so they don't upset the average programmers who have to work 8 hours to get the job done).

Continuing that thought-- does the great programmer piss off other good programmers, customers, users, or executives?

etc.

This type of approach will probably find a certain kind of "best" programmer.
Tho it would be fooled if one programmer got sick. Another programmer performed this way only for function point 1 (and lazed off once they got the job).

etc.

Re:Companies don't know

[Anonymous Coward]

Better programmers make better software, and better software sells better, for more money.

I know what you're saying and I, personally, agree however, does "better software" sell more copies?

It's like McDonald's. Their burgers are crap, but they are consistently the same crap, and they sell huge quantities of them.
The profit in McDonald's isn't in a single burger, it's in the numbers sold.

Re:Companies don't know

[computational super]

A famous book from the 80s, "Peoplesoft"

Hm - do you happen to know who the author of the book was? I'd like to take a look, but I can't find any info on it anywhere; Google, Wikipedia, and Amazon all want to tell me about the company "Peoplesoft", not the book.

Re:Companies don't know

[wwfarch]

In my experience hiring people 10 minutes isn't nearly enough time to deduce if someone knows what they are talking about. Plenty of people can talk a good game by studying up on theory before the interview. Relatively simple coding problems is enough to determine if they know what they are talking about but these take about 20 minutes from a good candidate.

I've crafted many simple problems for interviews and a vast majority of people fail to make the progress I would expect from a second year undergrad in Comp. Sci. One candidate even told me that he was shocked when I asked him to code. He was only expecting questions on theory and did all his brushing up there.

Re:Companies don't know

[microbox]

Hi, I had the same problem looking on the internet. The s/n ration is just too high. I have a copy of the book back at home (i.e.: in Canada, I'm currently in Australia for a few months.) Sorry! If I remember (in September) I'll update this link =(

Practicality

[Voulnet]

Usually a stunt like that lacks lots of real world practicality. Software development is a delicate craft, and it requires patience and attention to detail. It's difficult to attain that by pitting two programmers against each other. You can be certain of bugs, memory leaks and security vulnerabilities for example. Besides, won't it damage cooperation and teamwork? Your competition should be with the competing companies in the market, not a civil war within.

Re:Practicality

[h2oliu]

I agree that you want to have your team working together. But what about the idea of "come up with you you think this should work". By coming at it from different perspectives there are more possibilities to come up with something interesting.

Ideally you could blend the best ideas from both. That said, in many ways this isn't practical from today's business perspective, where resources are so thin, that you can barely get one fully staffed team.

Re:Practicality

[aj50]

This scenario refers specifically to hiring freelance programmers to complete a project. You want one programmer (or small team) so you hire several to do the first milestone and then keep the one which works best.

Yeah, the summary could have been better.

Re:Practicality

[Anonymous Coward]

You've never worked for an American corporation, have you? Most of the time, they're nothing more than civil wars between different managers and executives.

Re:Practicality

[SomewhatRandom]

What's the matter? Chicken? Buck Buck Buckaw! Sounds like a smoke-screen post from a 2nd-string programmer. (j/k - couldn't resist)

Re:Practicality

[Anonymous Coward]

Besides all that is the fact that you're probably going to have to hire them at contract rates, costing you much more money per programmer multiplied by however many programmers. Having a cutthroat attitude amongst each other in the cubicles is something I'd only deal with if you paid me a lot more money than usual anyway.
 
A slight tangent, but recently I took a challenging grad class where we had to work in teams, and even though the other two guys were obviously not as skilled at coding (it was an interdisciplinary computing class, for one) I found that for pushing things through as fast as we needed to go -- especially when I was worn the fuck out -- having the other guys around helped quite a bit. So whaddya know, pair-programming can sometimes be good. Still, almost no one is ever going to do it because managers think it'll cost more money. (With older, surlier coders it likely would always be a waste of money.)

Re:Practicality

[hoggoth]

Contract rates? Where have you been the last 10 years. Contract rates start at 10 rupees.

Re:Practicality

[Anonymous Coward]

That's amusing, but not in agreement with actual job listings where I live (USA -- San Francisco and NYC).

Re:Practicality

[kiddygrinder]

you're assuming that most programmers are competent, assuming that 1 out of 3 programmers are total gits this method looks a lot better

Re:Practicality

[Puff_Of_Hot_Air]

If you read the article, you will see that the intent is to find a non dodgy programmer, not a bare nuckeled cage match, winner take all. The article even suggests not letting either side know that there is another side. RTFA; yeah yeah, I must be new hear.

Re:Practicality

[Opportunist]

I was about to write that. If I ever find out you pit me in such a situation, and provided I do want that job, I will cut any corner possible to hit that milestone first. Does it require performance? No? Then it won't be performant. Will mem leaks matter? No? Then it will leak. I will not take care that the code is actually good. I will take care that it does exactly what the milestone requires. Not more, not less. Even if I have to unravel it completely because the design itself is unfit to do anything but hitting that first milestone.

That's what you get once your programmers notice such a practice.

Re:Practicality

[mfnickster]

I was about to write that. If I ever find out you pit me in such a situation, and provided I do want that job, I will cut any corner possible to hit that milestone first.

Aren't you assuming that the competition is for speed and not quality?

The article recommends continuing with the programmer "you like best," and if you're just going by who's faster, you're probably going to suffer for it.

Re:Practicality

[Opportunist]

I'm assuming that the competition follows the old market rule: Who's cheapest? When you're paying people by the hour, it's the fastest guy.

And yes, that's all that counts anymore. Quality is a myth everyone would really love to have but essentially, what people care about is cost. It's a bit like everyone wanting love, but prefering money in the end.

Re:Practicality

[zippthorne]

Ahh, the "Survivor" model of programming.

Far better, I think, would be to hire the programmers you can afford, and if possible divide into competing groups for the first milestone, at which point, you pick the better idea, divide into new groups, and set those groups to work on the next milestone.

You can't run a business like a game show for very long without burning everyone out.

Re:Practicality

[mfnickster]

But if you cut corners, it will end up being more costly in the long run.

I'm sure the managers aren't thinking about that, though.

Re:Practicality

[scamper_22]

As a developer I agree with you, but I'll also play devil's advocate here for a second.

I'm the most cooperative person. Always helping people. Sharing ideas... Yet, after years of interviewing people for positions, I sometime question if my cooperative nature is actually a problem.
They all come in with great resumes, but really don't know much.

Does it actually prop up bad people? Management only cares about results, as they should... and if I'm propping up someone, it shields them from failure and thus management is not going to be able to differentiate people.

In a hypothetical world, if all the good engineers/developers suddenly stopped propping everyone else up, you would very quickly find out who is doing work and who is not.

That all said, I don't see myself changing. I've worked at one place that wasn't very cooperative, and I couldn't stand it. This attitude of cooperation has been there since university . Everyone I talk to always agree that engineering is far more cooperative than say business or programs geared towards healthcare... Perhaps it is because those streams have programs that have to exclude people. Medical schools are hard to get into... so people are competing for grades and are less likely to help each other out. In business, there are so many good jobs of reaching the top.

Engineers see themselves as cooperative workers... and we are treated a such. It is as much our fault as that of business.
Lord knows, we (not me :P ) are totally against even enforcing proper entrance standards like the medical or legal profession.

Re:Practicality

[Anonymous Coward]

best = best return on investment

If you're trying to make an expensive luxury item, maybe you pay for the quality.

If you're just trying to make something that works well enough for some internal company tool, cheap & quick may win.

Re:Practicality

[turbidostato]

"But if you cut corners, it will end up being more costly in the long run."

That's only if there's a "long run" *and* the one paying in such a long run will be you. If there's no "long run", then your "quality" is plain old "overburden"; if there's to be "long run" but the ones paying for it are "others" (for a varying definition of "others") then it's "externalities".

"I'm sure the managers aren't thinking about that, though."

Mostly they do. And don't give a damn because that's not what they are being payed for.

Do you want managers to go after the right things? Then pay them for acomplishing the right things.

Re:Practicality

[Anonymous Coward]

I think youre missing the point. The programmers are not supposed to know about each other (contractors?)

Re:Practicality

[jc42]

That said, in many ways this isn't practical from today's business perspective, where resources are so thin, that you can barely get one fully staffed team.

Hey, where do live, that has such a problem? Where I live (the Boston area), most of the software people I know are only semi-employed or unemployed. Around here, it'd be pretty easy to get together a good-size team, and put them to work coming up with multiple solutions to software problems, then testing them to learn which ones are good for what part of the parameters' ranges.

Of course, part of the problem is that hiring usually has to go through the HR staff, who write up long lists of requirements that typically include several products that haven't been on the market as long as HR requires. This does make it look like it's hard to get a fully staffed team, but it's because your HR folks have filtered out the honest applicants. ;-)

Re:Practicality

[Anonymous Coward]

for some internal company tool

You mean like a manager?

Re:Practicality

[Opportunist]

No they are not. Because they are just like me: They get paid for certain things, not for the right things. Managers get paid for good quarter reports. Even if that ultimately means the death of the company they will be rewarded for good quarter reports. Because this is how their ability to manage is gauged. Just as my ability to code was gauged by the amount of code I crank out while I was still working in such a company.

I think it goes without saying that the quality of their products was not too good. More often than not, we produced a lot of bananaware.

Re:Practicality

[Anonymous Coward]

That said, in many ways this isn't practical from today's business perspective, where resources are so thin, that you can barely get one fully staffed team.

Hey, where do live, that has such a problem? Where I live (the Boston area), most of the software people I know are only semi-employed or unemployed.

He might have meant internal resources and not the pool from which to hire. IE: The company tries to save money and your project isn't given enough people (or money to hire enough people).

Wrong expectations

[Chemisor]

I'd say that when you hire three programmers, it is more appropriate to expect that one of them will be bad, the second one will be bad, and the third one will be the worst of all.

Re:Wrong expectations

[JamesP]

Protip: hire the three developers from different countries

Re:Wrong expectations

[Opportunist]

So you get a bad one, one whose comments you can't read and one who needs an interpreter to misinterpret what your specs demand?

Yes, I had to work with code from abroad ("I think I have to polish my code a bit" "No, I think your code is Polish enough..."). Why do you ask?

Re:Wrong expectations

[DoofusOfDeath]

Good call. They should hire four programmers!

Re:Wrong expectations

[Noughmad]

Good call. They should hire four programmers!

Why not up it to eleven?

Re:Wrong expectations

[DoofusOfDeath]

Why not up it to eleven?

Because even the manager isn't allowed to see it when it has eleven.

Re:Wrong expectations

[Yetihehe]

Bad code can be written by people speaking any language. I've seen bad code from French programmers, I've seen also good code from French programmers. You just see more bad code because good code just works and doesn't need to be rewritten.

Re:Wrong expectations

[mounthood]

"It was the best of times, it was the blurst of times"?! You stupid monkey!

http://www.youtube.com/watch?v=V7__SWWSaGM

Re:Wrong expectations

[Anonymous Coward]

Shame on you. Pollocks aren't the only ones who know RPN. You racist, insensitive clod!

Re:Wrong expectations

[Bill Dog]

Yes, I had to work with code from abroad

Except for the brilliant Paula, I've haven't noticed that they do it any worse. ;)

Re:Wrong expectations

[Opportunist]

clod, racist insensitive you are!

C'mon, when you do a joke, do it right and all the way.

Re:Wrong expectations

[Anonymous Coward]

>> >> Good call. They should hire four programmers!

>> Why not up it to eleven?

Didn't make sense at first, but on closer literal inspection, it does: hire eleven, but by the time the eleventh is hired, nine or ten have been fired.

There are 7 billion people on the planet, so getting good value for a budget is possible. Theoretically.

Re:Wrong expectations

[Chowderbags]

I'd suggest going over 9000.

Why is this surprising?

[Anonymous Coward]

Unfortunately, with all the kiddies getting a trophy for just showing up, I see a lawsuit in the future of this approach, with cries of "It's not fair!" Thank you 1960's!

There is only one reliable software meric.

[Anonymous Coward]

You ask, "Was this software developed by Indians?"

If the answer is "yes", then it is shitty software.

Re:There is only one reliable software meric.

[Rivalz]

Usually when I do work it is for the whole project.
There are people out there who are willing to be jerked around with a 33% of being hired to complete a full project?

You know what I would do is sub out a few people to help me with the first milestone and then just sub out to one dumb ass to complete the rest of the project.

Open Problem Vs Restricted/Closed Problem

[eldavojohn]

I think that there are two major groups of problems out there. Yes, some problems are in both categories and I'm sure there's problems in neither category but the majority of problems out there are either a restricted closed space or an open space. In the former, you have a problem with a facet that dictates there is a best way to do things. For example, say you are building a database meant to create millions of records daily with a demand for instant querying. You're not going to want three people to tackle that three different ways. There's just a more simpler way of analyzing existing products and comparing strategies like federated search versus directory storage. Or sharded versus RDB. Or a number of other things that can be planned out on paper ahead of time and should be.

In the open scenario -- like designing the UI or mashup of many different pre-existing services -- then I think the proposed idea is a great idea. Because a human interface is more open with many different variables that are related in some unknown way to each other. UI isn't the only place this is applicable but we have used this strategy to develop several UIs before milestone one and then all discuss, come to a collective agreement and kill two.

Re:Open Problem Vs Restricted/Closed Problem

[Anonymous Coward]

The goal isn't to find the best solution but the best programmer, with the understanding that the other ones will not be hired beyond the first milestone. The idea is simple: All programmers claim to know all languages, environments, methodologies, etc. that they're vaguely familiar with. How do you find the ones who actually do know what they need to perform on your project? You give them a shot at working on the project. While they're there, you can also check their work ethic and other "soft" aspects for which there are no certificates. Think of it as an internship with regular pay.

Re:Open Problem Vs Restricted/Closed Problem

[flajann]

Oh, you mean like hire them for a month for a probation period? Keep the one you like and let the other one go? Hmmmm.... interesting idea. Might work if done right.

Alas, silly labor laws in your state/country might get in the way of doing it that way -- unless, of course, they were hired freelance/contract first. Even still, I can't even dream of pretending how all the various labor laws in all the various countries/states/cities would affect that approach.

But I like it (this is Manager Me talking!)

US Fed. Govt. does that, too, ...

[Cragen]

And has been doing large contracts like that for quite some time. Military, especially. Then, again, the Fed. Govt. is moving away from hiring contractors and is looking to hire permanent employees these days.

Re:US Fed. Govt. does that, too, ...

[luis_a_espinal]

And has been doing large contracts like that for quite some time. Military, especially. Then, again, the Fed. Govt. is moving away from hiring contractors and is looking to hire permanent employees these days.

Yeah, but the Gov. usually consider competing contractors on large-scale systems (not individual programmers or individual programming efforts.) Contractors have to pitch (hopefully) sound and technically feasible proposes using specific systems (not software, systems) engineering processes. Prototypes might be involved but they are submitted by the contractors as the result of team efforts within each contracting agency.

The scope of competition between contractors vying for a gov. contract vs individual programmers competing for implementing a web site or a e-business idea is really different by several orders of magnitude. One entails systems engineering (usually mid-to-large scale integration of electrical, computer, software and many times mechanical engineering). The other one will most likely reduce itself to a simple hackery contest.

Re:US Fed. Govt. does that, too, ...

[Anonymous Coward]

Also it's an example of the classical IBM contention management which produced the System/360 of the 60's.

Re:US Fed. Govt. does that, too, ...

[spiffmastercow]

Seeing how much the government wastes, i would not consider that a glowing endorsement. And hiring feds is significantly cheaper than hiring contractors. Pay them more and you might even get good ones.

Re:US Fed. Govt. does that, too, ...

[Anonymous Coward]

And has been doing large contracts like that for quite some time.

Right, for large contracts, not individuals. Many of you probably have heard on the radio the JSF's engine was developed this way.

First will sadly win

[notthepainter]

Not best, but first will win. That's my guess based on how most industries work.

Re:First will sadly win

[Aladrin]

Unfortunately, I think you are right. Only if the second comes in very close on the heels of the first, and is obviously better, would it win. As I said in a post below, companies can't judge 'good' software without an excellent programmer on staff to do the judging, and even then it could get twisted by politics.

Re:First will sadly win

[Alien Being]

TFS mentions "The Soul of a New Machine". The reason Data General ran a parallel effort was that they needed a product "yesterday" (to compete with VAX). They went to market with the first completed project and did well with it. If they had waited for the other team to cross the finish line the race might already have been lost. Sometimes time is of the essence.

That book was a great read.

Re:First will sadly win

[Anonymous Coward]

I believe that this is how MS Internet Explorer was initially developed.
Three teams worked in parallel towards a given milestone (took about twelve weeks). All three were evaluated and the winning code base was spread across all three teams.
The three teams again worked in parallel until the next gate (again about twelve weeks). Again the solutions were evaluated and the winning solution shared across all teams. Repeat repeat.

This cost a bomb, but what it did manage to do was move the actual IE product from zero to "something that could be presented to the market" in record time.

As a further note, it's not just Microsoft that sees value in this approach (under certain circumstances). The venerable Fred Brooks (Mythical Man Month) participated in the development of several of IBM's OS offerings. At one point in his book he feels that, if you budget is up for it, multiple independent teams competing with each other against a spec is really valid way to go. If the two teams are not interoperable at the end of the build, then obviously the spec is not clear. I guess that if you are designing an OS the spec is quite important. In an agile world, maybe less so.

I believe that this approach can work, but only in the largest of shops.

Interesting idea, but...

[Anonymous Coward]

I find the idea intriguing, and I'm just prideful enough to think that -my- work would be the one chosen, but...

What if it isn't? I will have spent days, weeks or months working for a company that doesn't want me around any more. I won't have any other job prospects lined up, and I'm just back where I am, but now with either a big hole in my employment or a -very- short job on my employment list. It seems to me that this is a massive gamble.

Also, how does the company judge which is best? There are so many factors involved in such a determination, and many of them aren't something that a non-programmer can even understand, let alone quantify.

Code Readability
Comment usefulness
Self-documenting code
Documenation usefulness
Speed
Unit Testing Coverage
Unit Testing Usefulness

Those are just right off the top of my head on how I'd judge the work, but non-programmers couldn't judge most of them. So you have to already -have- an excellent programmer to do the judging, and you have to get one who isn't afraid of the new guy taking his job.

So on top of the gamble on whether you are the best programmer, you also have to gamble that the company can judge the work properly as well.

No thanks.

On the other hand, if you are outsourcing, this makes a lot more sense. Give the project to 3 companies and let them fight it out, and have an in-house developer (the one who is going to liaison for the project anyhow) do the judging. The outsource companies are better off because they had some work and they aren't screwed out of their next job by this one.

Re:Interesting idea, but...

[Aladrin]

Not sure why this ended up anon. It's mine.

Re:Interesting idea, but...

[Anonymous Coward]

I will have spent days, weeks or months working for a company that doesn't want me around any more.

As an independent contractor I always work like this. It's a non-issue.

You list a bunch of attributes the code ought to be judged on, but I think you are overestimating the vast majority of programmers. Simple questions like "does it crash?" and "does it do what it's supposed to?" will be enough to weed out the innumerable dumbasses who work in this "profession".

Re:Interesting idea, but...

[Puff_Of_Hot_Air]

Well, the article is talking about outsourcing; outsourcing to one. The situation presented is the small business looking for a non-shonky programmer for hire. This is more difficult than it may first appear! The web world particulary it appears. Case study: My father in law required a website/CMS system for his business. He allready had a basic website, but he was looking for a substantial upgrade. He hired a guy. This guy strung him along for several months, promising this and that, everything was 90% complete. Eventually my father in law got fed up, and demanded he just hand over everything in the state it was in. My brother in law, who is a web developer took a look at it. It was a cobbled together mess from various code-project projects. Nothing worked, and there was nothing to salvage. $5000 down the tube. Avoiding this is what hiring multiple guys is about. Give them one small useful increment and find out if their crap. Sounds like sage advice to me.

Pitching two developers, teams or even companies

[Sla$hPot]

Pitching two developers, teams or even companies against each other maximizes your change of success.
That is:
1. As management, you dont have a clue about what you are doing in the first place (go happy lucky)
2. You dont mind spending the cost two times over
3. To stay in power, You have learned to divide an conquer

But your cost will double
Your employees will start fighting and sabotaging each other

But who gives a $#!7 as long as your happy :)

Good in theory

[schnablebg]

In the vast majority of businesses, especially small ones, getting to market has a lot more value than building great tech. It doesn't matter how good the tech is as long as it meets the business requirements from a black-box prospective. You don't need three independent projects to do that. The resources are almost always going to better spent on sales and marketing.

Re:Good in theory

[Bill Dog]

getting to market has a lot more value than building great tech

The question is, which time? I worked for a dot com that got their first version to market quickly, but it was so shaky technically that it was taking forever trying to build on it for the next version, and the company ultimately failed as a result.

Code Competition may not always work!!!!

[flajann]

I was once involved in a project where this sort of thing was going on, and those that had the better looking GUI got the nod. I focused more on the infrastructure and the middleware, knowing I could pretty up the GUI later. The competition only focused on the GUI exclusively, but no infrastructure. Theirs looked much prettier than mine. They got the nod, and I simply walked.

Competitive programming, if not done right, can actually make matters worse rather than better. My GUI always looks like crap until near the end of the project, after I get all the infrastructure in place, working, and stable. I don't like focusing on the GUI up front because their are usually many requirement changes and what not and would have to be redone anyway. Better to wait until a later stage when everyone has had a chance to think about what they really want.

Alas, other departments, project managers, and what not only see the GUI and have no clue about what it takes to support the GUI underneath. The GUI is just the tip of the iceberg. It's the least important as far as overall functionality, but it's what everyone sees and reacts to. The database schema, the middleware, the messaging protocols, stuff you have to design in to make it scalable, robust, and secure -- all of that is "under the hood". Neglect it to your own peril.

Re:Code Competition may not always work!!!!

[Nerdfest]

I've found that competitive design pays off better than competitive development. It's easier to refactor code than it is the complete design of a piece of software, so it's more important top get it right the first time. For code just use paired programming or a decent code review process (or both).

Re:Code Competition may not always work!!!!

[Sla$hPot]

> The GUI is just the tip of the iceberg. It's the least important as far as overall functionality, but it's what everyone sees and reacts to.

True. So you have to be a good communicator besides being a good system developer.
Often you have be good at smooching a litle bit too :)
Unfortunately, in most cases, being good at your profession is usually not enough when you work with IT
Thats is why you have to walk sometimes even thoug it can be tough.
But you can plan for it and you can learn to become better at navigating through bad projects ( learning by doing :)

Re:Code Competition may not always work!!!!

[flajann]

I've found that competitive design pays off better than competitive development. It's easier to refactor code than it is the complete design of a piece of software, so it's more important top get it right the first time. For code just use paired programming or a decent code review process (or both).

Oh I despise the "paired programmers" approach! Well, unless the pair are reasonably matched in competence and ability, I see no good coming out of it. And since I've been writing code for the past 30 years and have gotten rather good at it, I can't even conceive of who would be a good "match" for me in that scenario. If anything, I would wind up *teaching* rather than *coding*, which is how it usually goes anyway.

Re:Code Competition may not always work!!!!

[JamesP]

This is an interesting problem, and more of a 'customer relations' problem

Non tech people (and even tech people) have a funny way to understand things. If it doesn't look like it's working (even if you're building the foundations, etc) then, for all purposes, it's not working!

And I'd say, never, NEVER put the button if the code to make it work is not there. If you put the button they'll say "ok, now you just have to make it work *wink*"

Re:Code Competition may not always work!!!!

[Anonymous Coward]

I was once involved in a project where this sort of thing was going on, and those that had the better looking GUI got the nod. I focused more on the infrastructure and the middleware, knowing I could pretty up the GUI later. The competition only focused on the GUI exclusively, but no infrastructure. Theirs looked much prettier than mine. They got the nod, and I simply walked.

I am so sick of programming done this way. If I can't use you program, the infrastructure and middleware is of no value. I hope you simply walk from any project I might end up using

Re:Code Competition may not always work!!!!

[Dumnezeu]

Maybe you should focus more on an outside-in architecture. You start with what the user wants and end doing what you need to achieve that. Otherwise, you might start with what you think the user wants and end up with an interface for controlling that, instead of an interface dedicated to the needs of the end-user. Having a well designed back-end is very important, but not as important as a well designed front-end, because the user will care that something isn't work properly, but he will care about it a lot less than he will care about the fact that the option isn't even there! You just teach the user that bugs will always be fixed and he'll be happy to know that the next iteration will include the option he wants. If he doesn't even see the option on the screen, he just can't imagine it and he will think that you don't care about his needs. Users need slick front-ends and they don't give a shit about OOP, layering and all the other "details" involved in the process of programming quality applications. Maybe the company which wanted to pay for that project knew this and they knew that there would be time and money to re-factor the back-end as soon as the users saw a shiny interface and started paying for what they got.

In other words: Computer programming is very difficult, but that (unfortunately) doesn't work as an excuse for not packaging your product properly. Packaging is the only indicator that the user has to judge if your product is well done or not, because regular people just don't give a shit about any kind of abstract notion such as "performance."

The only performance the user cares about is how much faster he will be able to do his work using your product.

Re:Code Competition may not always work!!!!

[OneMadMuppet]

I disagree with one significant thing: the UI is at least as important as the DB, middleware and protocols, precisely because it's what everyone sees and reacts to. I've used some very well architected software be absolute pigs to use because people thought the UI wasn't important. If it's going to be used every day, it should be simple, intuitive and look good. If it's going to be used by non-engineers it's even more important. As anyone who's ever tried to design a good UI knows - simple and intuitive are hard for anything past Hello World. Believing that you can just slap any GUI at all onto a well-engineered piece of software is wrong (I'm looking at you IBM and Sun) and is the equivalent of saying you can throw together a pretty website in 30 mins using notepad.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

Don't forget you are programming for end users, the UI is one of he most important things in a software application.
Looks like a lot of "great" programmers forget this and and although their app gets the job done it's a nightmare on users (see Lotus Notes).

Re:Code Competition may not always work!!!!

[bzipitidoo]

To use a car analogy, on your way to getting a car built, which would you rather have first? A bare frame with wheels, engine and transmission, or an empty shell with a pretty paint job? I prefer the engine first, but seems that puts me in the minority. I'm continually astonished by how much stock most people put in appearances.

At my last job, the boss was supposedly a bright guy, but he was the sort to nitpick about the appearance of a web page (margins are too small was one of his favorite complaints) while thinking nothing of all the work behind the scenes to generate the data that the web page was supposed to display. My duties were primarily system administration, and I was constantly being accused of doing nothing. He'd think the work behind the scenes was trivial, and should only take a few hours. The web developers would make mess after mess, doing things in such horribly inefficient ways that once again systems were brought to their knees, and I'd have to clean things up somehow. If I could, I'd be on top of the situation before the RAID array ran out of space, and be logged in and still able to issue commands before the CPU utilization shot so high that even sshd was being starved. When I wasn't putting out fires, I was doing all I could to head them off. To be fair, the web developers were under a lot of pressure to bang out more bells and whistles as quickly as possible, so it was no surprise they took shortcuts to meet those demands, and never mind how much more work that made for me.

Re:Code Competition may not always work!!!!

[Nerdfest]

The teaching is part of the intent, but yes it works poorly if there's a huge disparity in skills.

Re:Code Competition may not always work!!!!

[westlake]

The GUI is just the tip of the iceberg. It's the least important as far as overall functionality, but it's what everyone sees and reacts to

Of course it is. The UI is how users communicate with your program. It is core functionality to them.

You build a car for the driver, not the mechanic.

Re:Code Competition may not always work!!!!

[hibiki_r]

In a more generic way: Application quality cannot be measured at the time of delivery. It's usually many months before on can really say how good a custom app really is. Sometimes what seems like the best infrastructure ends up being the worst, because it was a lot less flexible than no infrastructure at all, and the requirements gathering that the system was designed from was faulty. Other times, the big infrastructure cost is more than warranted.

Using the obligatory car analogy: The car that has the best test drive isn't necessarily the best car after you've put 100K miles on it.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

To use a car analogy, on your way to getting a car built, which would you rather have first? A bare frame with wheels, engine and transmission, or an empty shell with a pretty paint job? I prefer the engine first, but seems that puts me in the minority. I'm continually astonished by how much stock most people put in appearances.

Leave the bad analogies to badanalogyguy. Ignoring the UI is like ignoring where to put the dashboard, the steering wheel, the ignition, etc., designing the engine, then putting the ignition under the hood, the steering wheel in the back seat and the dash on the front right side door.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

I've found that competitive design pays off better than competitive development. It's easier to refactor code than it is the complete design of a piece of software, so it's more important top get it right the first time. For code just use paired programming or a decent code review process (or both).

Oh I despise the "paired programmers" approach! Well, unless the pair are reasonably matched in competence and ability, I see no good coming out of it. And since I've been writing code for the past 30 years and have gotten rather good at it, I can't even conceive of who would be a good "match" for me in that scenario. If anything, I would wind up *teaching* rather than *coding*, which is how it usually goes anyway.

Oh right, there is no one on God's green earth that is intelligent and experienced enough to be your match.. please.

Be a little more conceited.

Re:Code Competition may not always work!!!!

[roman_mir]

So you were given explicit requirements, instructions on how to 'win' in this competition, but you decided to go against these requirements and concentrate on something that was not as important to the stake holders instead and now you are complaining that competitive programming does NOT work?

You are the proof that competitive programming DOES work, it's just you failed in that competition.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

I am so sick of programming done this way. If I can't use you program, the infrastructure and middleware is of no value.

You sent this message using HTTP/TCP/IP, which were all designed extensively long before they had any kind of user-friendly interface, and which were therefore flexible and capable enough to become integral infrastructure behind every user interface in the world. Ironically, the only things valueless about your post were the "thoughts" it contained.

Re:Code Competition may not always work!!!!

[coryking]

This is horrible advice! Your method is why we have such shitty software and is why companies like Apple are stealing Microsoft's lunch! Yes the backend is important and you shouldn't neglect it, but the GUI is what drives the design of the backend! It is, in essence, the high-level requirements document for the entire application stack! If you don't have the GUI design, how the hell do you even know what the bowels of the application should be doing!?

It's the least important as far as overall functionality, but it's what everyone sees and reacts to.

The GUI is the most important because as you say, it the part that actually gets touched by non-programmers. The UI should drive the design of everything below it--including the database schema , the middleware, and things like the messaging protocols.

I don't like focusing on the GUI up front because their are usually many requirement changes and what not and would have to be redone anyway. Better to wait until a later stage when everyone has had a chance to think about what they really want.

You *should* do the GUI up front because the GUI dictates the design of the entire system. You don't have to make it hi-fidelity (i.e. functional)--you can get away with simple things like Paper Prototypes*. Let the design process be iterative and don't be afraid to throw bad ideas (literally). Paper is cheap, development time is not!

Alas, other departments, project managers, and what not only see the GUI and have no clue about what it takes to support the GUI underneath. The GUI is just the tip of the iceberg.

This is true, and is the exact reason you should nail down the GUI first. How they use it is all they care about, and is the exact reason why you should nail down those requirements before you do anything to your backend. They aren't gonna come bitching to you about how your databases lack some index, but they might complain that your list of videos isn't dropping stop words like "The" or "A". A change to how the list sorts could well affect the entire application stack. Do you want to know about that before or after you finished your backed?

If you do the backend before the front end, your backend will wind up driving the functionality of the GUI instead of your customer. In other words, if you do the GUI at the end, you've invested so much time into the backend it becomes very costly to make changes to the GUI that would necessitate fundamental changes to the backend.

Bottom line, your method is fundamentally wrong. Let the design of UI drive the backend, not the other way around.

* Some people do their mockups in visio or photoshop but I'm personally not a fan as it allows you to make an interface look too real and thus people focus on the colors and fonts when all you are after is the overall grid and the flow of different screens/pages. Worse, your customer might think you are closer to being finished then you actually are (after all, your prototype looked so good that we assumed it just needed the buttons wired in!) Worse still, doing it in visio or photoshop takes more time and the idea of initial prototypes is that you dont invest much time in them so you don't feel bad about throwing bad ideas away. Personally I dont even commit to ink when doing my initial designs, I do it in pencil and when I really like something I trace it over with a permanent marker.

Re:Code Competition may not always work!!!!

[TuringTest]

Better to wait until a later stage when everyone has had a chance to think about what they really want.

If people doesn't now what they want of the software, how do you know you're building the right architecture for them?

Re:Code Competition may not always work!!!!

[Anonymous Coward]

Gnome developer ?

Re:Code Competition may not always work!!!!

[Yetihehe]

My sig may be a rather good match for your post.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

Your right, this shows that manages are completely incompetent to hire software engineers. They don't know how to interview AND they don't know how to judge a good software program when they see one.

Re:Code Competition may not always work!!!!

[AmericanInKiev]

Right,
this is the trade-off,
  the flip point is that the software that looks prettiest - will often be perceived to work best by the end customer as well. Software programming is part math, and part theater.

Perhaps scalability can wait longer than the PowerPoint OS version?

Re:Code Competition may not always work!!!!

[khaledh]

It's precisely because infrastructure code is not visible to the end user that you have to sell that (supposedly elegant) infrastructure some other way. You need to explain what's going on behind the scenes and why it is important on the long term. Upper management will appreciate simple block diagrams explaining that this kind of infrastructure will give them a lot of flexibility and maintainability down the road, reducing the cost of change and bug fixes.

Documenting the backend is also important for other developers who will maintain this code after you. I've had to deal with hundreds of thousands of lines of code with no documentation whatsoever, and it's not pretty.

Finally, I want to mention that not giving the GUI enough attention from the beginning is not good also. I'm a believer that function and form are closely tied together. You can design the best infrastructure in the world, but slapping a GUI on top of it as an afterthought will result in crappy user experience. Also there are a lot of times where certain UI functions, although may seem trivial, actually translates to significant backend design changes. As you mentioned, the GUI is what the user interacts with, and to them it's actually the GUI that represents the application, so it *is* what the application is about to them.

Re:Code Competition may not always work!!!!

[coryking]

You need to develop the low-level stuff first, and do so well and solidly.

What parts you *develop* first dont matter so much as you *design* your user interface first. Note I did *not* suggest you go jumping into *programming* the GUI first. Instead I advocated you *design* the GUI *before* you write a single line of code.

I mean, it is common sense! How the hell do you know what you should be programming before you know how the damn application should work!?

Re:Code Competition may not always work!!!!

[Anonymous Coward]

"I am so sick of programming done this way. If I can't use you program, the infrastructure and middleware is of no value."

Quite true. The point is that the other one doesn't work either, it only seems to. And then, there's the hope for the first kind of systems to reach the day when they work where the others never work.

"I hope you simply walk from any project I might end up using"

That's a win-win situation, since I hope to never have to work on any project where you have any saying.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

Bad news, dude. You won't ever know how the application should work early on. It will be revised continually, even after it ships, if it's anything of value.

You want the low-level stuff to be flexible and scalable enough to handle things efficiently, no matter how the front end changes.

With your approach, that the front-end drives the back-end, you'll end up changing both every time there's a change to the front-end. It should be obvious that this is inefficient, and consequently, poor engineering.

Re:Code Competition may not always work!!!!

[coryking]

The front-end is the whole point of the program. If it isn't driving the backend development, you are doin' it wrong. Companies who let the backend drive development get blown away whenever something new comes along.

Re:Code Competition may not always work!!!!

[thoughtsatthemoment]

Better to wait until a later stage when everyone has had a chance to think about what they really want.

To me, this is an alarming statement. So basically you got your infrastructure in place without considering what they really want. This means your infrastructure is a commodity, nothing special to the project. The GUI part, on the other hand, might have significant consideration of the work flow other than just a pretty face.

It seems your mentality is to produce command line apps. If a real GUI app is expected, it's very likely your infrastructure, even if it's really superior for its own reason, might not be able to integrated with a good GUI.

It's interesting you got +5(insightful) for your comment. But it's as surprising as why this year is still not the year for Linux Desktop.

Re:Code Competition may not always work!!!!

[thoughtsatthemoment]

I can't even conceive of who would be a good "match" for me in that scenario.

Linus?

Re:Code Competition may not always work!!!!

[startled]

I was once involved in a project where this sort of thing was going on, and those that had the better looking GUI got the nod.

I'll settle for the one that HAS A GUI.

This guy's advice is good for his target services and audience. In particular: he's giving advice with no existing relationship with a programmer, who are going to jump feet-first into elance, guru, odesk, and vworker. These first-time users of the services will be lucky to see a project through to a remotely satisfactory conclusion if they only hire one programmer.

Having been in that position once, I can vouch for what he's saying: you'll be ignorant enough of the criteria you should be using, that it's going to be very useful to hire 2-3 programmers for a small milestone up front. You'll get the guy who completely ignores the spec, and sends you something he cobbled together in 10 minutes. You'll get the guy who eats up the full time allotted, then at the very end cancels the project and refunds the money. And you'll get the guy who's actually a solid, communicative programmer, and gets the job done. Then you go forward with that guy.

It's going to be rare that, on your first use of these services, you can make a decision based on a close call, evaluating code quality, UI design, and so on. No, you'll be evaluating "did the project get completed AT ALL?". And you'll learn a lot about how to find people using these services, and how to write better specs yourself, so that you don't waste everyone's time in the future.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

You build a car for the driver

... and you end up with "The Homer".

Re:Code Competition may not always work!!!!

[martin-boundary]

And what's wrong with that? With that design, you'll just need four people to drive the car. If you call them Scotty, Sulu, Chekov and Uhura, then you can pretend to be the captain of the Enterprise. Who wouldn't want to pretend his new car is the Enterprise?

Re:Code Competition may not always work!!!!

[flajann]

Not that I don't mind teaching, and I've done plenty of it and mentoring before. But then it ceases to be pair programming at that point.

Re:Code Competition may not always work!!!!

[flajann]

I can't even conceive of who would be a good "match" for me in that scenario.

Linus?

Well, yes, but I couldn't conceive of a scenario where I'd be paired with Linus!!!!

Re:Code Competition may not always work!!!!

[kbielefe]

My first thought upon reading your example is what a pity the two of you couldn't work together. Different developers have different strengths and the most successful projects use the right people for the right layers.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

I've run into this as well, and its usually because the people making the decisions don't know what the f*ck they're doing. "Gee, this on looks good."

It's like hiring a building contractor based on how well they paint the walls. Great for that next promotion, but hope you're out of there before the house falls down, or plumbing springs a leak.

Re:Code Competition may not always work!!!!

[twebb72]

I would have to disagree in that you should have enough separation of concerns to develop both independently. Some applications require sophisticated back ends and middle tiers (think ETL) to satisfy the development requirements. I agree that UI does often drive requirements from the business side and is often the only communication tool for business decisions. So yes, in most instances UI is more important, because it serves as a communications tool and requirements outline, but it doesn't always offer a complete blueprint like your post suggests. Your response seems to confuse developer requirements and business requirements. The two are very different. The latter being much easier to convey. That being said, get a UI designer and a back end developer. Most good UI designers typically know nothing of good database design and architecture (and vice versa).

Re:Code Competition may not always work!!!!

[Maximum Prophet]

... The competition only focused on the GUI exclusively, but no infrastructure. Theirs looked much prettier than mine. They got the nod, and I simply walked.

I've found the best GUI's have pretty pictures, and a "Read the User's Mind" button. Those designs are always the best. I leave the mind reading subroutines to the backend programmers. (:-)

Re:Code Competition may not always work!!!!

[Maximum Prophet]

If you let the GUI drive the backend, you'll get designs with a "Read the User's Mind" button, and the implementation left for the backend developers.

At least where I work, most of the time the backend has already been designed, and the data has been populated from other GUIs. I'm given the task of taking some information from an Oracle database, merged with some from LDAP, then produce some report that makes sense. I can only use what's already in the databases, and sometimes I have to tell the user they can't have what they want because the information just isn't available.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

I've had similar problems with prototypes I've written being judged by the quality of the UI. I've found that if you can make the UI obviously appear to be of prototype quality, the problems of premature quality judgments based on the UI go away. For prototype I did in Swing a number of years ago, I replaced the standard look and feel with the NapkinLF, which made the entire UI appear to be drawn on paper. The UI still worked, but the appearance made it obvious that it was still a work in progress. It made people realize that the application was a prototype.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

How about letting the requirements drive the design? Some systems/sub-systems don't have a GUI. Then what?

Go with requirements. The GUI should not be coupled to the backend design.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

Even if a GUI is really well designed, if the back end written to implement the design, you could end up getting tied to one specific GUI design and philosophy. While a good GUI design is *critical* to the success of a single product, a well designed back end software is *critical* to the longevity of the platform, and the ability to churn out new products with different GUI's quickly. This is why the model-view-controller architecture has evolved - so one can separate the GUI design from the infrastructure and back end. An argument about which one is more important is not really relevant, IMHO.

Re:Code Competition may not always work!!!!

[Anonymous Coward]

Your "common sense" is idiotic. A GUI does not tell you how the application should work, and should NOT dictate design. Learn to do proper analysis of the problem, and learn to do proper design. Until you do, I will not be hiring you.

Re:Code Competition may not always work!!!!

[flajann]

Yep.

These days I leave the GUI development to others(unless it's my personal projects, of course), and work exclusively on the infrastructure -- the database, the middleware, etc.

Re:Code Competition may not always work!!!!

[flajann]

This is an interesting problem, and more of a 'customer relations' problem

Non tech people (and even tech people) have a funny way to understand things. If it doesn't look like it's working (even if you're building the foundations, etc) then, for all purposes, it's not working!

And I'd say, never, NEVER put the button if the code to make it work is not there. If you put the button they'll say "ok, now you just have to make it work *wink*"

Kinda like saying: "Nice car! Now all we need is the engine, the transmission, the coolant system..."

Re:Code Competition may not always work!!!!

[flajann]

Alas, all very true.

I like sitting down with the users and coming up with a comprehensive overall design, anticipating their current and future needs, and other things they have not thought of but will smack them in the face. In short, understanding the business is essential. A skill that simply takes a lot of time to hone and perfect. Recent CS graduates need not apply. :-)

They always love what I give them after it's completed, and appreciate it even more down the line when the system needs to be expanded -- with my designs, it's easy to extend, as I factor all those details in up front.

They may not appreciate the OOP, design patterns, clever algorithms, or dealing with scaling issues, or the like -- but they love the quick adaptability when the pressure is on. Pay me now or Pay me later.

Re:Code Competition may not always work!!!!

[flajann]

I disagree with one significant thing: the UI is at least as important as the DB, middleware and protocols, precisely because it's what everyone sees and reacts to. I've used some very well architected software be absolute pigs to use because people thought the UI wasn't important. If it's going to be used every day, it should be simple, intuitive and look good. If it's going to be used by non-engineers it's even more important. As anyone who's ever tried to design a good UI knows - simple and intuitive are hard for anything past Hello World. Believing that you can just slap any GUI at all onto a well-engineered piece of software is wrong (I'm looking at you IBM and Sun) and is the equivalent of saying you can throw together a pretty website in 30 mins using notepad.

I don't disagree with you, but I consider the GUI part the part that's easily and quickly redoable, assuming the infrastructure has been properly done. These days, on large projects, you usually have one or two developers who do nothing but the GUI. This is quite fine by me, because they can create all the slick pretty front-ends that I no longer have to bother with. And today most GUIs are done using the web browser anyway, and some have gotten really good at spitting out good CSS, integrating with jQuery, and the like. Me, it always takes me time to tweak the CSS because it has to work across different browsers and different versions, etc. Something that bores me.

Re:Code Competition may not always work!!!!

[flajann]

Don't forget you are programming for end users, the UI is one of he most important things in a software application.
Looks like a lot of "great" programmers forget this and and although their app gets the job done it's a nightmare on users (see Lotus Notes).

Don't even get me started with Lotus Notes. I've seen some badly-designed GUI in my time, but Lotus Notes takes the cake.

You don't have to sell me on the importance to the end-user of the GUI. Obviously that is a step that not only cannot be left out, but is a project in and of itself, and requires a lot of iterations to get it right. Which is why I typically want to leave it for last.

Alas, users being the way they are want to see that part FIRST!!!!! So these days it pays to just hire a guy or two who's sole job is to work on the GUI. I can direct them and point them in the right direction, and they can interface with the impatient and demanding users.

Re:Code Competition may not always work!!!!

[flajann]

Been there, done that. My last major engagement I played the role of DBA/Database Manager, but in my case I had to clean up the mess others created BEFORE I was hired. And what a mess it was! Can you believe PHP scripts used as batch processing launched through the web server by elinks???? Why not just run the PHP directly in that regard? Or just use Bash? Arrrrrrgh!!!

Nevermind the fact there was absolutely NO STRUCTURE to the PHP code. It was worse than spaghetti code in other languages. Not even a hint of any attempt to write code in a concise manner. And no wonder the entire infrastructure began to crumble once they started getting 60K+ simultaneous users *every night*.

We cleaned that mess up, though. But that was a major effort in itself. As the often-stated analogy goes, switching out a jet engine in mid flight. There was NO down time. Fun stuff.

Re:Code Competition may not always work!!!!

[Eil]

It's the geek factor. Ideally, every person in IT has some level of geek in them. But when you have someone who swings too far to the geek side of the spectrum, you wind up with an individual who frequently loses sight of the reality of business needs or doesn't quite realise how non-technical people interact with software.

For example, die-hard geeks make excellent programmers, but they rarely make the best application designers. I worked with one guy who was utterly brilliant with any coding task you handed him. But every time the boss would say, "design me an application that does such-and-such," his design process would last weeks and by the end of it, he had basically invented a special-purpose programming language for the task at hand rather than a plan for building a deliverable piece of software.

Re:Code Competition may not always work!!!!

[flajann]

So you were given explicit requirements, instructions on how to 'win' in this competition, but you decided to go against these requirements and concentrate on something that was not as important to the stake holders instead and now you are complaining that competitive programming does NOT work?

You are the proof that competitive programming DOES work, it's just you failed in that competition.

You are putting many words in my mouth here. You don't know all the details and are making assumptions. But whatever. It was a long time ago anyway. If an empty GUI with no infrastructure will get it done, you the man!

Re:Code Competition may not always work!!!!

[flajann]

This is horrible advice! Your method is why we have such shitty software and is why companies like Apple are stealing Microsoft's lunch! Yes the backend is important and you shouldn't neglect it, but the GUI is what drives the design of the backend! It is, in essence, the high-level requirements document for the entire application stack! If you don't have the GUI design, how the hell do you even know what the bowels of the application should be doing!?

I would think the business requirements are what drives the design and implementation. How can you design a GUI when you don't even have the basic business requirements down solid? Hello. Did I miss something?

It's the least important as far as overall functionality, but it's what everyone sees and reacts to.

The GUI is the most important because as you say, it the part that actually gets touched by non-programmers. The UI should drive the design of everything below it--including the database schema , the middleware, and things like the messaging protocols.

I would strongly disagree, of course. When you are dealing with LARGE projects, you can't even begin until you have the business requirements down solid. I'm not talking about a silly mom-and-pop website here. I am talking about a major enterprise application. I would never, for example, design a database schema solely on the GUI. Makes no sense. There's a lot of backend processing that must take place -- billing, customer management, data stores, and the like. Is the enterprise centrally located, or scattered around the globe? How much data will they have to share? Synchronization, presentation, backup, hardware to support it all. Do you use a sharded database, or a cluster configuration? How does the data have to interact? How does the front-end communicate with the back-end? Is it totally an "intraweb" application? Or will there be an external website? What will be the traffic load? What is the network infrastructure needed to support it? What about high-availability issues? How much redundancy will you need to give a 100% uptime (or dammed near it)? What are the cost tradeoffs? What can the business afford? What are the details of the business operation? How does that need to be supported by the application? What about security issues? Credit card data involved? How do you meed the compliance requirements? And on and on and on.

Only a fool would focus on the GUI first. Yes, it's important, but there are so many other details to get right first. I have seen too many cases where an unscrupulous/clueless developer worked on the GUI first, made it look real good, sold management and the owners on it, only to be found out later there was no attention paid to WHAT REALLY MATTERS. And so the project died.

Well, it is clear whom I am NOT going to hire on my next major project!!!!

To be honest, you sound like a hot-shot junior fresh out of school with only a couple of year's experience. The GUI is the easy part -- probably the easiest of all. Getting all the other stuff that I mentioned right is the hard part. It what separates the men from the boys.

I am currently working on a small project -- a trading platform that I will use personally. It quite literally took me less than a day to do the GUI part, and a couple of weeks to do the real part that matters -- datafeeds, sending executions to the brokerage, getting the acknowledgements back, and keeping track of the trades. I can change and fiddle with the GUI on the fly, and basically I wanted the GUI to be as simple-minded as possible. Basically, into a trade with a single click, and out of a trade with a single click. The software does all the annoying stuff, like figure out what the limit order will be, what the stop out will be, adjust the stops as the trade progresses, and so on.

Why did I write this rather than use the GUI apps the brokerage provides? Simple. Their application sucks.

Re:Code Competition may not always work!!!!

[flajann]

The front-end is the whole point of the program. If it isn't driving the backend development, you are doin' it wrong. Companies who let the backend drive development get blown away whenever something new comes along.

Ever hear of MVC? The front-end and the back-end should be decoupled, really. In an ideal situation, the GUI developers should not have to care much about what is going on at the backend. Just talk to the API. The backend needs to be able to handle the load and other issues that the front-end will need.

You should be able to rework the front-end quickly without too many changes to the back-end. If you can't do this, then something is wrong with the overall design.

It's the business requirements that should be driving both the back-end and the front-end. The front-end should not be leading the show. The back-end needs to be flexible enough to accommodate the ever-changing front-end without too much fuss. Since the front-end is the most dynamic part of the operation, if it were driving the back-end, the back-end would never get done!!!!!

I've had to be called in many, many times in the past and present -- and got paid good for it -- to clean up the mess created with the front-end lead the back-end. It's a quick way to nowhere. Yes, you get instant gratification, but it's a Faustian bargain at best.

Re:Code Competition may not always work!!!!

[flajann]

Better to wait until a later stage when everyone has had a chance to think about what they really want.

If people doesn't now what they want of the software, how do you know you're building the right architecture for them?

Because I spend the time to understand the business. Once you understand that, you've got 80% of what you need. Then you can lead them to the solution that is best suited for them.

Many business types really don't know what they really want, or more importantly, what they really need. It takes a lot of effort and skill to keep them all on the same page, to manage expectations, and to also keep the systems types informed and aware, and the developers on their toes.

Even when they think they know what they want, I still have to spend time to learn the actual business so that I can understand if they are being realistic or not. You'd be surprised how many can be totally way off the mark with their expectations.

Re:Code Competition may not always work!!!!

[flajann]

Finally, I want to mention that not giving the GUI enough attention from the beginning is not good also. I'm a believer that function and form are closely tied together. You can design the best infrastructure in the world, but slapping a GUI on top of it as an afterthought will result in crappy user experience. Also there are a lot of times where certain UI functions, although may seem trivial, actually translates to significant backend design changes. As you mentioned, the GUI is what the user interacts with, and to them it's actually the GUI that represents the application, so it *is* what the application is about to them.

I would agree with this in principle. GUI should NEVER be just an afterthought, but it should not drive everything, either. And yes, there are definitely times that some specific GUI requirement may need significant support from the backend, particularly in high demand environments.

Re:Code Competition may not always work!!!!

[flajann]

I've found that competitive design pays off better than competitive development. It's easier to refactor code than it is the complete design of a piece of software, so it's more important top get it right the first time. For code just use paired programming or a decent code review process (or both).

Oh I despise the "paired programmers" approach! Well, unless the pair are reasonably matched in competence and ability, I see no good coming out of it. And since I've been writing code for the past 30 years and have gotten rather good at it, I can't even conceive of who would be a good "match" for me in that scenario. If anything, I would wind up *teaching* rather than *coding*, which is how it usually goes anyway.

Oh right, there is no one on God's green earth that is intelligent and experienced enough to be your match.. please.

Be a little more conceited.

When I'm being honest, I'm "conceited". Were I to hold something back, I am committing a "lie of omission". If I were to flat out lie, then I would be dishonest.

There is no way I can win here.

Re:Code Competition may not always work!!!!

[flajann]

Better to wait until a later stage when everyone has had a chance to think about what they really want.

To me, this is an alarming statement. So basically you got your infrastructure in place without considering what they really want. This means your infrastructure is a commodity, nothing special to the project. The GUI part, on the other hand, might have significant consideration of the work flow other than just a pretty face.

It seems your mentality is to produce command line apps. If a real GUI app is expected, it's very likely your infrastructure, even if it's really superior for its own reason, might not be able to integrated with a good GUI.

It's interesting you got +5(insightful) for your comment. But it's as surprising as why this year is still not the year for Linux Desktop.

A properly-designed infrastructure will interface with the GUI just fine. The GUI, though, is the easiest part to change, and it will change quite a bit over its life cycle. The whole idea behind spending the effort on the infrastructure is so that it can support an ever-changing GUI without much complaint.

And like I said before, it's the business requirements that should be driving both. Marketing will have a VERY strong say.

Re:Code Competition may not always work!!!!

[flajann]

It's going to be rare that, on your first use of these services, you can make a decision based on a close call, evaluating code quality, UI design, and so on. No, you'll be evaluating "did the project get completed AT ALL?". And you'll learn a lot about how to find people using these services, and how to write better specs yourself, so that you don't waste everyone's time in the future.

Oh yeah, tell me about it. I've seen too many projects die and wither on the vine. And it was always due to either bad management or unrealistic expectations. The worst of the lot that I was personally a part of was this Revenue project at Conrail. (Remember them?)

Back then, I was just a consultant working on a part of a major project to redo the revenue tracking system that was originally based on Cobol running on mainframes. That was my only direct contact with mainframes in my career, and quite frankly, I never want to be near one of these beasts ever again.

I recall writing email on the mainframe interface once, and had mistyped a line. I could not figure out how to delete the line, so I asked one of the "old hats" there.

I watched in in moral shock and disbelief as he had to do several keystrokes and go through 2 or 3 screens just to delete a SINGLE LINE OF TEXT!!!!!!

But I digress.

That project was horribly managed, and went nowhere. And then management had the gall to call us all into a meeting to tell us: "You have all failed". "You", meaning all the contractors and developers. Oh, management couldn't possibly be at fault could they?

And to show how the sheer insanity had progressed to utter lunacy, they had us all to change the names of the files of our source code on our PCs to be like the filenames on their mainframes. Basically, 2 letters followed by 4 digits. So "WHATTHEF.CPP" would be renamed to "WF3377.CPP". This effort was supposed to make the entire project more "manageable." In those days, PCs could only handle 8.3 characters (thank you Microsoft!!!), and it was hard enough to know what a file was when the name had to be limited to 8 characters. But now only 2 meaningful characters? I went insane.

Needless to say, I quit. I already had another job lined up on that day they told us we "failed".

And a year later, Conrail finally closed its doors forever. Good riddens!!!!!!

Re:Code Competition may not always work!!!!

[flajann]

Don't get me wrong -- I would love it if I had someone that was complementary to my own abilities. That would be a rare person these days.

Re:Code Competition may not always work!!!!

[strikethree]

"Yes the backend is important and you shouldn't neglect it, but the GUI is what drives the design of the backend!"

I have argued with people who have that idea before. It is like talking to a brick wall. The "back-end" IS the project. You can attach any GUI at all to it and as long as the "back-end" works properly, everything will more or less be ok. The front end could be a web page, native widgets and windows, a curses environment, whatever. As long as the GUI can send the necessary commands to the "back-end" and the GUI is comprehensible and usable to the user, the GUI does not matter.

Ultimately, it is not the GUI that drives design. That is like saying the cart goes in front of the horse... which is exactly what the OP was referring to. A GUI is merely an abstraction layer to make the program itself usable by mere mortals. Permit me to repeat that since it is the point of this entire comment:

A GUI is merely an abstraction layer to make the program itself usable by mere mortals.

(Of course, which seems to be your objection, if the GUI is not adequate then the program itself is not fit for use.)

Regards,
strike

Re:Code Competition may not always work!!!!

[flajann]

I've had similar problems with prototypes I've written being judged by the quality of the UI. I've found that if you can make the UI obviously appear to be of prototype quality, the problems of premature quality judgments based on the UI go away. For prototype I did in Swing a number of years ago, I replaced the standard look and feel with the NapkinLF, which made the entire UI appear to be drawn on paper. The UI still worked, but the appearance made it obvious that it was still a work in progress. It made people realize that the application was a prototype.

I wish NapkinLF was around when I was playing around with Swing on this project way back when. They were using this GUI layout application, and I was coding the GUI by hand. Of course theirs would always look sweeter -- at first, anyway.

And then they wanted me to fit my framework for their GUI layout application, which generated shitty code that was completely incompatible with what I was doing. But I was going to find a way to make it work anyway. I always do.

I think most GUI layout apps are crap, at least the ones I've seen over the years. Unless you write code to what they had in mind, you're completely lost.

If someone isn't skilled enough to compare...

[Anonymous Coward]

If someone isn't skilled enough to compare the quality of two programmers and select the best one for their project, what makes them think they are skilled enough to compare/judge the quality of two programmer's work?

This seems to be a recipe for premature optimisation and poorly maintainable code. It might get you a good first milestone, but it might be screw you in the long run.

Isn't that part of LEAN?

[nicc777]

Just worked on a project using LEAN. What we would do is let all developers deliver the same prototype. At the end we evaluate each one, pick the best and move on. In diverse projects, different developers will excel in different areas. This was one way we could quickly see who is strong in which areas making later task assignments easier - especially when you are done with prototyping and now need to add all the other functional requirements. This sounds very similar...

Re:Isn't that part of LEAN?

[luis_a_espinal]

Just worked on a project using LEAN. What we would do is let all developers deliver the same prototype. At the end we evaluate each one, pick the best and move on. In diverse projects, different developers will excel in different areas. This was one way we could quickly see who is strong in which areas making later task assignments easier - especially when you are done with prototyping and now need to add all the other functional requirements. This sounds very similar...

No, it is not. Not by a long shot. You are missing the entire point and essence of that practice.

The author of that ill-advising article is suggesting small businesses to hire three independent programmers (none of them working in collaboration, but in competition, and thus, not necessarily acting with anyone else interest in mind), and somehow be technically capable of evaluating which is the best (and only one to pick up.)

Yeah right.

The lean approach you are suggesting entails pitting ideas and designs for later evaluation by a team of colleagues. Yes, one design gets picked up as the primary contender. But chances are that other ideas from the other designs will be picked up and integrated to the final design as well. If this integration of ideas does not take place, and the only thing being done is to take a winner to the exclusivity of the other designs (which is what will happen with what the blog author is suggesting), then you are doing something wrong. That's not engineering.

Re:Isn't that part of LEAN?

[Anonymous Coward]

That's not even close to Lean. It's pure waste generation. If a consultant told you this, it's time to fire him.

Personal Experience

[fantod]

Before they fired me, we would hire people for a week or 2 week contract. I think this is much easier for both sides to manage than a milestone. I agree with some of the comments above. Having only the first win selects for the wrong sorts of traits. If you did the least amount of tasks because you were helping the other programmers, or adding documentation to the wiki, or identified and fixed one of the many core design flaws in the code, I'd still hire you.

Sounds a lot like free market economics

[Anonymous Coward]

And also like free market economics, it will never work in reality and will probably actually end up sending everyone's computer back to the 1970s

Re:Maintainability

[Anonymous Coward]

It's not enough to take into account quality of the finished product as such. You also have to take into account how maintainable it is and how easily it can be modified for future requirements. That's one of the thoughest parts of software development and that takes years to learn and is easily overseen by clueless management.

People who use Linux have their heads up their ass

[Anonymous Coward]

Fucking dick smoking queers.

bullshit; the most experienced of them will win

[zugedneb]

if there is not much research or serious architecting involved, but mostly design, than the most experienced will win...

if it is a difficult poblem, than there is no win in developers hiding information from eachother...

Sweat Shop?

[drooling-dog]

As an employer I'd like the idea a lot. As a programmer, though, this would quickly lead to intolerable working conditions. Are the other "candidates" willing to work 16-hour days in order to win the job permanently? Then, unless I'm a lot more efficient than the best of them, so will I. Then, once the initial milestone has been reached, I will have created expectations that would be impossible to satisfy in the long run. I'd have to be fairly desperate to put myself in a situation like that.

Not at all

[gweihir]

There are multiple problems with this approach. One is that you cannot easily evaluate code quality. The important characteristics will show only over time or if you have somebody very experienced invest a lot of time into the evaluation. A second one is that you cannot know whether the best person until the first milestone does actually know how to pace him/herself. It is well possible to have somebody come in best that later burns out. At the same time it is well possible to have somebody that actually would do reasonably well for the whole project duration, not do best until the first milestone. This could be prevented bu allocation generous resources for the first step, but it seems very likely that nobody is going to do that, and even more likely that resources will be far too low to save some of the triple effort.

My take is that this is another stupidity by people that do not understand software creation. This is doomed to fail. Personally I would refuse to participate.

Re:Not at all

[thePig]

I agree with all your points. I would also like to add the effect of confidence.
For me, if I am confident that I am in it for the long term, my effort goes up quite a bit.

The effort is not fully visible to my boss all the time - since most of the effort goes in non-obvious, but nevertheless extremely important aspects of programming - thinking deeply about design and deciding the exact architecture which can handle most of the future enhancements, creating the best aspects for UI design and exact representations of qualitative and quantitative information, creating good test cases, creating bug proof code etc.

But, even if the effort is not visible to my boss straightaway, I dont have to care, since I am confident that my boss has confidence in me and that I am not going to be a fungible commodity to him.

If, as per mentioned in the article, that sort of competition and lack of confidence in workers is rife in the company, I am not going to create always the best output - rather I will be going to produce the safest output - the one with the most visibility - never mind how it performs later, after I get the advantages out of it. This is going to cause negative effects in the company in the long term.

I was in a big (1 lakh + employees) company earlier. There I was considered an easily replaceable resource - even though my performance was quite good, with this amount of people, they could always get a better person than me to replace me. Even though I did not know it at that time, my performance was then less than optimum - i.e. I was not trying to improve myself a great deal - due to lack of confidence and this was a negative cycle.

After quite a few years with this company, I was burned out, and I left to start my own company. Then I was absorbed (along with my product) by another startup. In the last 2 years, I think I have learned as much as the 10 years before in the big company - and my quality of work has now improved a great deal - this especially being because in the startup - and my own company - I gained a lot of confidence that I am in it for a long time.

Actually, the aspects of confidence is extremely visible in sports etc, wherein if the player knows he is in it for a long time, he tries to play his natural game - and he is not hamstrung by the fact that a risky move will not jeopardize his career.

Why the management in most companies do not understand this - I have no idea.

Re:Not at all

[Anonymous Coward]

There are multiple problems with this approach. One is that you cannot easily evaluate code quality. The important characteristics will show only over time or if you have somebody very experienced invest a lot of time into the evaluation. A second one is that you cannot know whether the best person until the first milestone does actually know how to pace him/herself. It is well possible to have somebody come in best that later burns out. At the same time it is well possible to have somebody that actually would do reasonably well for the whole project duration, not do best until the first milestone. This could be prevented bu allocation generous resources for the first step, but it seems very likely that nobody is going to do that, and even more likely that resources will be far too low to save some of the triple effort.

My take is that this is another stupidity by people that do not understand software creation. This is doomed to fail. Personally I would refuse to participate.

Obviously you did not read the article. You would not even know you were participating, you would simply be doing a project for a guy who hired you.

Go read the article.

Assuming you won't, here's a quick summary: Write good specs for the first milestone of a project. Post this 2+ times on various sites, only mentioning that this is merely the start of project and that you might give them more work down the line. Choose programmers to do your work. Wait for them to finish. Evaluate how they did. Assuming at least one of these programmers weren't terrible, pick the best one. Voila, you have a decent programmer who you can feed more work to and have a decent chance of getting quality work from.

Now, your objections do have merit, but really look at what we're talking about: hiring freelance programmers to complete your project. Not in-house. So your objection of:

One is that you cannot easily evaluate code quality. The important characteristics will show only over time or if you have somebody very experienced invest a lot of time into the evaluation.

has some validity. That is a problem... but what alternatives do you have? You don't have a long-standing awesome programmer sitting around waiting to do your bidding (or obviously you wouldn't be fishing for one) and your alternative is really just to hire one programmer. And spend an entire project budget finding out if he can produce rather than testing the water with the first milestone.

A second one is that you cannot know whether the best person until the first milestone does actually know how to pace him/herself. It is well possible to have somebody come in best that later burns out.

Again, you don't have someone in-house. How do you know this about anyone you don't already have a long standing relationship with?

I'm not even going to bother commenting on the rest, other than to say you missed the point of the article (because you didn't read it). The point was not to use this as a method of developing software, the point was to use this to FIND a developer who can develop your software, and then develop a long standing relationship with him if he works out.

What happns when one is fast other slower better c

[Joe The Dragon]

What happns when one is fast with rushed / buggy code and the other one is slower with better code?

Does the PHB pick the fast guy over the guy how is slower but has better code?

Christ, what a moron

[0xdeadbeef]

Doesn't this guy sound like every drunk imbecile who, upon finding out you write software, wants to sell you on how he's got this great idea for the next Facebook or Apple or eBay? For the percent of a percent of them who act on their delusions, they are the ones you see ridiculed on the Internet for ridiculous job postings.

These people have a conception of software development derived from 24, and have the intelligence necessary to remain that ignorant.

But do you know what's most funny? He betrays the shibboleth of every incompetent business person, and assumes the same of his audience: he thinks he is an expert in user interface design. "Write a detailed walk-through of every click." When you see any spec like that, withhold your laughter, and decline whatever they are offering.

Re:Christ, what a moron

[luis_a_espinal]

Doesn't this guy sound like every drunk imbecile who, upon finding out you write software, wants to sell you on how he's got this great idea for the next Facebook or Apple or eBay? For the percent of a percent of them who act on their delusions, they are the ones you see ridiculed on the Internet for ridiculous job postings.

These people have a conception of software development derived from 24, and have the intelligence necessary to remain that ignorant.

But do you know what's most funny? He betrays the shibboleth of every incompetent business person, and assumes the same of his audience: he thinks he is an expert in user interface design. "Write a detailed walk-through of every click." When you see any spec like that, withhold your laughter, and decline whatever they are offering.

Yep, pretty much.

Re:Christ, what a moron

[Krahar]

"Write a detailed walk-through of every click." When you see any spec like that, withhold your laughter, and decline whatever they are offering.

In the case of some business person with no background in UI doing something like that, definitely run. However, a spec like that could actually be absolutely wonderful, if it is the outcome of a number of prototypes, even just paper prototypes, made by someone who knows what he is doing. Then I, a programmer without a particular competence in UI design, have a design for the UI that has been shown to be workable. So I can get on with the business of implementing it instead of having to make my own user sessions with prototypes - because I most certainly hope that I'm not as good at that as someone who specializes in that. It's not a detailed UI spec that is a problem, it's a detailed UI spec that some moron pulled out of his ass that is a problem - as indeed it seems would be the case in the situation you are commenting on.

Re:Christ, what a moron

[VTI9600]

How is a programmer any more qualified to do UI design than a business person, who we can assume has at least some idea about how he wants people to use the software? Who's capital is being risked in this scenario (excluding of course lame offers of equity in exchange for labor)? The person taking the risk should have the final say on the design even if you don't agree with it. A good programmer would make suggestions for UI design, but not become offended if those suggestions get rejected.

Re:Christ, what a moron

[0xdeadbeef]

> How is a programmer any more qualified to do UI design than a business person

How is a business person more qualified to understand business than a programmer, who we can assume has at least some idea of the business domain he is modeling?

Sounds pretty stupid when you put it that way, doesn't it? So why do you assume that user interface design isn't part of the repertoire of any programmer who writes customer-facing applications?

> A good programmer would make suggestions for UI design, but not become offended if those suggestions get rejected.

A good programmer has the freedom to find clients or an employer at a competence level appropriate to his own.

It is remarkable, though, that people will blindly trust a programmer to make decisions on the safe handling of billions of dollars worth of data, and yet second-guess everything that programmer does that they can actually see.

Re:Christ, what a moron

[Anonymous Coward]

Yeah, he only wrote the software that ran CdBaby.com for most of the last decade. If you're going to engage in ad hominem, at least *try* to find something about about the hominem first...

Re:Christ, what a moron

[nametaken]

It's not about the basic UI design, it's the click-for-click walk-through of what you'll do and what you'll see as a result. I've tried this numerous times before and regular people don't have a real grasp of basic logic and possible outcomes. This leaves you with ridiculous lines of thought that assume one possibility after they've described a situation that could result in 5,000 different possibilities. They invariably fail to recognize that their "process" generates 5,000 possibilities and don't account for 4,999 of them. When you point this out, they get flustered and embarrassed and end up saying, "Oh right... well, uh... do what you think makes sense." Or they spend 3 weeks having meetings to resolve all 5000 when you could have just provided a better way of doing it.

Re:Christ, what a moron

[Anonymous Coward]

not to reply for the parent... but I expect they knew how to really do good UI, which is only through an iterative process, not a "detailed" upfront spec.

or did you think the iPhone, etc, sprung from some static a priori walkthrough steve jobs specified in a powerpoint???

Re:Christ, what a moron

[Anonymous Coward]

Just because a programmer isn't laying cash down on the table to get the job done doesn't mean he's not laying down capitol. He's putting into the job a chunk of his life, which is an investment. That investment can be low risk or high risk depending on whether the leaders are marching the wrong way. Sometimes the leaders can pay their way out of a small set back, but typically they make mistakes on the scale of Napoleon's invasion of Russia. Afterward, they leave the battlefield lamenting on how if the solders didn't suck so much, they wouldn't have died.

Re:Christ, what a moron

[gweihir]

Indeed. And to think that there are quite important applications, that do not have a GUI at all and are better off without one. Personally, I strongly believe a coder that is not proficient on the command line has no business writing code in the first place.

Re:Christ, what a moron

[VTI9600]

The difference is that the programmer (usually) gets paid whether the business succeeds or fails. The investors don't. Exchanging time spent working for cash does not involve substantial risk. Investments are measured in capital (cold, hard cash), not life experience, fuzzy feelings or anything else along those lines.

Re:Christ, what a moron

[VTI9600]

How is a business person more qualified to understand business than a programmer

First of all, it doesn't matter. The client is the one taking the risk while the programmer (at least in theory) gets paid regardless of whether the business succeeds or fails. Too many programmers take this for granted, and fail to appreciate the risks that are being taken to pay their contracts/salaries.

Secondly, the presence of capital in the hands of a client or executive is at least some (albeit a weak) indicator of market confidence in that person's decisions. At some point, they were able to attract investors who believed their sales pitch, or were somehow able to earn it on their own through other successful ventures.

who we can assume has at least some idea of the business domain he is modeling?

Huh? How can we assume that? Programmers are hired for technical ability, not business domain knowledge.

Sounds pretty stupid when you put it that way, doesn't it?

Indeed it does, but I didn't say it...You did.

So why do you assume that user interface design isn't part of the repertoire of any programmer who writes customer-facing applications?

Certainly, any programmer worth 2 cents knows the mechanics of how to build a UI. But programmers (especially those who work solo), tend to be bad at designing UI's because they lack the perspective of someone trying to use their system for the very first time. The countless hours they spend pouring over every detail makes them experts on what is going on in front of and behind the scene, so they often don't take the time to make things user-friendly or write help docs. Any system *you* design will seem useable to you, but you need an outside perspective to test that hypothesis. I have yet to meet a programmer that went out and actively recruited end-user testers as part of their UI design process. It is usually just the digital equivalent of licking their thumb and sticking it in the air.

A good programmer has the freedom to find clients or an employer at a competence level appropriate to his own.

Right on point with this one. If you suggest design improvements and they ignore the valid issues you present, then you should indeed look for another client/job.

It is remarkable, though, that people will blindly trust a programmer to make decisions on the safe handling of billions of dollars worth of data, and yet second-guess everything that programmer does that they can actually see.

You are obviously angry/disgruntled over an employment situation. Don't let that anger cloud your ability to reason and keep things in perspective.

Re:Christ, what a moron

[VTI9600]

I can relate to what you are saying...When you see a case like this, you can (as I said) make a suggestion for a more elegant design. If they ignore you, then start looking for another job/contract. Let them shoot themselves in the foot if necessary...they've earned that right.

A detailed specification is normally a good thing since it takes the guesswork out of building software. As a side-effect, it also limits the creativity of programmers, which they don't like. But business decisions can't be made for reasons such as this. If there is a problem with the spec then the programmer should suggest a fix. Otherwise he should just do his job and code it.

But regardless, my main point was that programmers (such as the OP) tend to belittle the risks that clients/executives take in hiring them. It's a fair trade-off when you think about it...most of the reward for a business' success goes to the investor, but so do it's losses. Programmers are exchanging their labor for a fixed amount of money that doesn't depend on business profit or loss.

Or, to put another way, its fair because the person who takes the risk does not have to do the work and the person who does the work does not have to take the risk.

Re:Christ, what a moron

[0xdeadbeef]

The client is the one taking the risk...

Doesn't matter in the slightest. Whoever signs the checks can demand that programmers code in INTERCAL while wearing lederhosen. It is the competence of someone who would dictate design well beyond his area of expertise that is in question.

Programmers are hired for technical ability, not business domain knowledge.

Now I know the scope of your ignorance.

But programmers... tend to be bad at designing UI's because they lack the perspective of someone trying to use their system for the very first time.

I could claim that your anger at bad software has clouded your ability to reason, but it is obvious you lack the experience to even support that generalization.

And then what?

[Azarael]

And who is to decide which programmers work is better? Hey wait..

Next you'll have to have another competition between two managerial candidates to see who does a better job of judging the programmers' work.

Gimmickry is not going to solve the issues that we have in software development. You can probably only count on two hands the number of true 'one size fits all' solutions and this isn't one of them.

Bad example: The Soul of a New Machine

[walmass]

The story in TSNM: one programmer was asked to build something quick and dirty in 6 weeks, the other one was asked to build something much more detailed. the quick and dirty version was used until the detailed version came out 5 months after the first one. There was friendly competition, but this does not match at all the "one will fail, one will be so-so and one will be great."

No

[Anonymous Coward]

No. Now get back to work.

False assumption

[slasho81]

This method of selection is based entirely on the false assumption that competition brings out the best of people.

Depends on the knowledge of the hirer

[Anonymous Coward]

If one of the hired development teams hacks an app together in short time doing strictly what is required by milestone one, it can still be of poor quality because it can lack a grand design which can haunt the dev-team for the rest of all the milestones, in terms of scalability, documentation, neatness etc.
In short, milestone 1 in a fixed time setting, is a bad indicator of good code.
However if the hirer can look through these hacked up apps, He could make a better educated guess, but we all know the 'boss' never knows something about those "damned computers" and he loves shiny short reports and a working program developed by yesterday.

If you need experts in gaming the system--

[dpbsmith]

--then a task which rewards those who game the system is certainly a sound approach. :) ---Irony, note smiley.

Seriously, what message does this sort of thing send you employees.

1) We are willing to have people work on things that will never get used.

2) We like to fire people, two out of three in this case.

3) We do not trust any of you.

4) We enjoy imposing pressure that is not intrinsic within the task itself.

5) We do not trust our ability to recognize good programmers. Something to keep in mind at review time.

6) We judge by "results," meaning we do not judge the fundamental underpinnings of those results.

No

[Anonymous Coward]

A "competition" like that tells the prospect far more about the hirer than vice versa. It tells the prospect to run.

A competition only tells you who has the most superficial knowledge. Because of the time limitation inherent in the competiton, you never learn who has the most forward potential.

Also, what does the loser tell in interviews for his next job? "Well, I worked there for six weeks, but the other guy got to stay on survivor island and I didn't." In other words, both sides invested 6 weeks of inculturation and learning about a program knowing that fifty percent of that investment would be wasted. Sounds like they're both idiots to me.

If you're so incompetent at picking talent that a "Survivor Island" process will waste less effort than traditional hiring with probation, you're to incompetent to be involved in the hiring process, and have so little respect for your direct reports that only someone with no self-esteem will work for you.
 

two examples: winning and losing

[John_Sauter]

I have been involved in this sort of competition twice. In one case my group won the competition, in the other we lost.

In the first case our group was developing the software for the DN60-series of communication processors for the DECSYSTEM-10. Another group was developing equivalent software for the DECsystem-20. I whispered in the ear of the product manager, telling him that if the other group failed to deliver, we could port our product to the DECsystem-20 in three weeks. As it turned out, the other product was not satisfactory, so he told us to do the port, and we completed it on time. (Of course, we had started preliminary work on the port weeks earlier, but that work would have been wasted if we had not gotten the go-ahead.)

The second time this happened to me was on the software for the PrintSystem40, a large-scale printer built out of a high-speed copier, similar to a fully-expanded HP LaserJet 9000. Our group was in competition with another group for the on-board software and the print spooler. The other group's software was chosen, I think because our on-board software required a floppy disk drive for error logging and theirs didn't. We offered to send them our spooler, but I don't recall if they used it.

What about the employer's investment?

[Walter White]

Projects I've worked on include specifying requirements as a first step. That usually involves a huge investment on the part of the employer. They're going to have to spend even more time bringing three developers along. By the time the system is fully specified, it is likely that the weakest developer will have benefited greatly from the work of the strongest developer. That is likely to provide an overall improvement in the spec, but it won't make the decision making process any easier. At worst, the employer may get tired of answering similar questions and the last developer will suffer as a result.

Of course if there is a fully defined spec to work with, then the designer or programmer can start w/out a lot of employer involvement. I've never actually worked on a project like that but I suppose they do exist.

Define "best"

[mwvdlee]

How will the company know which of the three programmers was actually best? Will they just look at how many features they managed to stuff in, no matter how badly hacked it is. I hope not.

No, they should also hire a code reviewer. Better still, they should hire three code reviewers in case the other two aren't any good at their job.
But how do you know which one is actually any good.

Better hire a code reviewer reviewer as well. Or three.

Sounds like this wasn't such a good idea in the first place ey? Guess whichever manager thought of this wasn't so smart. The company should have just hired three managers and let the board of directors decide how well he's doing.

Better make that three boards of directors and have three sets of stockholders decide which board is least incompetent.

And on and on until you come to the inverse of "atomic"; a point where it is no longer physically possible to have three separate larger units.

Re:Define "best"

[Murdoch5]

How will the company know which of the three programmers was actually best?

Run there program under hard performance and stability checks. The one to pass all of or most of the test wins. What you should look for in the first code milestone is the ability that the code is clean, well put together and can be moved around for portability.

Re:Define "best"

[mwvdlee]

What you should look for in the first code milestone is the ability that the code is clean, well put together and can be moved around for portability.

...none of which you can test by...

Run there program under hard performance and stability checks. The one to pass all of or most of the test wins.

Re:Define "best"

[Murdoch5]

code thats well put together will pass hard performance tests, other wise it wasn't well designed and by that stand point it will be unstable even if it take 100 years to memory fault. So actually

..none of which you can test by...

should be

..All of which you can test by...

Re:Spring

[TaoPhoenix]

Not always. The ones who Were There are the ones I respect. But there really is a serious problem first nationally trumpted by Dilbert, that "managers" DO "spring forth from nowhere" because they're good at the old high school Let's Make a Clique games. Getting rid of those guys is a pain because they outrank you, and usually too savvy to do anything truly stupid. Rather, they specialize in doing Vague Nothings.

Better Development Through Competition??

[Anonymous Coward]

Holy Crapolie...

Welcome to 1900

BNR experience

[PsiCTO]

Back when, Bell-Northern Research used to launch 2 or 3 parallel dev teams on a project and select the best result. Obviously they had cash to do that, but the key is that they let the teams run to the end. Each team got to complete a whole project and there were no winners or losers, at least as far as your career went in the company. At least that was the idea.

When budgets were tightened, they went back to a more traditional approach. I wonder if anyone did a study on those days... Might make a good thesis.

Anyone from those days care to comment?

...you'll pay more for worse programmers.

[Anonymous Coward]

See, there's real demand in the market for great programmers -- it's people that are not that good that are a dime a dozen.

So the natural result of making programmers artificially compete for a job is... either:

1. pay more to entice great talent who could get a job without the stupid competition elsewhere, or
2. resign yourself to seeing such talent disregard your offer and directly go elsewhere.

In the end, you'd end up paying more and getting less.

Competition is great when you have to talk

[istartedi]

Competition is great when you don't have to talk to your competitors. When you chose a vendor or a product, competition rules.

If the "competitors" have to sit down and have lunch every day it's a different story.

I can see two possible things happening. If a particular team consistantly wins, this might initially seem like a good thing--you can just lay off and/or reassign the losers. Now, how good is that for morale? Even if the winners really are superior, will the knowledge that they are out the door if they lose a competition help them perform? Is that the kind of challenge that motivates people, or will they just decide to switch jobs to another company where this doesn't happen?

Are the best and the brightest really going to like this kind of environment?

Also, the "not the best" programmers might turn out to be more useful than you think. We may discover that having people who work at different levels of proficiency is actually valuable. Maybe those people are better able to explain the system to non-programmers. Maybe they are more patient explaining things. You might be taking the meat and potatoes off your plate with this strategy.

The other possible outcome is that people might collude to produce similar work. This kind of stuff happens at factory jobs all the time (don't work too fast, they'll speed up the line on us).

You know what you'll get?

[spiffmastercow]

There are 2 types of people who would accept this kind of condition: those who suck and those who are desperate. The desperate will leave as soon as their crises are over with, leaving only those who suck and can't find decent employment elsewhere.

Works for Iran

[Anonymous Coward]

The most high profile example of this approach that I can think of occured recently in Iran. They needed to build bigger balistic missile, capabable of carrying warheads that were, um, just a little bit heavier than a conventional warhead, and they also wanted to be sure it would be delivered on schedule. So they kicked off not one but two completely separate project teams with the same goal. This would cost more than double the price, given that rocket scientists were already in short supply, and there would be some obvious contention for human resources between the projects. Thats military thinking for you, and it this case I think it panned out quite well in the end.

You need incentive to do a good work

[Yvanhoe]

Except... not : http://www.youtube.com/watch?v=u6XAPnuFjJc
The video is good but the tl;dr is : give monetary incentive for an intellectual work, the more you pay people the LESS they work. That is the result of a few sociological studies. Give programmers a good enough pay so that he doesn't worry about money, give him autonomy and challenging objectives and you'll get better result than with a promise of a 20k$ bonus.

Two jobs then

[Anonymous Coward]

t's not a new idea — the practice of pitting two different programmers against each other on the same task was noted three decades ago in Tracy Kidder's Soul of a New Machine — but one that never gained widespread acceptance. Should the programming code-off be adopted as a software development best practice?"

Fine, they shouldn't mind us taking two jobs and siding with the one we like in a few months.

A million monkeys...

[mevets]

Has the same problem; identifying the best is another problem, and even identifying metrics for determining the best is far from obvious. As fortune keeps reminding me: "Any sufficiently advanced technology is indistinguishable from a rigged demo".

Suggested reading

[Anonymous Coward]

The idea of competing software development teams is one of the central themes in Tom DeMarco's book "The Deadline: A Novel About Project Management".

Good programmers have options.

[Anonymous Coward]

Good programmers have options. Pull this BS and they'll exercise them.

I currently work at a place that does this. About 60% leave in less then 6 months. The rest stay for years and years.

The only problem is that the people leaving are the ones you'd want to stay. They can't get rid of the sub par people because they're the only ones who have any institutional knowledge.

The "hire and see who works out" approach leads to a real shitty office environment. You get people desperately trying to scramble to the top and take other people down. It is toxic, and the only people who put up with it are those with no other options.

Work together

[Midnight Thunder]

If you have to uncooperative programmers that can't work in a team, then this programming competition could work, but be ready for increased chance of burn out. In general though getting these two programmers working together is probably the best of action. There is a lot to be said for bouncing ideas off each other and motivating each other.

Jump to Conclusions

[Loualbano2]

I think I would rather get hit by a car and then build a "jump to conclusions" mat.

ft

Maybe Not

[Javagator]

pitting two different programmers against each other on the same task was noted three decades ago in Tracy Kidder's Soul of a New Machine

The book mentioned in the summary is about a project at Data General. I think it is interesting that they aren't in business anymore.

At my company, every one knows who the best programmers are, even management. We don't need this kind of nonsense.

Heard of a similar experience

[eulernet]

The development competition is nice when the project is very short, and no quality is needed, so most of the consultants projects are in this category.

However, it's the most terrible approach for long time projects.

One of my colleagues explained me that in his previous job, there were 2 software architects who competed this way when a new extension in their project was needed.
The winner was never chosen by the code quality, but by the first delivery, so I can only imagine how terrible is the code to maintain, since most of the code has been written in a few minutes.

There is a known rule that states that the most time is spent on writing the first code, the least time is spent on maintaining it.

Well no

[sujies]

Such an approach might at best be adopted in companies like Google or perhaps during competitions,
The rest of the corporate companies are filled with managements who would never admit
to the individual superiority of one of their employee over others.

GUI is more important but...

[SuperKendall]

Others have noted that the GUI is actually the more important part. The underlying systems should be subservient to the needs of the GUI, to make what is required possible.

That said, maintenance of something once built is usually pretty important too.. If I were running something like the competition you were imn, I'd actually evaluate who did the best GUI, and who built the best backend (based on code review and a description from each team on how the infrastructure was laid out). Then I'd have that backend team re-write the blackened to make the GUI performant, and then I think you'd really have something (and not necessarily have to fire anyone).

Amdahl got started that way

[realeyes]

My first job in IT was with Amdahl Corp. Gene Amdahl was the leader of the IBM 360 design team. When IBM went to design the 370, Gene's team was one of 3. His team's design used VLSI, which was not common at the time. The problem for IBM was that they would have to build all new manufacturing facilities. So they chose a different design.

Gene left the company and took much of his team with him. He got funding from several investors, including Fujitsu and built an IBM 370 clone that ran circles around the IBM machine. IBM's response was to redesign the architecture, which forced Amdahl to focus on keeping up with the changes instead of improving performance. Still, the company gave IBM some serious competition which was good for customers.

I doubt that this could happen in today's 'IP hoarding' world.

Later . . . Jim

They used to do that at SAIR...

[Anonymous Coward]

...you know, the now-defunct Linux certification startup. Take two "technical writers" (read: college students), assign them to write the same chapter in the upcoming certification manual, and pick the best one. Unfortunately for those sad saps who shelled out for the original SAIR linux cert, I think my chapter on UDP was picked.

Better Idea

[Anonymous Coward]

Hire two programmers to work independently on the project while reviewing each others code. That way everything thats even slightly hacked will be corrected by the other guy because he needs it to continue his work, that way you can often get more then a doubling of the development speed, and you get information sharing free in the process since each coder has to document properly along the way.

Did anyone actually read TFA?

[SquirrelCrack]

If put in the context of how to work with "talent" found on sites like elance.com, guru.com, etc. it's actually pretty good advice. In short, build a solid requirements doc, break it down into simple milestones, (since you are already scraping the bottom of the barrel of commoditized software development "talent") pick three providers and see which one actually delivers something for your first milestone.

When you're working with dirt cheap developers that are most likely off shore, all of this sounds like pretty good advice to me.

I HATE people who generalise ...

[recrudescence]

I HATE people who generalise ... it's always fat bald middle-class suburban under-achieving married white people who do that!

Re:I HATE people who generalise ...

[khallow]

fat bald middle-class suburban under-achieving married white people

"How did he know? ... How did he know?"

Define "good"

[Kittenman]

Written quickly or bullet-proof? Easily maintainable? With accompanying documentation or free-standing? Open and extensible?

I won a major contract for my employer this way

[Anonymous Coward]

A large mail-order company had decided to open retail stores, their Point-of-Sale software wasn't working right, the software vendor seemed to be unable to fix the major problems with the system, and they were opening in two weeks, ready or not. Since the company I worked for at the time used the same programming system (Progress DBMS), we were called in to see if we could help. I was sent out of town on an hour's notice to do whatever I could to get the system working.

When I arrived, the project manager told me that their biggest problem was an inventory report that took over 24 hours to run. The software vendor had a programmer on-site, but he had been unable to make it run faster. The project manager told the vendor's programmer and me that whoever fixed that problem would get all future work.

I couldn't believe that the inventory program needed to take that long, and my first thought was that it was an index problem of some sort (missing index, corrupt index, or program that wasn't using the best index for the job). It took me a few minutes to determine that the existing routine wasn't using the indexes at all, meaning that the software was doing several sequential searches through much of the database for each inventory item. I rewrote about four lines of code, and the runtime for the report went from over 24 hours to under 30 seconds. The next day, I was told that the original software vendor had been "fired" and that I should plan on staying there for awhile.

The original vendor did something I've seen over and over: They sold the system based on senior, experienced and competent staff, and then once they had a signed contract, replaced the competent people with unqualified junior people who didn't know enough to, for example, check for proper index usage when a database query was running too slowly. They assumed that once they had the contract, they didn't have to worry about keeping the customer happy. In this case, they met a customer who wasn't willing to put up with that kind of abuse.

It was one of the more reasonable experience I've had in this career.

The Fat Part of the Bell Curve

[Spinlock_1977]

Given that, in the majority of cases, solution #1 will be no better than 10% better than solution #2, is paying 200% worth it? What guarantee do you have that the succeeding project (of a slightly differing nature) would be better executed by the team winning the first? Life is fraught with such complications, rendering generalizations of this sort moot.

Apple port to PowerPC did this

[maitas]

I remember reading an article at MacWorld Magazine about how they create two teams at Apple, one went to a complete rewrite of the MacOS to Power with no backwards compatibility (that was the primary team that the company bet tu succeed) and a second one that was the plan B. This plan B team was requested to write an emulator to reuse as much as possible of MacOS software.
  When finally the B team end his job the A team was call out to try to brake the B team implementation. They even tried using 360Kb 3.5inch floppies. But finally the B team won, and it was a good migration from 680x0 to PowerPC.
  Nice history, if someone can find an URL about this it is welcome.

CS degree

[wonkavader]

If they're in management, I think a CS degree (at least one less than 10 years old one) is often a detriment to a manager in corporate America. Managers should manage. The common desire for managers to be "Working managers" is a recipe for disaster. People do what they like and are good at. If you have a manager who's a good programmer, he'll program instead of doing what a manager should actually do, which is to constantly work to remove obstacles from the path of his or her team.

Furthermore, a CS degree can lead the manager to start making decisions that the team lead(s) should really be making, which is another recipe for waste, gotchas and unhappy workers.

I'm not saying a degree is a bad thing, but it shouldn't be a classical CS degree. The "lines of code" metric mentioned above is a good example of the problem. The manager needs to know about metrics that actually work. He or she needs to be able to judge software quality by speed, usefulness, buglessnes, user comfort, etc. These can be metrics. But most managers don't know (and aren't interested in knowing) how to measure them.

Borland tried this

[sproketboy]

Borland tried this and look where it got them. Almost all of their products were developed this way and it did allow them to come up with some great tools. Delphi and the original 2-way design tools (which came out the dBASE group surprisingly).

The downside is that it created a lot of animosity amongst team members making getting past that first milestone more difficult. Good developer would balk on working on the successful implementation and often quit.

No silver bullet here.

The greater cost

[CJmango]

Unfortunately, there's a lot more to that first milestone than sitting down to hash out some code. In just about any size business, a project will require the programmer to work with a multitude of other professionals around the company. Imagine you're one of those people and for every project you have to deal with two or more people not only for the initial briefings, but for ongoing support where they're likely to ask similar follow-up questions and require at least some maintenance. It's not so simple that you brief and follow-up with the programmers simultaneously either; doing so would misrepresent their skill sets and unfairly level the playing field, thus mitigating the initial intent to discover the best and brightest at that particular project. I imagine the cost in this paradigm actually exceeds the simple salary of the extra programmers, but also includes the time, energy and frustration of the other employees who must deal with the redundancy.

Your competition will do it if you don't.

[firewood]

If you don't hire that second team and have them compete internally, your competition might just hire those other programmers, compete with your company, and potentially take all your business away. There will be competition, whether from within or without. You choose.

Hope that first milestone is architecture & de

[presidenteloco]

- including user stories, storyboards etc. I sure wouldn't want to see any code other than technical risk-reduction / tech evaluation spikes included in the first milestone.

If you're talking about code-monkeys incapable of requirements & design specification, maybe it would have been more determinative of your project's success to have tested 3 architects / senior team leads against each other.

Great coders under lousy architect / project engineer will still fail, because their good ideas will be vetoed, and they'll be ordered to charge down the valley like the 600.

really demotivating

[TechBCEternity]

I've been in this situation where a manager tries to get you to do something by assigning someone else to do the same thing and let you compete.

I had been asking for additional developers and the ones I got were tasked with a competing design it completely demotivated me

Set Based design is something that could work. Where you have multiple teams working on different complexities of a component that don't compete but supercede each other.

Programmer Pyramid

[kai6novice]

I am a programmer. There are different skilled level of programmer. Let me break it down, then you can think of a way to identify them during interview. 1. Programmer who can solve simple problems. 2. Programmer who can solve hard problems. 3. Programmer who can solve very hard problems. 4. Programmer who can solve hard problems and recognize the root of the problem. 5. Programmer who acknowledge the root of the problem and brave enough to determine that the root problem must be solved. 6. Programmer who acknowledge the root of the problem, brave enough to determine that the root problem must be solved, and smart enough to know what the solution is. 7. Programmer who acknowledge the root of the problem, brave enough to determine that the root problem must be solved, smart enough to know what the solution is, and hard work enough to actually solve the problem for the good of the company. You just need to find a way to identify these different type of programmer.

Review Time...

[RivenAleem]

“So Paul let me see what you’ve done for the first milestone”

“Nothing Bill”

“Nothing?”

“Not a thing at all ”

*A crash is heard outside*

“Oh, I did reprogram the elevator to plummet 40 floors when the other two were in it.”

No, just look at microsoft

[Anonymous Coward]

It is just a "promotional driven developement" company now. They have 5 versions of windows mobile?

Nobody gives a fuck about the company's product anymore, we (I work there) just care about our promotions that are MANDATORY based on CSP's (Career Stage Profiles).

Do you want to end up with product code like that? I don't think so.

To many bad developers in the world.

[cfulton]

Yes, yes, yes. Most employers do understand what makes a good programmer. So, they often end up hiring the longest resume. If they had a little competition to see who's output was the most satisfactory a lot of bad developers would quickly become good or leave the market place.

If you can't build it, you can't manage it.

[agentultra]

This is the sort of solution I see proposed by business stakeholders who've been burned by out-sourcing or consulting.

I say, if you can't build it yourself then you shouldn't be directly involved in managing it. Too often I find that business stakeholders tend to stick their noses where it doesn't belong. Inolving themselves in this way does more harm than good.

Who wants to work longer hours, invest in more training, and constantly feel like you could lose your job?

Nobody. Not even the managers and CEOs. So why is it okay to think programmers would just love to work this way?

You're confusing GUI with "customer desires"

[jonaskoelker]

If you don't have the GUI design, how the hell do you even know what the bowels of the application should be doing!?

If you don't know what the bowels of the application should be doing, how do you design the GUI? How do you design a GUI if you don't know whether it's for a spreadsheet or a media player?

Well, I have one answer: "Customer focus groups say they want a call block list and a call forwarding feature."

An understanding of what your users want and what you're trying to help them achieve decides what features your application should have.

The desired feature set shapes the back end as well as the way the features are presented to the user for him or her to call upon.

Else, I think you get into nonsensical situations.

but the GUI is what drives the design of the backend!

Compare these two statements:

(1) Because modern computers are equipped with a control key and a Z key and our user interface designer created a menu item labeled "Undo" with C-z as the shortcut, our editor supports undo.

(2) When humans write things on a computer, they make mistakes from time to time, but the notice soon after. To help them correct their mistakes easily, our editor supports undo.

Which one sounds most sensible? In which one does the GUI design drive the feature set? In which one does the feature set drive the GUI design?

Let the design of UI drive the backend, not the other way around.

I think you're confusing "this program should support Undo" with "there should be a rectangle with the word 'Undo' in it". You're confusing things, processes and properties with their visual representation; probably as a reaction against someone confusing them with their implementation.

Good design chooses "Should support Undo" before "Edit/Undo and Control-Z" and also before "maintain a 'vector of state_t', containing all the previous states of the document".

(Oh, and by the way, if you write some code to find out what's possible, you might get good ideas as to what the user wants; you've probably experienced the "Hey, that's cool! I didn't even know I wanted that!". That's what I'm on about here.)

They aren't gonna come bitching to you about how your databases lack some index, but they might complain that your list of videos isn't dropping stop words like "The" or "A".

How is sort order a property of a GUI? Bonus question: same question, but assume the application in question was a command-line one; no curses, just argv and stdin to stdout. How is sort order not completely orthogonal to graphics and interaction?

Henry Ford

[Anonymous Coward]

Henry Ford did this in the development of the flathead V8. He had teams, which he micro-managed to death, and put strange engineering requirements on each team. One team was supposed to design the water cooled engine that used no water pump, another without an oil pump, etc. Ford apparently had an aversion to pumping fluids. He also isolated the teams to make sure no ideas could be shared. This necessitated completely separate shops with all of their own machinery. The teams didn't know of each other's existence until later on. If you are willing to work for one of the many 'idea guys' out there, make sure they are really smart, not just bipolar psychopaths. If they have a long string of failures, they're probably not going to tell you about them.

Competition kills collaboration.

[calebhoward]

Yeah... I worked for a company who handled employment this way. It may have made for better individual skills (Though this was by no means clear), but it *killed* any team skills because it reduced collaboration to competition. It was perhaps one tenth as effective in terms of overall productivity when compared to the next worst team I ever have worked on.

an analogy RE an organization's role in your life:

[vaporland]

...the speaker made an analogy regarding an individual's role in the organization. He asked them to think of putting their hand in a bucket of water, and then withdrawing it, then asked "how fast does the water replace your hand when you take it out?" Instantly. "That's how quickly you can be replaced."

"Think of your boss putting his fist up your rectum.

How fast does your colon replace it with shit once they take it out? Instantly - that's how much I'll miss your crappy job.

Oh, and remember to wash your hands before returning to work . . ."

Please accept my apologies if that is a little graphic, but it is important to consider both points of view.

As Charles de Gaulle said, “The cemeteries of the world are full of indispensable men.” Most of those were HR managers.