Test Driven Development – How Stupidity Spreads

I went on an interview at another flaky startup. When a startup is in one of those “shared office space incubators”, that’s a red flag. Allegedly, the NYC government is wasting taxpayer money financing startups, which means it goes to people with political connections but not good ideas nor the ability to execute.

The head programmer said something hilarious. He said “We have to implement a lot of automated unit tests and test driven development.” I replied “That’s premature optimization. At this stage, all your resources should be invested in developing version 1.0 of your product. You only have 20 users. Wait until you are bigger, before introducing automated testing. I’d only introduce automated tests for problems that actually arise. Test driven development is a waste of resources, especially for an early-stage startup.”

He replied “Most VCs ask for test-driven development. They won’t invest if we aren’t using it.”

That explains why stupid ideas proliferate. If your startup is hype-compliant, you get an investment. Otherwise, you don’t get funded.

I said “Only someone computer illiterate would demand an early-stage startup invest a lot in automated testing.” He replied “Some former engineers are advising the VCs. Therefore, they are correct.”

It’s pretty obvious what happens. If you’re a good programmer, you’ll probably stick with writing software. If I had successfully cashed out big $ from a startup, I’d bootstrap another business while using the money to pay my living expenses.  If you’re a lousy programmer, but good at promoting yourself, then you switch to being a VC adviser. If you have high emotional intelligence and low logical intelligence, you evaluate based on hype rather than technical merit.

A successful startup will have some great programmers and some great liars. The great liars will leverage their one success into lucrative jobs as advisers. As overpaid technical advisers, they will never have to produce working code and get discovered as a fraud.

The founder said “Most VCs ask ‘How are you going to scale your product?’” Again, that’s premature optimization. You need users first! You can always add more servers, and optimize your code later.

If the founder says “We’re using. NET!” or “We’re using LAMP!”, then the VC says “Boring! Next!” If the founder says “We’re using Rails!” or “We’re using node.js!”, then the VC replies “You are following the latest hot trend! How much money do you want?” If you’re using Rails or node.js, then you have the hype-compliant answer to “How will your website scale?”

In this manner, the VC industry selects for hype-based businesses rather than merit-based businesses.

You might ask “Wait a minute? Don’t the VCs get paid based on performance?”

The VC is not looking for the business with the best long-term value. The VC wants to flip his shares to a greater fool in the next 2-5 years. In other words, the VC is looking for a good Ponzi rather than a good investment. With a Ponzi, the #1 priority is good hype. It’s much more lucrative for the VC to dump overpriced shares of Groupon/LinkedIn/Twitter/Facebook, than to invest in a genuinely profitable business at an appropriate valuation.

Also, most VC money is “stupid money”. Due to State law, there are huge pools of pension fund money. The pension fund manager is looking for good kickbacks and CYA, rather than the best investment. Some of this money goes to VC funds.

The VC isn’t just investing other people’s money. He’s investing money for people who are investing other people’s money. It’s nearly completely removed from accountability. The VC keeps his job as long as the hype is good.

That explains why stupid programming practices proliferate. A VC will only invest if the startup is buzzword-compliant. The VC thinks he’s smart, because former programmers are advising him. Unfortunately, the VC probably picked the least qualified programmers as advisers, rather than the most qualified.

The USA is a hype-based economy, rather than a merit-based economy.

That startup had a bunch of red flags. I probably should refuse, if they do make an offer.

It was one of those ideas that made me think “It’s sort of neat, but I don’t see it getting enough users to justify the investment.” I’ve interviewed at a lot of startups that had ideas that were sort of interesting, but I didn’t see them ever being worth enough to justify the investment.

If I stay for a month and they go broke, then I have another short-term assignment on my resume. I could not mention it at all, but then I’d have an even longer gap.

The founder is currently financing the business with his own money. I certainly could not afford to do that.

How many startups are financed by people with rich parents, blowing part of their inheritance so they can dream of being the next Bill Gates?  The founder said that his father was a doctor, so he may have a decent inheritance.

They offered to hire me as an “independent contractor” rather than an employee. Why does that matter? I become an unsecured creditor, when they default and refuse to pay.  Employees are priority creditors.  There are more severe legal consequences for cheating an employee, than for cheating a contractor.

Many dishonest employers abuse independent contractors. The know that, when they default, it isn’t worth the hassle for the victim to sue and try to collect.

One rule of thumb is “Screw over the other person, if you can get away with it.”  There is a serious risk that I won’t be paid.

The head programmer said that a lot of their code needed to be rewritten.  I asked “Who wrote most of your code?” The head programmer replied “A bunch of different people.” I am suspicious that they signed a bunch of people to 1 month contracts, and then stiffed them.

