Hacker News new | past | comments | ask | show | jobs | submit login
Rent-a-coder hilarity (2008) (willbenton.com)
140 points by cramforce on May 6, 2013 | hide | past | favorite | 131 comments

Actually one of my colleagues had the opposite (yet in my opinion equally hilarious) problem with rent-a-coder - the code was much better than he wanted.

He wanted sample vulnerable Java code to use for secure development training. None of us enjoyed writing Java web apps, so this seemed like a cunning plan to get sample (yet custom) code with minimal effort. Hopefully, full of bugs.

He asked for a "task tracker" (IIRC, might have been phone book), and specified Java with "no framework" as the implementation language. He chose the dodgiest bidder he could who looked like they might finish the job. I think he put a few gotchas in the specifications.

Actually, as delivered, the app was solid, and based on JSF2 ;)

What I learned about rent-a-coder:

* There are corporate refugees who do this on the side to make extra money.

* CRUD apps appear to be a sweet spot for rent-a-codering.

* Code quality is hit-and-miss if you're looking for disasters ;)

That's funny, how come this person was the dodgiest bid of all?

Well, maybe he should have specified he wanted an insecure application (or an "extra secure" application - expected result is having several layers of snake oil and "proprietary solutions" applied)

Bidding was decided based on communication style, low bid, low GDP country and "has feedback on just 1 or 2 projects" (minimal, but not extensive history of delivering).

Didn't ask for "extra buggy" or "extra secure" because the ideal was the combination of honest mistakes and laziness that turn up in real code all time. I like the idea though ;)

I mean, you'd think that for $100 or whatever all up, they would have half-assed it a bit ;)

Probably the mistake was to stop at n=2 and not choosing a harder problem domain.

The mistake was for your friend to think that he was a good judge of ability based on the features at hand. It might be useful to reflect on whether the people your friend normally prefers to hire might just be the people who are best at managing presentation?

I would expect a terrible bid from a high GDP country to be a better source of bugs than a terrible bid from a low GDP country.

Poor communication? Probably just ESL. Low bid? In a low GDP country that low bid goes a longer way.

If you grabbed an american with the same conditions you're more likely to get some illiterate kid instead of some Czech doctor moonlighting.

I love a good anti-anecdote (antidote?) ;) Here's one potential problem with the selection criteria: "low bid, low GDP country". I might have been better to weight the bid with the GDP (I don't mean really crunch the numbers, just put your thumb on the scale).

But more to the point, if your friend didn't have a lot of experience with this sort of thing, he probably wasn't that good at picking a bad apple. Or he just got unlucky, maybe.

I suspect "has feedback on just 1 or 2 projects" might also indicate the opposite: That the guy is picky, waiting around for a project he can actually deliver quality on, and perhaps optimising for second (off-site) follow ups.

I don't know about all the rest of you, but I find it really depressing to read these rent-a-coder sites.

The first thing that strikes me is that people posting projects don't really understand the value of software engineering. They want someone to do crazy ambitious projects for pretty much no money. As if to say, "I have this idea which is really awesome and valuable, now I just need some monkey to do all the work." $500 should be enough for that, right? Then I'll cash in on my awesome idea...

Maybe some projects honestly work out like that. But a lot of the projects I see on these sites fall outside that scope. For big ambitious projects, we all know programmers are not fungible resources, and competent execution matters.

But the worst part is that people humor these projects, or more likely take advantage of the gullibility of the people asking for them... "Yes sir, I can solve that impossible problem promptly and under your budget of $500." It's really sad.

It's easy enough for us to say that people don't appreciate the value of what we do but really market value is set by supply and demand.

Not everyone lives in San Francisco or New York where they feel they must bill $100 p/h just to make rent. A smart person in an emerging economy where $500 per month puts them on a higher part of the local income curve could certainly realize that they can compete in a global marketplace on price. This does not necessarily make them incompetent, in fact it's not a bad way to "hack" oneself out of poverty.

Besides, many software applications are alternatives to excel spreadsheets or to handwritten HTML websites and don't necessarily require the hippest programmers who are well studied on the latest technologies. A customized rails scaffold can go a long way to solve a lot of real business problems, and doesn't HN often talk about the value of producing an "MVP"?

There's truth in the idea that a first world salary might go further elsewhere in the world, and that lots of people get by on less ... But I suggest you look at getacoder.com et al. and see what I was really talking about, because it can't be explained only that way with no other explanation. I once saw a project similar to something that took a former employer 10 years to iterate on and finally get right, with a long tail of bug fixes and crazy corner cases because it is a difficult problem. The rentacoder "cost" was 2 weeks and less than $1000. I did not follow up with that particular guy's project but I'm going to guess that they did not have success with those expectations and that budget.

