tddfuckwitz

A good point. I think the bigger learning exercise for this team in particular would be: do we need this test and why? To make them examine a bit more about what they are trying to achieve and not just succumb to testing by numbers. Ultimately, the large battery of tests passes, but when the system is still borked, the disconnect is great.

To be fair, you don't have to use LLVM or Swift, if you don't want to - there are other compilers and languages out there, some already cross platform (hello C++).

I understand the unhappiness though that so called techies and developers these days do not question anything anymore. They just take what they are spoon-fed and ask for more of the same.

Does this eventually end up as yet another virtualization layer? How big and bloated does the web stack become before we start again, with a lean protocol and markup language for text documents?

Can't blame him for asking. He has obviously sized you up correctly, given you didn't say no to him straight off the bat. Unless you expect lawyer cannons to be fired broadside at your startup on an hourly basis, how much involvement would you really need? There is your answer. Now, about my ten percent equity for the above advice...

I have just come onto a project that has tests up to the armpits, mocked everything, and the test lead wielding an almost evangelical bent across the developers. And the codebase and system is still shit. Why? Because the team though loads of tdd and bdd equals a great system. Wrong. They can help, when used sparingly, but to make them your design methodology, praying at the church of testing dogma is insane. So, no tests bad. Worse, over testing. When I see fourteen tests to one code unit, I know now to run away.