Also, they will string me along while defaulting. If the payment due date is September 1, they will say “Wait one more week!” or “We almost closed a round of investment!” If I get paid on September 15 for work in August, they can squeeze 6+ weeks of free work from me.  Once I’m there, the incentive is to stay, hoping that I will someday be paid. That’s the sunk costs fallacy. If your employer fails to make payroll, you should always walk.  However, in the meantime, they got a month of free work from me, and I lost the opportunity to search full-time for something better.

They said “VCs are interested in our product!” A VC will always act interested, even if your product is lousy. The VC wants the option to invest later, if you do succeed. It costs the VC nothing, to pretend to be interested. The VC’s goal is to string you along, and see how your business performs before investing. It doesn’t count until the deal is closed and the money is in your account.

I asked the founder “Suppose you don’t raise VC and you don’t sign up enough customers to be cashflow positive. How much longer will you keep this going?” He replied “20 days”.

That’s a huge red flag. He was offering me a 1 month contract! The startup has zero assets. After a month, he may declare bankruptcy and default. He may have cheated other people, because he had high staff turnover.

High staff turnover is a huge red flag.  If it really was a great opportunity at a promising startup, the early employees would have stayed.  (However, many people would say that about me, because I switched jobs too many times.  It becomes a sort of career death spiral.  I’ve switched jobs too many times, therefore employers reject me.  Many employers would reject me for superficial reasons, therefore I’m forced to take sketchy jobs.  My most recent job counts as a sketchy employer.)

Any equity part of the offer is worthless. If I had the opportunity to invest cash in their business, at any valuation, I would refuse. Besides, if you do get an equity grant, there’s all sorts of legal loopholes for cheating minority shareholders. If they would cheat independent contractors out of their salary, they would cheat employees out of their equity share, if they were successful.

This post had a huge fallacy.  That post said said “If you do work at a startup, and you have the opportunity to invest cash for extra equity, you should do that.  That increases your upside if the startup succeeds,”  NO!  Only an idiot would do that.  That stupid idea is a type of startup porn.  If you’re a founder, and you can find someone dumb enough to work for free AND buy equity, wouldn’t that be awesome?  I’ve yet to interview at a startup that had better business ideas than mine.  If I was going to blow cash on a startup, I’d do my own thing rather than be a minority shareholder in someone else’s startup.  As a minority shareholder, there’s too many ways to get cheated.  I’d be very suspicious of any startup that wanted to hire me *AND* accepted an equity investment from me.  I can afford to work at a failed startup for a below-maket salary for a year.  I can’t afford to blow all my savings.  If the founder’s only source of funding is from his employees, and not from true angels or VCs, that’s a HUGE red flag.  As a great programmer, working for a below-market rate is enough of an equity investment.  There’s no need to pony up additional cash.  I’d also be suspicious of any startup that couldn’t afford to pay a fair salary, because that indicates they’re underfunded.

At Zygna and Facebook, early employees were cheated out of their options.  After rapid growth, early Facebook and Zygna employees had unvested options that were very valuable.  At Facebook, employees were fired rather than be paid for their unvested options.  Zygna demanded that early employees give back unvested options, or be fired.

If they do offer equity, it would probably have a standard “4 year vesting, 1 year cliff” clause.  They could keep me for 11 months, and then fire me, even after I wrote version 1.0 of their product.  Paradoxically, if I do a great job, that gives them a greater incentive to cheat me!

In effect, I’d be getting a call option for a paycheck.  If they do raise money, they might pay me.  If not, they declare bankruptcy and default.  Even if they do raise money, they could weasel out of paying, and I’d be SOL.

I should refuse, if they do make an offer. The $ amount proposed was less than my last job. There is a high risk that I could work there for a month, and then they default and refuse to pay. They probably cheated other people, due to high staff turnover.  It’s probably a better use of my time to keep searching, than waste a month with them and probably get cheated.

On the other hand, I could take it and keep looking. That’s a possibility. I can take it, expecting to be cheated? That seems stupid.  Maybe I should ask to be paid weekly, rather than wait a whole month?  That would decrease my risk.

They haven’t gotten back to me yet, so it may go nowhere.  They may not make an offer, making it a moot point.

What do you think?  They sound too flaky.  It’d be nice to interview at a startup that didn’t have a mediocre idea.