Its interesting that those sites are flooded with "create" but never "update". Version 0.00001 of "a copy of ebay with facebook integration" (true example from getacoder) will only cost $5K... What is the site for "OMG we need version 0.00002"? Oh we already have those, they are the established $500/hr contracting sites.

There's a Hollywood movie trope rolled out every 2.8433 years where a rich guy goes back to university and tries to buy his way past projects and tests. I always kind of imagine some rich kid in "Web Programing 317 section 7" contracting out his final project. Now that tuition is so expensive, $5K for a final project sounds more or less reasonable for a kid who just wants the credential and not the education/training. There should be some kind of ethical filter where if you're obviously trying to contract for a stereotypical final project around the end of the school year...

Once I was looking through rent-a-coder and the pdf spec attached was a homework assignment with the class and professor's name on it. Emailed it to the prof as my good deed for the day.

I once read of a prof that was on a rent-a-coder site, did a student's assignment, and then failed him.

I guess most of the people posting these one-off coding jobs on bidding sites are probably too flaky to ever need a version 0.00002, they will abandon the business as soon as they realize they aren't getting any hits.

Interesting that you're mentioning the "outsourcing" of academic projects.

While this seemingly has been "popular" in Europe for PhDs / doctoral theses for quite some time (in Germany e.g. some ministers recently lost their posts for that or similar activities), it has become an even larger issue in countries like India across all levels of academic studies - see https://news.ycombinator.com/item?id=4610739 for more info on that.

For many Indians, a degree is just a path to a cushy job. That is probably true for many other parts of the world too.

Rentacoder used to have a disclaimer (they may still, I haven't looked in years) that the site could not be used for any thesis or "final senior project"-type project that would determine whether or not someone received a degree.

I always found that oddly specific - they clearly acknowledge that people will use the site to pay someone to do class projects, and get better grades by doing so, and they very much don't care so long as it doesn't determine whether the buyer graduates.

Well it's possible that in many cases 0.2 is created by the same person as 0.1.

This is caused by the fact that the online markets for freelance coding are open to anyone. Since anyone can post, naturally you will see a lot of impossible jobs.

Since anyone can bid, naturally you'll see bids on these impossible jobs, too.

But, underneath this superficial layer of incompetence lies a good selection of developers and clients in each of the freelance sites. Having done some work on more than one of them, I can say that as a developer, the key to finding actual work is to take the tests, have a portfolio, and wait for clients to contact you. If you must bid on the jobs by searching, search hard for the realistic ones and bid appropriately. The clients that understand their work will not usually go for the lowest bidder just because. They'll go for the one they have the most confidence in.

this is where github helps. or stack overflow.

There was an article in the NYT recently about companies exploiting underpaid interns in non-software engineering fields. One of the sentences said that the dream employee the companies were looking for were "Triple 22s" - 22 year olds willing to work 22 hours a day for $22k. So its not just software engineering.

anyone doing rent a coder should follow some oldie but goodie advice:

create a few small tasks to get started. rent out a few coders for a week. make all of them code the given tasks. pick the best quality and continue.

you will get good quality out bad, whatever you prefer... And waste little money.

the only flaw is if all the coders who are participating are not the quality you wanted.

And then you become the PM and integrator too? That overhead will start to stack up. Don't forget Brook's Law.

Sounds to me more like "throw away most of the initial work, keep 1-3 people that do the best work"

For every Facebook-clone-for-200 dollars there's someone (several, actually) trying to solve some basic business problem or wanting to test out a product idea.

And willing to pay bottom dollar to do it, even if it means terrible results

I've heard mixed reviews, it would be interesting to see some comprehensive comparison.

Rates are going to be driven by cost of living as much as expertise, so it's not unfeasible to imagine skilled developers in Malaysia / China / Russia / India who didn't get a green card (or didn't want one) being able to comfortably sell their services for < $10 per hour.

Sure, and for every ten or so of them, there's someone more reasonable. ;) I'm not sure what the next babushka doll is, but my point is that the jobs are not completely uniform and that within the variation lies _some_ value.

for an mvp? hell yaah.

tbh, there should be a price picker. you specify a timeline. you specify quality, and then price is calculated for you.

this communicates that your want mvp, or real development. And for each the site can provide heuristics. that's where the site's secret sauce can come from.

I'd like to see that "Bug per 1K LoC" drop down list. There could even be an ISO rating and you could fail coders for not meeting their minimum bug counts. As a dev I could just skip over problems as long as I was on target for my bug count.


Well. Listen, you get what you pay for.

However I think BUG count is not the issue. It's code quality. What if I told you:

"I need a POS implementation of Foo, it doesn't have to be maintainable but has to work with a taaaaad bit of ability to patch it up. I am trying to prove a concept is viable and show it off to like 50 people. I will rewrite this code if I decide to implement the concept. Also I want this done in ~ 1 week"

Should that not drive down the price and time required?

That means probably minimal tests, minimal abstractions, lots of copy-pasta, but still within decent coding guidelines and meets the needs

The part of reading rent-a-coder that always depresses me is the rampant contract cheating. It makes me wish that by facilitating that activity and taking a piece of the action, sites like rent-a-coder incurred civil liability to the colleges and universities whose assignments are being bartered.

I'm not quite sure how to work that - maybe sue them as some sort of accessory to fraud, though that would probably first require the university charging cheating students with fraud.

Well, university assignments are at least doable. For an experienced developer easily so, which makes them quite profitable. The profit goes down the drain if you need to explain to the student how your code works (if he knew, he wouldn't want you to code it for him).

if you see a fun project but underfunded, send out a note saying your hourly rate, approximations, and offer to review deliverables on a weekly basis.

most people don't understand the costs and what you get for $100...

If you click through to the screendump of the bids there are some pretty obscure jokes besides the obvious KurtG and GeorgeCantor. BusyBeaver is another computability joke, solving "in the most productive manner possible". chn's bid is in infinite-radix numbers. The HaltLib.NET library is claimed to work in PNG and BNF among other languages. J. S. Carberry is a mythical Brown professor started as a practical joke in 1929; the backstory is interesting: http://students.brown.edu/College_Hill_Independent/?p=2127

I liked this reaction, from KurtG:

Dear Mr T.,

Your problem is very much like I have been considering. Assume that we have a consistent and complete axiomatization of all true first-order logic statements about natural numbers. Then we can build an algorithm that enumerates all these statements. This means that there is an algorithm N(n) that, given a natural number n, computes a true first-order logic statement about natural numbers such that, for all the true statements, there is at least one n such that N(n) yields that statement. Now suppose we want to decide if the algorithm with representation a halts on input i. We know that this statement can be expressed with a first-order logic statement, say H(a, i). Since the axiomatization is complete it follows that either there is an n such that N(n) = H(a, i) or there is an n' such that N(n') = ¬ H(a, i). So if we iterate over all n until we either find H(a, i) or its negation, we will always halt. This means that this gives us an algorithm to decide the halting problem. Since we know that there cannot be such an algorithm, it follows that the assumption that there is a consistent and complete axiomatization of all true first-order logic statements about natural numbers must be false. There is no way your application can be built, and for this advice I am willing to waive any fee. Sincerely, K. Gödel.

"But the other guy says he can build this in Java in 50 days, I think you're not as smart as he is"

The boss is always right

Although anyone worth their salt should recognize the halting problem, I'll point out that the vast majority of programs can be proven to terminate or not, and although testing for halting in particular isn't especially useful for real-life programs, it could be used as a benchmark for a more general theorem-proving tool of the sort that would be very useful for avoiding bugs.

Of course, a tool that could automatically prove useful properties about programs with no guidance, which would be significantly superior than all existing practical program analysis tools which require quite a lot of guidance, might be beyond the capabilities of the people that post bids for $300. Unless it used Mechanical Turk. :)

There exist research programming languages that support 'total functions', that can be proven to always halt. Usually you divide the world into functions and cofunctions, and data and codata, the latter of which may be infinite (such as I/O).

I wish this were a more popular thing. When I write a function, I can probably enumerate in my head all the things I want it to do, and not halting usually isn't one of those things. But the instinctive reaction is to worry about Turing-completeness, which is puzzling. When's the last time you wanted a program with fundementally unprovable behavior?

Programming with such functions is called total functional programming. Here's a nice little introduction to the subject[1], and if you're a fan of code and math you should probably check out the other blog entries as well.

[1]: http://blog.sigfpe.com/2007/07/data-and-codata.html

When's the last time you wanted a program with fundementally unprovable behavior?

I'm working on one today. I'm analyzing a data set for tens of millions of possible statistical anomalies, and I'm putting my "investigate further" threshold to statistically one in billions. Each thing added increases the size of the search space.

Knowing that it is extremely unlikely to run forever really is good enough. Proving that it won't is a non-issue for me. (Right now it takes several hours to run.)

> When I write a function, I can probably enumerate in my head all the things I want it to do, and not halting usually isn't one of those things. But the instinctive reaction is to worry about Turing-completeness, which is puzzling. When's the last time you wanted a program with fundementally unprovable behavior?

You don't usually want fundamentally unprovable behavior. However, you also don't want to sacrifice the ability to compute anything that is computable. And you can't throw out the bathwater of the halting problem without throwing out the baby of computing everything computable.

So, in practice, you want to use provably-halting-on-all-valid-inputs algorithms for the problems where you have available (either known, or that you can find with reasonable effort) such an algorithm, but retain the option of using other techniques for other problems.


> Although anyone worth their salt should recognize the halting problem

Bah humbug. You can be a totally competent engineer and not immediately recognise the halting problem, just like you can be a totally competent auto-mechanical engineer and not recognise a oxidation-reduction reaction.

You can solve high-value real business problems every day for the rest of your life and never encounter a single decision that will be meaningfully informed by knowing about the halting problem.

Computer science != software engineering.

> You can solve high-value real business problems every day for the rest of your life and never encounter a single decision that will be meaningfully informed by knowing about the halting problem.

I dunno; I find that plenty of times dealing with fairly pedestrian business-problem requests its not uncommon to run into something that is desired that is equivalent to solving the halting problem; recognizing the difference between problems that are merely difficult and potentially expensive and risky investments of time and ones that are knowably impossible is pretty useful in terms of choosing where to allocate time and effort.

> Computer science != software engineering.

True, but software engineering depends on computer science, and, as in any form of engineering, understanding the well-known outer theoretical limits of what can be done is pretty important to engineering.

A good software engineer will know that there are limits to his capabilities, so my point is that in practice it's useless to differentiate between "merely difficult and potentially expensive and risky investments of time" and "knowably impossible", because, with the resources at hand, the former will, in fact, be impossible.

> True, but software engineering depends on computer science, and, as in any form of engineering, understanding the well-known outer theoretical limits of what can be done is pretty important to engineering.

I disagree - you can get by very well by understanding the inner, practical limits. Again, just like an auto-mechanical engineer: He doesn't need to understand the details of combustion or the process of refining oil, just enough to understand it works in the context of his domain: engineering cars. On the other hand, he also needs to know a little about suspension (but not the calculus of the harmonic oscillator) and enough metallurgy to weld the chassis safely.

And don't get me started on computer scientists that can't code.

> A good software engineer will know that there are limits to his capabilities, so my point is that in practice it's useless to differentiate between "merely difficult and potentially expensive and risky investments of time" and "knowably impossible", because, with the resources at hand, the former will, in fact, be impossible.

In practice, many of the most useful things to invest time and energy in are difficult, potentially expensive, and risky (often, because of the risk, you want to dual track this with a less-risky, lower-payoff approach) things that have high payoffs if successful.

OTOH, the knowably impossible things are dead ends. So, no, they aren't the same thing in practice.

Frankly, I think this shows that the "jokers" don't know what they're talking about either. Yes, the problem is undecidable in general, but one could certainly develop an interesting program that solves the problem sometimes, and can definitively report when it cannot decide the problem [in a given number of steps, for some value of "step"]. The halting problem is not some black hole such that when you dare venture into it, your program will be lost never to "return;".

In fact, come to think of it, for any program which 1) uses a bounded amount of memory and 2) has a bounded input (taking "input" as broadly as possible), the halting problem is always decidable in 2^[bits of state] "steps". There are a lot of programs which satisfy (1) so long as (2) is satisfied, and if (2) is not satisfied then the halting problem is not an interesting problem at all.