19 Responses to Test Driven Development – How Stupidity Spreads

    • I’d work for a company I didn’t believe in, if the pay was right. When I was writing financial software, I knew it had no real economic value, but it paid well and I didn’t have to worry about my paycheck bouncing.

      It’d be silly to work for a startup you though was doomed, if the equity was party of the paycheck. I haven’t been earning that much, so the cash-only component of a startup job might be worth it.

      Also, it’s lousy to work for a startup that doesn’t offer health insurance. COBRA is a ripoff.

      Actually, now that I think about it, getting paid in cash isn’t so stupid. If he’s paying me out of his own pocket, cash is better, because it cuts out the State middleman. If I avoid taxes, it’s like getting paid 60% more! He didn’t seem like the kind of guy who’d go for that.

  1. Anonymous Coward July 12, 2012 at 5:09 pm

    >However, many people would say that about me, because I switched jobs too many times.
    >It becomes a sort of career death spiral. I’ve switched jobs too many times,
    >employers reject me. Many employers would reject me for superficial reasons,
    >I’m forced to take sketchy jobs. My most recent job counts as a sketchy employer.

    I had three sets of interviews at a bank in London on three separate days. One interview consisted of an hour long written test. I was told I scored 100%.

    The last interview was about an hour long and consisted of a stream of technical questions. I got all of them correct, except maybe for the last one which was a trivial question about a specific proprietary development environment name for a config file. A stupid question to ask.

    Despite an almost perfect performance in their written and oral questions, the most likely reason I didn’t get the job is because the non-technical interviewer pointed out in had 5 different jobs in almost 10 years.

    It is a pity they didn’t spot that before I had to waste 3 different trips to their offices.

    A friend of mine says pretty much the same as you. He had a series of contractor jobs on crappy death-spiral projects. In the end the recruitment agencies only put him forward for rubbish jobs and some of them were very brazen about it.

    In one job he couldn’t put up with the dishonesty and rubbish strategy anymore and left. The recruitment agency berided him for not sticking it out for a bit longer, even though they both knew the project wasn’t going anywhere and the staff turnover was very high.

    • I had one headhunter that only sent me on sleazy interviews. It actually was amazing. I met with a bunch of different clients, all of which were nearly complete twits. I was surprised both by the volume of interviews, and how clueless/sleazy most of the clients were.

      At one interview, after 6+ hours, they rejected me for “not having enough Java experience” along with “FSK is overqualified”. I never pretended to have much Java experience, so why waste my time? They may have had another reason for rejecting me, but gave that as the superficial reason. According to the headhunter a month later, the position was still open.

  2. Anonymous Coward July 13, 2012 at 7:30 am

    Testing is important. I always test the code continuously as I develop it.

    However I’m sure going overboard with formalized testing and code to test code can cause problems.

    Testing is good. But anything good that involves clowns gets wrecked.

    Instead of realizing the cleverness is in writing code and solving problems, clowns think the cleverness is in repeating mantras. Unless you say exactly what the clowns say, then you are stupid. Stupid clowns can’t write good code. Clowns can’t solve problems.

    I once worked for a famous tech company. Another group pushed out some code that didn’t work. The bug got sent to our group to fix. The buggy source code was under version control and only the other group had permissions to change the responsible source file. I told them repeatedly their code was buggy and they should fix it. They repeatedly tried to shift responsibility even when evidence was emailed to them.

    One of their interns said as their automatic overnight testing had passed the code it couldn’t be buggy!!!!!!

    Of course code to test code doesn’t find all the bugs.

    Eventually the clowns fixed their code.

    • There’s a big difference between testing your own code as you write it, and setting up automated tests, and writing the tests before you write your code.

      Automated tests only matter when you have more users. It’s a waste at an early-stage startup.

      “Test Driven Development” is particularly stupid. How can you write the tests before you write the code? If you do have automated testing, see what problems come up, and then add test for it.

      • You clearly don’t understand TDD. It is NOT writing tests BEFORE the code, it is writing tests ALONG with the code. It’s a HUGA difference.

        • Wrong. Infamous Uncle Bob doesn’t let you do that: You are not allowed to write any production code unless it is to make a failing unit test pass. i.e. writing production code along with the test (before the test is finished) is considered cheating.

          “TDD is a fraud.” (C)

          • I read another amusing argument against TDD. After awhile, you have a LARGE suite of tests. It can take an hour OR LONGER to run the full test suite! And the full test suite has to be run anytime someone submits a patch to the main code branch, leading to a backlog there!

  3. Anonymous Coward July 14, 2012 at 5:49 pm

    I guess another piece of stupidity that spreads is having programming tests that last from 10am to 5:30pm on a day of interviews.

    I went to a day of interviews at Microsoft and each interviewer asked two whiteboard programming questions. As I had to wake up at 5am to get to their offices it was a bit too much.

    After the first few interviews any more technical questions becomes increasingly pointless. It is an exercise in endurance rather than off real long-range intellectual skills.

    The trouble is a lot of other companies copy this style.

  4. Anonymous Coward July 14, 2012 at 5:50 pm

    Forgot to mention I had 4 programming questions before the interviews (3 by email and 1 via Internet whiteboard).

    • My favorite are the multiple-choice programming questions on a computerized pre-screening. Why did I get a CS degree from a top university, if every interviewer is asking a multiple-choice pre-screening test? Is their 15 minute test going to measure more than my CS degree?

      I like it when the multiple-choice tests have errors. Then, I have to guess the intelligence of the question-writer. One question assumed that C++ had closures, but “Hey! C++ doesn’t have closures!” wasn’t one of the choices. (A closure is when local variables are preserved after a function returns, usually local variables that are used in anonymous functions declared locally. One example is the callback function style in node.js, where variables must be preserved for when the callback is called.)

  5. Anonymous Coward July 15, 2012 at 5:47 pm

    It is a long time since I did any C or C++ programming.

    I do vaguely remember static variables in C. I wonder if that has anything to do with that question.

    So long ago I can’t remember!

  6. According to Piwik, I got a lot of traffic from this website. (original untranslated link) It isn’t English. It was 60+ pageviews in one day! Surprisingly, it didn’t generate a pingback.

    It was mostly bounces or 2-3 pageviews. That’s another advantage of Piwik over Google Analytics. Google Analytics only tells me overall bounce rate. Piwik is better at giving me details on traffic from a specific source. Cynically, because Google Analytics makes it hard to track the effectiveness of links and ads, that makes it easier to trick people into advertising on Google! With Piwik, I can identify the original source of regular readers; that is not available with Google Analytics.

    I read another interesting bit about Test Driven Development. It’s a stupid idea that combines well with Design Patterns, another stupid idea. When you use Design Patterns, your project is broken up into lots of classes. When you have lots of small classes, it’s easier to write unit tests. When you have lots of small classes, you have more potential problems, so you need more testing.

    • Hey FSK

      Weblabor is a Hungarian community site for web developers, now there is a heated debated about TDD since many people agree it has nothing to do with automated tests or optimalization but anyway that has not much to do with the article which is informative and great

    • Which one is easier:
      find a bug between 5k lines of code or 100 lines of code?
      Yes, the places are increasing, but they became separated following the SRP, and easier to maintain
      Finding bugs become much faster

      • Just because you have fifty 100 line components, all of which passes every single unit test, doesn’t mean the program as a whole works. When you break the application up into more components, you’re adding more lines of code for the interfaces.

        Suppose your program has a lot of 100 line components. The program as a whole has a bug, even though each component tests perfectly. You still have to dig through and find the problem, exactly the same as if you had fewer components.

        My point is that Test Driven Development adds overhead. It isn’t a substitute for skilled people working intelligently. A highly skilled person will be frustrated in a TDD environment, due to the productivity-draining added overhead. If you have a large group of mediocre programmers, TDD might help you manage them better, but they won’t perform as well as 2-5 highly skilled people managed properly.

        Here’s an example of automated testing at one job I had (but not TDD). It was financial number-crunching, so automated testing made a lot of sense. The program was in C. In C, an uninitialized variable has a random value (actually, it was a global variable re-used from a previous iteration). When the program parsed the input, there was no clause to handle unexpected input. I added a clause that said “If input is not one of the expected values, raise an error instead of continuing with an undefined value.” This broke the automated tests, because one input file contained invalid data. They didn’t want to admit to the customer that the previous version of the program had a defect, so they ordered me to remove the error-checking code!

        At my current (new) job, the software I’m using is a lousy POS. I have no idea if they were using TDD. It’s obvious that nobody competent ever sat down with the program for 5 minutes and pretended to be a user. I found some real boneheaded bugs after using the programs for a few minutes. It is possible that the program passed every single automated test, but I’m finding obvious defects nobody ever tested before.

        Here are some bugs I found:
        * If you close the program while it’s saving, it saves corrupted data instead of exiting gracefully.
        * The program has various editing modes. When you load a file, it enters “undefined” editing mode instead of a specific mode.
        * The program works fine when editing a 300kb file, but it chokes on a 3MB file! (I.e., it’s 1000x+ slower instead of 10x slower.) It’s obvious that someone used a lousy data structure.
        * When the program generates a textbox for me, I’m not able to resize or move that box.
        * The input screens have 50-100 fields each, and I’m only using 1-3 fields on each screen.
        * The button labels on the input screens are misleading. One button is labeled “Accept” (i.e. start working), but it actually means “Submit” (i.e. I’m done.). One button is labeled “Revert” (i.e. discard changes) but it actually means “Refresh screen”. When I edit something, the data onscreen is not updated until I click “Revert”.

        All of these bugs could be handled by automated testing. However, that requires someone intelligent to test the program. I have no idea if the authors of those programs were using TDD or not. They certainly were incompetent. (They’re probably billing the bank $10M+ for that POS.) It is possible that those programmers thought they had a perfect program, because it passed every automated test.

    • The blog has some very valid points – 1) Overheads of using TDD 2) TDD is not a panacea and is certainly not a substitute for intelligent testing and programming 3)As always there are situations where TDD is appropriate or otherwise

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>