The approach would be to fix an upper bound on memory and to enumerate all possible state, running the program each time and determining if all cases terminate or if any runs forever?

I think the real crux of the problem is that you can't determine in any of those cases whether the program is going to terminate. Consider bogosort or a brute-force algorithm for solving travelling salesman. These can take millions of years to complete even for small input sizes. Do we consider that an "infinite" runtime?

No, the algorithm is to run the program and see if any state is repeated; if it is, the program is in an infinite loop (where "state" means, roughly, all memory and remaining length of input). Of course, this requires 2^[bits of state] bits of memory, and a similar amount of time. Obviously an interesting (read: approximate) solver would use tighter heuristics.

Consider bogosort

That's true, external inputs and true randomness is not accounted for. (However pseudorandom generators are included!)

You can also bound time. For a web site / web app, end users aren't going to wait around for 5 days after they click a link... merely spawn your "Halting Problem Tester" and if it doesn't terminate in 10 seconds or whatever your metric is, lie and call it an infinite loop. Yes this is an epic fail from a computer science perspective but its perfectly adequate from an engineering perspective.

Or don't lie and explain to what degree of certainty it is an infinite loop...

This is a special case of the notion that questions about a given computational model can be solved using a more general computational model. See regular expression syntax validation as a context-free grammar, and related notions.

But even if your program only uses 5 MB of RAM, that's still 2^(5,242,880) or about 1.4x10^1,578,264 steps you have to check.


One bit of state (true/false) means we have to run for 2^1=2 "steps". Since the program does not halt after 2 steps, we have proved that the program will never halt. Easy, huh?

So? This can be easily detected by comparing snapshots of memory, including any registers, etc.

We had exactly the same frustrations with online outsourcing (being on both sides of the table), and now we have built https://codeable.io (focused only on WordPress for the time being) - 4 months after launch, we have more than 900 jobs posted, half of them completed, excellent reviews, more than $45k in revenue.

I'm very proud of what we achieved so far, because we eliminated the biggest "pains" of online outsourcing; There is no bidding, our (invited and reviewed) contractors form a single estimate which is then presented to the client. And we focus on sub-$500 tasks, because the margin for error is significantly smaller, so if a client comes in with a huge job, we help him break it down into smaller pieces. We also maintain client/contractor ratio, so there is no need for contractors to compete with one another, anyone who wants to work, can work.

> so there is no need for contractors to compete with one another

Why would buyers desire this?

One benefit may be that contractors won't be in a race to the bottom, so they won't feel like they should half-ass it.

On one of the other websites, they seem to want to install a spyware on your computer so the employers can see what you are doing at any given moment. I doubt a great coder would put up with that (I'm merely good and I wouldn't) and the odds of finding one there are lower. On the other hand, I think a great coder would be more likely to freelance on a site that has consistent work which they don't need to fight over.

So that's my speculation.

> One benefit may be that contractors won't be in a race to the bottom

It's obviously of benefit to the contractors, I meant the other side of the transaction.

I explained it further, if you had bothered to read the rest of the comment; that sort of thing may attract higher-quality developers.

Your speculation explains it perfectly!

Because first and foremost, we want to keep contractors happy. If they are paid well (by well I don't mean ripping clients off), they will come back and perform more work. Our long-term goal is to establish a trusted network of developers that always go that extra mile to satisfy clients - I must admit, so far, this approach has paid off in dividends. We're currently re-designing the landing page, and we will put client testimonials on that prove it.

> and we will put client testimonials on that prove it.

I'll be curious to see which client gives you a testimonial that thinks non-competing contractors is a great idea.

Each and every, in fact. Because they don't come to us to see how (or not) our system works but to get their problems fixed in time, and by a top quality expert. (I'm saying this because we do a lot of research on both sides, and transparency is part of our business, so all involved know how the system works)

> Because they don't come to us to see how (or not) our system works but to get their problems fixed in time, and by a top quality expert.

I notice the word "price" is not present in that testimonial.

Do you think that darwinian fight of everyone with everyone else is the best possible way to finding cost-effective solutions?

No need to waste a week weeding through bids, when the whole job could be done by then.

Outsourcing is supposed to save you time, bidding wastes your valuable time.

> bidding wastes your valuable time.

Why does it waste more of my time in this bidding process than any other aspect of the marketplace? It's how you minimize costs, and any smart seller that realizes you're not going through the bidding process jacks up the price to milk you for all you're worth.

Bidding is the best way to get rid of the best contractors, because most of them won't want to invest significant time to compete with others for the jobs, so what you're left with are the most desperate or mediocre ones. And even those will realize in long-term that it's just not worth their time or either leave or perform poorly.

So in my experience, bidding doesn't do any good, to either party.

> It's how you minimize costs, and any smart seller that realizes you're not going through the bidding process jacks up the price to milk you for all you're worth.

Honestly, I rarely get more than one or two bids when I'm looking for someone to work for me. I've been around long enough to have built relationships with vendors for various tasks. I know about how much I expect something to cost and if the bid comes in significantly higher or lower then the vendor and I talk it over and negotiate either a lower price or a changed scope. They don't jack up the price because the cost to acquire customers is very high. I'm guessing I saved 100 hours last year by not putting every last task out for bid.

What's funny is that math people know this is impossible and will never attempt it, but it's quite easy to write something practically useful that does the job most of the way. It's possible for static analysis tools to identify many loops that will never end. E.g. in Java if there's no break or return and the guard is a boolean that is never written to and no runtime class loading is used.

It can be very valuable to have static analysis tools in an organization, I know my own company has them, and we don't share them. IBM as well puts tons of work into it. Motorola has shared one of their tools. Every bug and issue your tool can find is one much more cheaply solved.

Similarly, the client may be doing coding education, or interview, or other software where just a few limited lines and limited operations need to be checked, or it is OK to say if you hit n^4 loops you lose, etc..

John Carmack also has a lot of praise for static analysis: http://www.altdevblogaday.com/2011/12/24/static-code-analysi...

Here's another asking to solve P vs NP. Hilarity ensues:


The overlooked bid in this case was by Vinay Deolalikar for $1000000 who simply said "I think I have done this." For background, Vinay was a researcher at HP Labs, Palo Alto who made a serious attempt at solving the problem (independently from this bid :P).

Ok, so lots of people bid on projects without fully understanding the requirements, some people understand but want to solve it as an engineering rather than a math problem, and others get it. Where's the hilarity in this or OP? HN Sunday night, aiyiyi...

It's the cautionary tale that you cannot believe the words coming out of a salesman's mouth.

I used to work in a startup where the cubicals had sequential phone numbers. From time to time I'd get a call from one of the sales reps in the field.

"I'm talking to a customer," the rep would say, "Can our product do X?" Where 'X' was something like, oh I don't know, 'Computational Sushi' or 'License plate recognition,' or anything unrelated to what our real-time messaging middleware did.

"No," I would tell them (but using more words).

Then I would move to the next cube and instruct the engineer sitting there that the phone was about to ring, and that they should pick it up, listen and say "No" quite firmly. Repeat for the remaining cubicals.

Salesmen will say anything to make a sale. It's what they _do_.

We used to have customers who would do that. They'd call every number in the company until they found someone who'd say "That sounds do-able." Upon which they'd demand a price reduction because "Your product doesn't do what you said it does."

I like the guy who guarantees the solution will be "100 % W3C compliant"

Hmm, the last time I commented on HN on this rent-a-coder hilarity, someone proposed "writing a new scripting language" within a week. I suggested that this was actually doable within a week. One could just concoct some simple language with curly braces that maps 1-to-1 with a procedural subset of Python, then output Python to run it.

The result? I was downvoted by some less than informed individuals who thought there was some deep fundamental difference between curly braces languages and whitespace significant ones. What The!?... On HN!? This was before Coffeescript was a widely known thing as it is today. Think what you'd like about Zed Shaw, but his "DB Invasion" idea has some merit.

Heh. JavaScript was famously invented in a week.

client: I need a software tht can find information about my mp3 files online and it must work 100% correct

me: What information do you have and what do you want to look up?

client: I have the folder and file names and there are 5 webpages like google where you can search for music. I want the programm to get the right song info from this. BUT IT MUST WORK 100% right no error ever! I had 6 other programmers try it but no one can make it right!

(the real clients english was even worse)

Writing a program to determine if another program will complete, error, or run indefinitely is quite doable given reasonable constraints: Run the program!

One need only specify some reasonable length either equivalent to infinity for such a program, use a heuristic of checking whether the program is in the same loop and if so, whether any of the variables involved in determining loop termination are changing. Of course, proper security precautions are required.

For a certain subset of problems, it is possible to do this.

For any finite number of clock cycles N, in a Turing-complete language, I can write you a program which terminates but takes longer than N cycles. There is therefore no value of N which will consistently give the correct results in your program.

Turing machines have an infinite tape, so under a Turing machine model, there are infinitely many loop termination conditions, and so it is possible to craft a program which never repeats the same state within N cycles for any N but still terminates.

If your machine is finite state (with no inputs) and s possible states, rather than a Turing machine, you can check if the program halts:

  halts s program initialState = do
     seenState <- newBooleanArrayOfSize s
     setBooleanEntry seenState initialState
     halts' initialState
     halts' state0 =
      if state0 == HaltingState
        then return True
            seenAlready <- getBooleanEntry seenState state0
            if seenAlready
              then return False
                state1 <- nextState program state0
                setBooleanEntry seenState state1
                halts' state1
In practice, s might be very large (even a 64 bit integer in the state will contribute 2^64 to s) so this algorithm isn't necessarily usable in practice, but it does complete in finite time.

It also says it must take "the source code", so that means you would have to be able to build any arbitrary program from source? That would be a huge pain in the ass in general, above and beyond actually doing the things you mention.

You forgot about the butterfly. Even if it looks like nothing could change, something could due to a bit flipping in memory, which would allow the program to halt.

Right. Any statement that the program is in an infinite loop will usually be subject to error.

Of course, the real question anyone asked to develop such a program would be what runtime is equivalent to an infinite loop. Any real-world program must have a runtime bound that is predictable on invocation or it's useless.

Isn't the joke on the guy posting the (impossible) job?

I see some have commented on the economic desperation or the salesman attitude of the coders bidding for this impossible job, but when someone asks a large population of salesmen that they have a serious intention to procure a bridge ... well ... there will be a few who'd definitely show up wanting to sell one.

Don't see the point of this whole thing really.

> Isn't the joke on the guy posting the (impossible) job?

No, considering the poster's name is "AlanT"!

Dear Sir,

I kindly propose a two-phase project based on Test-Driven Development methodology, of which we are expert.

1. Specify and develop test harness.

2. Develop program that satisfy tests.

(1) is actually perfectly doable w.r.t. to this project, so I must be missing your point.

Any set of tests that fully exercised the desired functionality would be infinite.

Any finite approximation would modify the task from an impossibly infinite one to something possible.

Note that for a huge amount of software functionality, the amount of tests required to "exercise full functionality" is infinite, and very rarely can we mathematically prove that a finite set suffices. When code is multi-threaded, for instance, this tends to happen a lot.


But I stand by adaption of the old sales technique "What does ____ mean to YOU? ... Oh, that won't be a problem."

The part of rent-a-coder that bothers me is I'm sure it goes like this more than we'd like:

- Party A contracts with Party B on a big software contract. - Party B sub-contracts on some of it to Party C, D, & E. - Party E is a bit dodgy and does a bunch of rent-a-coder. - Hey it compiles! It gets passed up the line. - Party B is late and just passes it on. - Party A is late and, "Hey, it works!" and delivers. - Hilarity does not ensue.

My personal experience with this kind of thing is that the further away from the actual concerned party you are (in other words, the people who are going to use the software), the more likely it is that the software is going to be wrong.

That looks like another 'FizzBuzz' filter to me, just more elaborate - in this case, KurtG appears to be the one to pass the screen, right?

I am SO tempted now to add this to our standard interviewing questions list. At least for anyone claiming a CS education.

Why? This is a miscommunication issue, not a CS issue. Determining whether or not something runs "infinitely" is typically just, "Does it run longer than an acceptable amount of time?" It may not actually run infinitely, but it may run practically infinitely (which is to say, just very long).

You have people responding that are assuming that they're going to test if a process takes too long and bail if it does. Pretty simple, actually, since for all practical purposes, when somebody describes a program as "taking forever," they rarely mean "forever" literally.

If you want to ask it, go ahead, but understanding practical limitations and engineering to those is a perfectly acceptable answer for the context of the rent-a-coder site (and an interview for a coding job). The only time it's not is if you're interviewing for some sort of academic position.

So, what's best current practice for naive clients when trying to hire designers or programmers?

Is that advice online anywhere?

To me, the disappointing thing about this spoof is that it treats the engineers on this platform like "code monkies."

One of the biggest gripes from top tier engineers is that they hate being treated like animals by jerky business guys, and here we have a group of people mocking these engineers and the platform. It all seems disrespectful to me.

describe 'My experience, -> _.map ['amazing','awful'], (quality) -> _.map ['engineers','business guys'], (role) -> _.map ['Brooklyn','online platforms'], (place) -> assert "There are #{quality} #{role} in #{place}."

What would happen if you went through with it? I bet it wouldn't be too hard to write a program that does it for 90% of cases. Is there a simple case that would be impossible to determine?

Yes, there is a small program, for which you could be one of the most famous mathematicians if you could tell whether it terminates or not:

i = 4; while(there exists such p and q that prime(p) and prime(q) and p+q == i)) i+=2;

keyword: Goldbach conjecture. The Goldbach conjecture states that this program will never halt. No one could prove this yet; seems to be really hard.

I find your code hilarious in that, if it ever terminates, it doesn't print the two primes.

A true mathematician; nadam only cares that a solution exists.

But if you were to code out such a program it would have to still have an upper bound for the size of the numbers you are testing. My implementation would look like this:

  int i = 4;
  bool sumFound = true;
    sumFound = false;
    for(int p = 0; p < MAX_INT && !sumFound; p++)
      if (isPrime(p))
        for (int q = 0; q < MAX_INT && !sumFound; q++)
          if (isPrime(q))
            if (p + q == i)
              i += 2;
              sumFound = true;
You could use big integers, but it'd still be bound by whatever the max size is for that. This program would eventually terminate. Could you write an implementation where the limitations of the system don't get in the way of the theoretical mathematical limitation? I guess you could build some system which can accommodate arbitrarily large numbers, but even that would be limited by the computer specs.

I guess what I'm saying is, isn't the implementation of the program the test in itself?

The program must run on the Turing machine. The Turing machine has an infinite tape, so it is able to represent arbitraily large numbers on its tape. It is a different question that a real Turing machine cannot be built in the known physical universe which contains only a finite number of atoms.

Since you don't have a real Turing machine, why would you care? Your computer is not Turing machine.

That program doesn't run forever, you didn't declare that there what had to exist for the (just there exist) and prime isn't declared (is prime? highest prime which is a factor in the argument?).

The Goldbach conjecture is this:

"Every even integer greater than 2 can be expressed as the sum of two primes."

My program is simply constructed in such a way that it terminates if and only if the Goldbach conjecture is not true. Maybe my pseudocode is not very precise (and also english is not my mother language), but given the Goldbach conjecture anyone can construct the program more precisely if needed.

Off the top of my head:

1) Assuming rand(x,y) gives a uniform distribution between x and y:

    for (int a = 0; a < INT_MAX; a += rand(-1,1));
2) I can't find the source any more, but someone basically implemented a big int library with bit twiddling to allow for an upper bound on a loop that would finish after the heat-death of the universe, assuming generous CPU specs. Not infinite, but also non-terminating.

3) Anything that makes a system call. You might never get scheduled again!

As to 1) any rand() implementation that doesn't use an external source of randomness is deterministic and cyclical, thus it is quite possible to determine if 1) halts by analyzing rand()

#2 isn't any more non-terminating than "for (i=0; i < 100; i++)" is.

A simple example that is hard to determine if it halts is to iterate through a,b,c,n and see if a^n+b^n=c^n. I.e. solve Fermat's last theorem by brute force. (I won't spell out the iteration details.) If your software could determine if this halts or not, it would prove Fermat's last theorem. (Obviously since FLT has been proven, this particular case is known not to halt.)

Interesting read:

"The proof itself is over 100 pages long and consumed seven yearsof Wiles's research time. For solving Fermat's Last Theorem, he was knighted, and received other honors."


There is a paper online that proves fermat's last theorem in this way, by exploiting the C compiler's ability to optimize away non-terminating code that has no observable state changes.

Oh, the halting problem is easy enough to solve for most cases (people do it informally all the time), just not for the worst cases.

For giving a percentage, you need to specify a distribution of programmes first. E.g. programmes created reading from /dev/random, or programmes downloaded at random from the internet, or something more sensible.

Exactly. The first reason to reply to this kind of request would be to engage with the uneducated client, and make sure that she will pay for that 90%.

It looks like a recruiter, but the other way around :)

I don't think it's all that hilarious to waste people's time, especially when the goal is to point out the naïveté of others.

How come that there's a new getacoder project that invites all those users who gave those fabulous comments?


Unfortunately, the situation has only gotten worse in 2013

I have an uncle who is a deposed King of Nigeria who will solve this problem for you for a small deposit and your bank account information. :-)

Is it money up front or c.o.d on those sites? Trying to get my head around why people bid without having a clue what`s entailed

I believe that if the developer's bid is accepted, the money goes into the 'escrow', which is the main purpose of the site: make sure that the developer does not go unpaid if he did the work.

If the customer is not happy, there are some sorts of resolution processes that I don't know much about.

What surprises me is that the clueless developers also had high 'reputation' (positive customer feedback), which should be at least some indication about their competence.

They do not really read what the customers want until the bid is accepted.

    foreach(newProject as project){
        new Bid( projeckt.averagePrice * 0.8 ), "We are the best nd have done this many times");
In the most cases they can really solve the problems and get good ratings.

Some clients include a "password" in the project description and ignore all messages without the password.

Project Creator: AlanT


what if that program finds bugs in itself? wheres your god now?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact