I'm Agile but My Contract Isn't - <AUTHOR> http://www.stridenyc.com/blog/2014/10/3/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams <comment><USER2> > _"No changes will be effective unless and until memorialized in a written > change order signed by both parties."_

Ahhh, in the "Enterprise", we call this a Change Request (we would name and number them CRXXX, for example) and put them in a "register" (Excel doc that got passed around 100x a day). These become so excessive they needed to be managed by a Management Consultant (who charges $250+/hr) who specializes in change management.

> _There are three variables to any project: Money, Time, and Scope._

Every project I approached, I would draw the following diagram to the client: [http://en.wikipedia.org/wiki/Project_management_triangle](http://en.wikipedia.org/wiki/Project_management_triangle) and any time one of the corners changed (it always did) I would redraw the triangle and ask the client how they wanted to proceed with ensuring the quality of the project.

As someone who has successfully and unsuccessfully implemented agile in arguably the worst environment possible ("The Enterprise"), my general conclusion is this: if the client doesn't understand agile fully or is already implementing practices that are agile-like, then do not begin the project. Set up workshops, assess their ability to adhere to budget-less (agile) projects, and make a decision then. For smaller clients, I typically ask the client "what's your budget?" and then I work backwards from that. So if a developer is $100/hr, and the client has $5k to spend, I'll say "ok you get a developer for 50 hrs. Most likely we can build this, this and this" If/when the client disagrees ("But I can get 2 people in Malaysia for that price!") you simply tell them to go find someone cheaper on oDesk.

<comment><USER3> I'm wondering up to what size you managed to do an agile project for 'The Enterprise'. From what I've seen, as soon as an enterprise contract is big enough to involve a tender, bidding round and separate purchasing department, agile is impossible. Being agile actually works against you, since regular demo's will bring up more opportunities to point out how you aren't sticking to the letter of the contract, flexible scope means adding scope and never reducing it, and grooming as you go along means uncovering big requirements which are sort-of-kind-of in the contract halfway through a big project that's already late. And those are the easy projects compared to government contracts.

I keep wondering how you're supposed to negotiate the typical big enterprise contract so you're allowed to be agile while executing it. I haven't seen it done successfully yet.

<comment><USER2> You're not incorrect. But I always like to think there is always a possible ;) The reality is agile is such a strong buzzword in 'The Enterprise' now that you can't even avoid it anymore.

The one that was successful was a $250k project - 3 months. Client insisted fixed price and done "in agile". We estimated the actual work was only 6 weeks, but knew they'd change their minds 100x times (they did). We didn't optimize the timeline properly (as you are insinuating, it's almost impossible to predict), so our margins ended up being quite low.

I do know one company which successfully does agile (within a company that does $100bil in rev). They budget the whole year out for X amount of employees and then do everything in 3 week sprints. They basically "fit in as much development as they can with the resources they have" and disregard the high level 3-year "integration plans" that the management consultants put together.

</comment></comment></comment><comment><USER4> This article really addresses the need for agile development to be a two way street [1]. I loved the manifesto when I first read it, and I still do. But I've noticed it really goes wrong when both sides don't adhere to the principle - when one side tries to be "agile" and the other side lawyers up, the agile side will get railroaded if (and probably when) the relationship turns sour.

"Individuals and interactions over processes and tools" means "we come by your office to interact with you as an individual about why your story points haven't velocitized properly in the time tracking system" [2]

In a similar vein, "Customer collaboration over contract negotiation" becomes "we'll hold your feet to the fire about deadlines and estimates, but we reserve the right to change our minds at any point."

In this sense, agile becomes unilateral disarmament in the face of a heavily armed… neighbor. I wouldn't say "foe", yet, but good relationships can turn bad. It's like one side saying "let's do this with trust and work together", but they're the only ones with a lawyer at the table.

In some ways, the agile manifesto almost says "peace and cooperation over fighting and coercion". Yeah! I'm for it. But we _both_ need to do this!

[1] I feel a little embarrassed using the word "agile", but I figure that as long as it's an adjective, I preserve some dignity. [2] I'm not technically a _certified_ scrum master, so I may have some of that slightly wrong.

<comment><USER5> Let's step away from the contracting scenario for a minute. Let's say it's purely in-house, and the team is committed to agile. That's great... until you run into a layer of management that doesn't understand agile. They still want the old waterfall-style progress reports, and they still make decisions based on them - decisions that can kill your project. This can force you to suddenly be less agile, or to present an interface to those outside your team as if you were not agile.

Back to contracting. If you're a contractor, even if the team you're working with is fully on board with being agile, you can still get burned by higher layers of their organization.

</comment></comment><comment><USER6> Clients almost always want it fixed-price, but those same clients, when it comes to the actual project, they turn into agile scope creepers.

It is very important to discuss all this upfront with clients, many of them have no idea of estimation, the mythical man month and are horrible at knowing fully their ideas, the level of detail, before work starts yet will want fixed. It is especially bad on clients new to apps/games/web or their first attempt who just see surface level tasks.

Iteration and a more agile approach will hopefully find the way into business and mba textbooks/processes. Right now almost everyone wants fixed-price and flexibility to change at will. This will only hurt developers/designers and ultimately the project chance of success.

And don't get me started on non-competes the most anti-innovation, anti- business, anti-american (if you are in the US) thing ever being fully pushed by business at every turn. Most non-competes want you to come in to help a company compete, then once they know how or you have built it for them so they can compete, you can no longer compete any longer for a time because you helped them, makes sense for kings/owners/dictators but not fair business.

</comment><comment><USER7> The underlying issue is risk management. Customers want certain features within a certain budget, hence their need to constrain at least two of the variables mentioned in the article. They want the vendor to take the risk of going over budget.

Vendors, obviously, want the customer to take the risk. This is why we see articles like this.

If you want to apply agile methodologies in these situations, you need to keep the scope small and also constrain the time. That keeps the risk for both the customer and vendor manageable.

<comment><USER8> We have a different approach. If the customer wants a fixed scope and price, we make an estimate (considering both our internal cost, and the value of the work for the customer) then double the price.

They usually do not accept and want it cheaper. Then we offer the project at the estimate and to split any difference. So if we use 1 hour less at 200$/h, they get it 100$ cheaper. However, if the project ends up taking 1 hour more it will only be 100$ more for the customer.

I really would wish that the customers would trust us more and accept it at the hourly rate to get the initial work. Then we can iterate on that until they're satisfied.

<comment><AUTHOR> Agreed that if we can get 2 sides to 'trust' each other, we can minimize the need for this type of approach.

</comment></comment></comment><comment><USER9> Fixed contracts (Option 4) are extremely problematic for clients. I rarely seen one of those going well.

There are 2 options:

a) The supplier is not an expert in this and will have problems with the project changing scope and maybe running over budget and time which they cannot invoice. This leads to the supplier being at the unfair end of the deal, leading to poor work by the numbers.

b) The supplier is an expert, works on a fixed scope and denies all requests for changes (without renegotiation). This rarely works in favour of the client. I had prospective clients coming back to us after another company wrote them a software perfectly for their spec, but they realized in the middle that the spec was not fitting their business case properly.

</comment><comment><USER10> This clause sounds more like it has to do with changing features that a developer may see as an improvement and a client may see as a "holy crap, what happened, now I have to retrain my staff."

We're agile, working with established businesses. We have to take in our clients real world needs into account. Agile is a set of principles and a guide, not a set of physical or economic rules. Sometimes the tool isn't the best for the job, sometimes two conventions (client's work, developer's work) contradict.

<comment><USER10> Reply to self: Of course, as relationships grow, we know our clients better and they trust us to make the right decision or fix it quickly on production.

</comment></comment><comment><USER11> If "Agile" really works (and I have no opinion on whether it does), then its use should be an implementation detail that the client doesn't need to care about, but which allows the consultancy to offer much better estimates of time and cost for a given scope.

In other words, if your methodology is so great, use it to your business advantage.

<comment><USER12> Agile is definitely an implementation detail but good clients will care about it for precisely the reason you provided.

They won't care to hear about the specific labor pains, but they will love it when you tell them your "agile" development process allows them to get prototypes quickly and provide further input as their ideas take shape.

"In other words, if your methodology is so great, use it to your business advantage."

I did and it resulted six-figures worth of contract work last year from just one client. Part of my sales pitch was to explain agile development in a way that focused on their business.

When I asked the client why they chose to work with me instead of the bigger agency, they mentioned 2 things: 1) They liked the feedback-driven development process and 2) I talked about their business instead of the technology that would go into the software.

The best part is that an agile process helps you position yourself as a trusted advisor instead of a commodity laborer. When you do that, your clients get better results and provide repeat and/or referral business.

TLDR: The best clients do care if you're agile about their business needs.

</comment></comment><comment><USER13> The article mentions this as a question if you want to confine the amount of money you spend: "How much do you want to invest before we stop?"

I think this is one of the fundamental issues with Agile, if a client wants to hire a consultancy to complete a project, they want to know how much it will cost and what will actually be completed.

Forming the question as: "How much do you want to invest before we stop?" requires a large amount of trust in the consultancy, personally I have worked with a number that supply below par developers and so asking "How much do you want to invest before we stop?" gives the client no guarantees and the consultancy no obligation to what will actually be delivered.

I think agile can work for in house software teams but not so much for consultancies, where in reality there are normally 2 or 3 of those variables mentioned in the article fixed.

<comment><AUTHOR> Yes, it does require trust. I have personally seen Agile work for consultancies (It works well for my consultancy, Stride). The trust factor is paramount. We take a lot of care and implement many practices outside the contract to ensure we deliver what the client wants.

</comment></comment><comment><USER14> If as the OP says, it's about treating the contractual relationship as an investment to deliver value then I believe we can do better than simply "fix scope". I've recently written about this at length including why the contract model (and agile derivatives) do little to align the interests of client and supplier to deliver value. ([http://www.energizedwork.com/weblog/2014/09/commercial- contr...](http://www.energizedwork.com/weblog/2014/09/commercial-contracts- guarantees-commitments-risks))

</comment><comment><USER15> In the US, if you're "agile", you're an employee, not a contractor, for tax purposes. Read IRS Publication 15-A, page 7. A fixed-goal, fixed price contract is a real contract. "Agile" puts you under the "behavioral control" of the employer at a more detailed level, which makes you an employee.

[http://www.irs.gov/pub/irs-pdf/p15a.pdf](http://www.irs.gov/pub/irs- pdf/p15a.pdf)

<comment><USER12> It's not that simple. Being "agile" does not necessarily makes you an employee in the US. From IRA Pub 15-a:

"The general rule is that an individual is an independent contractor if you, the person for whom the services are performed, have the right to control or direct only the result of the work and not the means and methods of accomplishing the result."

As an agile contractor you can give clients options that allow them balance quality & cost without being under "behavioral control." The client gets to say they want to build a widget that does X and Y, then you choose to build it at time T using whatever tools and methods you deem appropriate.

Couple that with offering these services to the public: "People such as doctors, veterinarians, and auctioneers who follow an independent trade, business, or profession in which they offer their services to the public, are generally not employees."

That said, "whether such people are employees or independent contractors depends on the facts in each case" so make the facts obvious in your contract with a section like this:

"Independent Contractor. The Parties agree that Contractor is an independent contractor and that Contractor has full control over the methods utilized in performing the Services. Contractor will not make any representation of an employment relationship between Contractor and the Company and will not claim any benefits provided by the Company to its employees. Contractor has no authority to contract for or bind the Company in any manner, except with prior written consent of the Company. Contractor shall devote such amount of his or its time, attention, knowledge, and skills as may be required to create and deliver the Product and to perform the Services."

</comment></comment><comment><USER16> It sounds like the author is working with contracts that are too detailed. Contracts should specify the legal obligations and structure of a relationship between two parties, but if it is getting into procedural detail, or dictating the policies of an organization, it is just asking for trouble. At that point, an internal process change could violate a contract clause. That just doesn't make sense.

<comment><USER9> You can always amend a contract. Just write a sideletter. A contract should always contain a definition of the services and the mode they are supplied and invoiced in.

<comment><USER17> I work with two types of documents: master consulting agreements and work orders. The master consulting agreement has all the "standard" stuff like IP, confidentiallity, indemnity, etc. The work orders are where I specify what we're going to do(1), how much it's going to cost, and when it will be delivered. Both are dated and signed. This works well for me and allows me to do agile-style sprints with work orders. This is usually in addition to a ballpark price range for ballpark scope.

(1) Where "what I'm going to do" can be substituted for "what I'm going to try," when the client understands why I can't guarantee something.

<comment><USER9> That, I do a lot as well. Basic point being: a fitting contract doesn't have to be a hassle.

</comment></comment></comment></comment><comment><USER18> Based off of reading this, I can imagine a lot of people not wanting to hire you. _I get what you 're saying_, but all you've communicated to the customer is that you always need enough wiggle room to successfully screw them over. You should still place contractual bounds on how something can change.

<comment><AUTHOR> Yes, if all I offered a client was an Agile contract, they shouldn't want to hire us.

But, the contract is 1 piece of the puzzle. In order for businesses to want to hire Agile teams, whether consulting teams, freelancers or otherwise, many factors have to exist in addition to an Agile contract.

These factors include - high quality development teams, visible work, high collaboration, working agreements, trust, a cancellation clause, definition of "done", and more.

</comment></comment><comment><USER19> \- Why push agile onto the contract?

\- Why not move to a whirlpool (or other milestone-based iterative process) with fixed milestones?

</comment><comment><USER20> lol.

On one hand we have culture and art and philosophy and technology. We have technological culture and art. We have philosophies for creating a culture for creating technology. Then, OTOH, we have this. An inability to collaborate for fun or profit.

We need to account for various skill levels, failures in communication, philosophical differences. Scheisterism, baseless accusations of scheisterism. Bugs. etc. etc.

Collaboration is ultimately a fundamental problem, perhaps the most fundamental one.</comment>


The 20 Minutes That Broke the U.S. Oil Market - <AUTHOR> https://www.bloomberg.com/news/articles/2020-04-25/the-20-minutes-that-broke-the-u-s-oil-market <comment><AUTHOR> Paywall free - [http://archive.md/XBP6v](http://archive.md/XBP6v)</comment>


Resolving the St. Petersburg Paradox - <AUTHOR> http://mindyourdecisions.com/blog/2010/06/07/the-st-petersburg-paradox-a-flimsy-critique-of-expectation-theory-by-people-who-dont-know-math-or-economics/

<comment><USER2> What about the TVOM implications? There has to be some opportunity cost for both sides to playing the game. Given the potential loses involved I think it would be foolish for anyone to play the game as the seller/ coin tosser.</comment>


Node-Qt: Build native apps using Node.js + Qt (Windows, Mac, Linux) - <AUTHOR> https://github.com/arturadib/node-qt <comment><AUTHOR> Hi, OP here. For folks who prefer HTML5 APIs, I'm also working on a layer that translates these Qt APIs into HTML5 primitives (like Canvas and AudioContext):

<http://news.ycombinator.com/item?id=3816870>

(There are some neat demos there :))

<comment><USER2> Wait, so what Node-Qt and Node-Five would both allow you to use exactly the same code?

<comment><AUTHOR> Not the same, but sometimes similar. (For example the QPainter API is similar to the Canvas 2D API, etc).

Node-Five is for folks who are more familiar/prefer HTML5 APIs over Qt's proprietary API.

<comment><USER2> Hold on, I think I misinterpreted something. Is Node-Five a Web framework or a native application framework?

<comment><AUTHOR> Think of Node-Five as a very small WebKit/Gecko engine for Node.js. It is written in JavaScript on top of Node-Qt, whereas Node-Qt itself is written in C++.

When I say "native apps" in this context I simply mean you don't need a traditional browser to run the apps, and the runtime interacts more closely with the OS (for example, Qt exposes native menu methods, native OpenGL, etc).

<comment><USER2> Ah, okay, awesome. I was thinking Node-Five was a Web framework which would take your Node-Qt code and run it server-side as a public Web application by translating the Qt API calls.

</comment></comment></comment></comment></comment></comment><comment><USER3> In the sample on that page, it says:

       // Prevent objects from being GC'd
       global.app = app;
       global.window = window;

Why do you need to do that? I thought that as long as there were still references to an object, it isn't GC'd.

<comment><AUTHOR> Yeah it's just in case there are no surviving references to those vars. For example in the hello world code app gets GC'd unless it's in a callback in setTimeout().

</comment></comment><comment><USER4> From Qt5 "Lighthouse" would replace C++ as the main development method, and the Qt Quick language in Lighthouse is just a JavaScript extended language, IMHO, this project is just another re-invention of the wheel...

And on desktop, we already have state-of-the-art web browser Chrome, why bother using this to write HTML5 Canvas based app?

</comment><comment><USER5> Nice. Last time I looked at Qt bindings for Node, it didn't support async and used the main node thread to run the UI on (OSX seems to require Qt use the main thread to draw UI on).

Care to elaborate how you got around this? I tired several different things and couldn't get it done.

<comment><AUTHOR> Some Qt APIs are inherently asynchronous (like QHttp) but the graphics-related ones I'm binding to are not (like QPainter).

So the situation is analogous to the DOM in web browsers. The calls are synchronous and run in the main thread. As the web has taught us though, single-threads and blocking graphics calls can go a long way :)

<comment><USER5> True, but Qt specifically (as well as many OS such as Mac OSX) do not allow running of the GUI in anything but the main thread. This is due to the fact that (from what I've read) graphics drivers are not thread safe.

Just wondering how you got around this...I see you're using processEvents in QApplication.

from <http://doc.qt.nokia.com/4.7-snapshot/thread-basics.html>:

GUI Thread and Worker Thread As mentioned, each program has one thread when it is started. This thread is called the "main thread" (also known as the "GUI thread" in Qt applications). The Qt GUI must run in this thread. All widgets and several related classes, for example QPixmap, don't work in secondary threads. A secondary thread is commonly referred to as a "worker thread" because it is used to offload processing work from the main thread.

<comment><USER6> On X11 I actually have a bunch of patches so I wrote for Qt so I could do painting in another thread. It was useful for a project where I was injecting QtWebKit into a game where the main thread was the game and the Qt event loop and all its processing had to exists on a different thread sending a single opengl buffer across when rendered. I got some patches into Qt, but others were rejected for one reason or another (could no reproduce, not supported etc), but nonless it was a very cool project.

</comment></comment></comment></comment><comment><USER7> God job . Will definitely give a try , as I have some experience in both of them .. I always wanted to try qt php bindings, but even running the example apps was difficult .

Thanks to NPM :)

</comment><comment><USER8> This seems to describe a large portion of javascript based frameworks:

This is a list of common errors when experimenting with Node addons, and their possible solutions: "Out of memory"

<comment><AUTHOR> Hi, OP here. As explained that message happens when you mess something up in the C++ bindings, not because of JavaScript actually running out of memory.

</comment></comment><comment><USER9> So... this allows us to run webservers that call Qt methods? Why would anyone do that?

<comment><USER10> It allows you to call Qt methods from JavaScript. You don't need to run Node as a webserver.

<comment><USER9> Don't they have QtQuick or QtScript for that?

</comment></comment></comment><comment><USER11> OT but regarding the current native app hype (especially in the mobile space): I still don't like native apps except my browser, my editor, the shell and some legacy software (Office and Adobe CS). I don't like updating 30 apps a week on my Android. But it's more than a trend I guess?

<comment><AUTHOR> Node-Qt apps are really semi-native since the app itself is written in JavaScript. So you can easily make your app auto-updating, just like a web app. (iOS is an exception due to Apple's restrictions, unless they're OK with QtWebKit which I doubt).

</comment></comment><comment><USER12> Why the dependency for Python?

<comment><AUTHOR> That comes from node-gyp (Node's addon build tool)</comment></comment>


A collection of iPhone apps screwed over by Apple - <AUTHOR> http://screwedbyapple.tumblr.com

<comment><USER2> In other words, a collection of mobile apps that could find a good home on Android.

<comment><USER3> Or Cydia

<comment><AUTHOR> Surprisingly, the rejections seem to have demotivated a lot of these from bothering to port them to Android or even put them in Cydia. The world of Cydia is still mysterious to a lot of developers and people we talk to are confused about how to even package applications properly for Cydia.

</comment></comment></comment><comment><USER4> Interesting, how did TrapCall even work?

<comment><USER5> It still works, by forwarding unanswered calls to their number where it routes through a toll-free that they pay for the incoming call to unmask the number.

<comment><USER4> Wow, that's actually really clever! I'd pay for that Ina heartbeat.</comment></comment></comment>


We recognise talent far more easily when it's accompanied by success - <AUTHOR> http://www.ft.com/cms/s/2/c3c4f7da-09f2-11e3-bc4e-00144feabdc0.html#axzz2cpF75ZKN

<comment><USER2> That means you recognize success, not talent, which is the case for most people. Most people see success, success on top of success, and the ability of someone to string the right words together, not whether they are talented or not.</comment>


On the Timing of iOS's SSL Vulnerability and Apple's 'Addition' to NSA's PRISM - <AUTHOR> http://daringfireball.net/2014/02/apple_prism <comment><USER2> This seems so silly to me, Jon.

The OSX/IOS SecureTransport TLS vulnerability is getting coverage because it's easy for laypeople to understand. Any geek can look at a description of the bug, or even the code itself, and say to themselves, "hey, I could exploit that!". Because more people understand this bug than they would any other bug, it paradoxically seems scarier.

The reality however is that the ease with which a bug can be exploited has little to do with its impact. What matters is the feasibility of exploitation. And in terms of feasibility, this bug is _less_ exploitable than the kinds of bugs that are disclosed in every platform every month; it requires a specific (common, but not universal) set of circumstances to escalate it to code execution.

Matthew Green told a Reuters reporter yesterday that the TLS bug was "as bad as could be imagined". He was also drinking†, which explains how he managed to find a TLS validation bug worse than memory corruption, which is discovered routinely in all platforms, and produces attacks that directly, instantly hijack machines regardless of their configuration and the network they operate on.

Vulnerabilities in TLS code are not all that unusual. We get a new one every couple years or so. There was a vulnerability in the NSS False-Start code a year ago --- it didn't get covered because (a) few people know what NSS is (it's the TLS library for Firefox and Chrome) and (b) nobody knows or cares about False-Start. Here's another example: NSS misparsed PKCS1v15 padding, such that an e=3 RSA certificate could be forged --- anyone on the Internet could run a small Python script to generate a certificate for any site. Certificate chaining has broken within the last ~4 years ago. Again, no coverage: what's e=3 RSA? How does chaining work?

Simple thought experiment: imagine if, instead of a missing-brace bug that broke all of TLS, it was instead disclosed that NSS had a memory corruption vulnerability in its PKCS1v15 parsing. Would there be a shitstorm in the media and on Twitter? I doubt it: comparable bugs are found routinely without shitstorms.

I don't know if NSA knew about this bug or didn't. If they did, I'm confident that they exploited it; that's what they do. But ask yourself if you're sure that NSS and SecureTransport and OpenSSL and SCHANNEL are free from the kinds of memory corruption vulnerabilities that would allow NSA (and other organized criminals) to hijack machines directly. You think _this_ is the bug they're relying on?

† _No, really._

<comment><USER3> Tptacek, it is scary because of exactly that -- it is so simple. How could such a secure platform built by such a massively large cap tech company do something so incredibly stupid in its most critical security stack.

If this trivial bug can happen and pushed into production .. Good lord, anything can happen.

The foundation of our mobile economy has just been proven to be on very very shaky legs.

<comment><USER2> This is a comment that seems to suggest that it's abnormal for dumb bugs to cause huge security problems. It is not. If the foundation of our economy is C software security, well, hate to break it to you, but...

<comment><USER3> It is absolutely abnormal for companies like Apple to release core security bugs this shallow that could have been easily discovered by straightforward unit tests and static analysis tools.

This is why it's a big deal.

<comment><USER4> The other reason why this is no big deal (anymore) is that the Snowden leaks have shown that the NSA has total control over all iPhones.

Why should we even bother talking about bugs like this anymore? Pure distraction.

<comment><USER5> > the Snowden leaks have shown that the NSA has total control over all iPhones

You mean: had total control over all the original iPhones that they could get physical access to. (back when jailbreaking was extremely simple and common)

<comment><USER4> Where does the "physical access" part come from? And if that was the case, why would it be impossible now?

One of the sources: [http://www.forbes.com/sites/erikkain/2013/12/30/the-nsa- repo...](http://www.forbes.com/sites/erikkain/2013/12/30/the-nsa-reportedly- has-total-access-to-your-iphone/)

<comment><USER5> From the slide on your very link: "The initial release of DROPOUTJEEP will focus on installing the implant via close access methods. A remote installation capability will be pursued in a future release."

Basically how it worked was they jailbroke your iPhone and installed spyware on it. Is it quite likely that today, 7 years later, they have a remote 0day to do the same? Absolutely. But there's no proof that "the NSA has total control over all iPhones".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Let's not ascribe all deviousness to the NSA!

Sneaking this in, and being the 1st (or only) group to know about it, would be valuable to lots of amoral entities, from solo criminals up through state actors. Simply being bold enough to use a bogus signing-key (different than the one in the certificate you just showed) was enough to fool every iOS6/7 device for more than a year!

I'd personally hope that the NSA would be more subtle, and has a longer-term interest in ensuring Apple products _seem_ secure. Other state actors or criminal gangs would be more interested in a short-term benefit, and then wouldn't mind that afterward Apple (and US tech in general) gets egg-on-their face. That could be icing on the cake.

I hope Apple does a deep-dive on how this happened – not just "5 whys" but "50 paranoid whys" – including looking at the employee who made the change's background and personal security practices.

What if the person it's traced to does not recall making that change? What if they find evidence that systems designed to catch such a thing were themselves subverted, such as different code shown to a reviewer, or build tools set to suppress certain warnings? It might be a simple slip up... or a very, very deep compromise that takes weeks or months to unwind.

Letting my paranoid imagination roam wild, recall a few years ago when Google suddenly became very, very chilly towards China, after reports of some deep compromises. My hunch is that Google perceived a threat so extreme – like an attempt to hijack their auto-update mechanisms – that it resulted in an all- new level of lockdown and resentful cold war. What if this is a similar existentially-revelatory moment for Apple, with regard to some state actor?

<comment><USER7> Your conspiracy theory is a bit too complicated. Here is how it works in practice: Bad actor shows up (compromised employee, or vendor with system access, whatever). Bad actor notices that code reviews are not required or a reviewer can be buffaloed with a 10k line commit, and static analysis tools aren't a commit hook, or employees don't lock their computers, or he has access to scp a binary on to a production server, or dozens of possible exploits that everyone knows about and is planing to fix eventually...

</comment></comment><comment><USER8> Unless I'm misunderstanding exactly what PRISM is, this bug seems like it would only be useful for OTHER nsa data collection programs, not PRISM.

Unless, of course, we are now using the term PRISM to refer to all NSA activities that we don't agree with.

Gruber should know better.

<comment><USER2> We are definitely using the term PRISM that way.

<comment><USER9> You might be, but Gruber wasn't -- the evidence he linked to was a powerpoint slide which was specifically about PRISM. Which means that it is not relevant when trying to determine if NSA introduced this vulnerability or not.

</comment></comment></comment><comment><USER10> To everyone claiming "it looks like a merge gone bad": That's a bit hard to believe. There's no other changes around the extra goto, so it's pretty weird for a duplicate line to appear like that out of nowhere. It's also incredibly visible in any diff viewer, so how such a checkin could have gone in without being noticed is just unfathomable.

<comment><USER2> It's hard to believe if you pay no attention to bugs caused by code refactorings, but easy to believe if you, for instance, saw the OpenBSD IPSEC team refactor authentication checking on IPSEC packets out of the kernel by accident, in almost the exact same manner as this bug.

<comment><USER11> No, because the OpenBSD case was NSA as well (via NETSEC, who worked on the OpenBSD IPSEC stack, and have since admitted to sneaking backdoors in). Exact same MO, 15 years later!

(I don't actually believe this, but it was too convenient and amusing not to call out.)

<comment><USER2> I thought the NETSEC conspiracy theory was Angelos Keromytis working for the FBI.

</comment></comment></comment></comment><comment><USER12> It's not the first time Apple has a bug with verifying the hostname of the certificate.

In June 2010 I reported that Safari 4 did not check the last letter of the hostname, so a certificate for example.de was accepted when accessing example.dk, and it would accept cert for example.co.ug when accessing example.co.uk

The real problem is that Apple did not add unit testing when they fixed the problem in 2010. If they had, the goto bug would have been found.

<comment><USER13> The "person" who made the "error" in the core code could have made a similar "error" in the unit test.

<comment><USER14> Yes, that would be quite the "coincidence", wouldn't it?

</comment></comment></comment><comment><USER15> Why would the NSA put a backdoor in an open source component of iOS and OSX when presumably, it would have been just as easy to put it in the closed source part, where it would be much less likely to be found and even less likely to ever be publicly exposed?

</comment><comment><USER16> Wrong. The only 3 options are these:

1) The NSA knew about it, and exploited it.

2) NSA itself planted it surreptitiously.

3) Apple, complicit with the NSA, added it.

Such a bug would've never lasted this long without NSA knowing about it. Even if they didn't find it themselves, which seems unlikely, they would've bought it from the exploit black market long before now. There are people who all they do long is try to find exploits in the iPhone.

And as we know, if NSA _can_ do something, NSA _will_ do it. So they most definitely took advantage of that "bug" and everyone's data that they could get through it.

To me the more likely scenario is still that Apple cooperated with the NSA here. The "adding to PRISM" at the same time this bug appear is _way_ too coincidental.

<comment><USER13> Further to 1) if the NSA fulfilled its mission and actually helped secure the country against enemies, they would have immediately told Apple about the security hole. Hence we're down to 2) and a modified 3) Apple, complicit with the NSA, added or kept it.

</comment></comment><comment><USER17> > I see five levels of paranoia: ... 5. Apple, complicit with the NSA, added > it.

While it seems _possible_ that Apple conspired with the NSA to add a security hole in SecureTransport, I doubt it. According to sources in the article, this bug was introduced in iOS6; and I haven't heard a mention of it until yesterday, despite it being open-sourced ([http://opensource.apple.com/source/Security/Security-55471/l...](http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c)).

Since nobody was raging on the internet about this bug, I see it as a good- faith effort by Apple to fix a bug that they've just discovered.

<comment><USER16> Consider this: it was only at the end of December when Appelbaum showed some documents about iPhones being hacked by the NSA, and it made a pretty big splash in the media. I think it even forced Apple to respond at the time. _Especially_ if this was open sourced, and everyone could see they fixed it, they wouldn't _immediately_ try to plug the bug/backdoor after that piece of news came out, especially with such a weird bug.

<comment><USER18> Those documents were about NSA bein able to plant a malware on a iPhone (1st generation) when given physical access. I would say it has nothing to do with this TLS bug

</comment></comment></comment><comment><USER19> I also would go at least as far as #3 ( _The NSA knew about it, and exploited it._ ). And it does seem a reasonable explanation for the prism slide update.

I only just heard about this bug a couple of hours ago. I can not for the life of me fathom how this code was not tested. Surely this is a basic function of the security code. You can test for it with a simple bit of js. If something as important and easily testable as this is broken, what other subtle issues are down there?

I, for one, no longer trust the Apple's software (I know that seems a bit dramatic but I just don't enjoy using it anymore, on any level). Intentional or not, this has all been handled very badly. Massive security hole, quietly releases iOS update, doesn't offer update for their freaking desktop os.

<comment><USER20> In theory yes. But Google Engineer Adam Langley wrote:

> A test case could have caught this, but it's difficult because it's so deep > into the handshake. One needs to write a completely separate TLS stack, with > lots of options for sending invalid handshakes. In Chromium we have a > patched version of TLSLite to do this sort of thing but I cannot recall that > we have a test case for exactly this. (Sounds like I know what my Monday > morning involves if not.)

</comment></comment><comment><USER16> > The Prism program collects stored Internet communications based on demands > made to Internet companies such as Google Inc. and Apple Inc. under Section > 702 of the FISA Amendments Act of 2008 to turn over any data that match > court-approved search terms.

[https://en.wikipedia.org/wiki/PRISM_(surveillance_program)](https://en.wikipedia.org/wiki/PRISM_\(surveillance_program\))

"Demands made to the companies". It looks to me like PRISM was a voluntary thing, even if the companies didn't know it was named PRISM.

If that's the case, and Apple's "bug" happened at the same time with their _voluntary_ addition to PRISM, then the bug was actually a backdoor, and Apple knew about it.

<comment><USER21> Prism is as precisely as "voluntary" as the cops showing up with a search warrant at 5am and asking you nicely to open up "voluntarily", because, well, they have a nice 5.11 MiniRam Breaching Tool 50091 and your door looks very pretty and it would really be a shame to have to knock it off its hinges. Yes, that would be a real mess.

See what I wrote on this last summer: [http://news.cnet.com/8301-13578_3-57588337-38/](http://news.cnet.com/8301-13578_3-57588337-38/)

</comment></comment><comment> daniel-cussen I thought the date NSA was added to prism simply had to do with Steve Jobs dying. It's the kind of thing I could see him refusing to cooperate with.

<comment><USER22> The date has to do when Apple had cloud services that more than a few people outside the US used. There's no point simplifying data requests to a provider that doesn't have any data they want.

</comment></comment><comment><USER23> Where is the patch for OSX Mavericks Apple? Patches aplenty for iOS yet it appears Safari is still vulnerable.

<comment><USER24> Exactly. My MacBook is now for sale. Back to my Lenovo T400.

Trust = gone.

Apple's policy of silence and denial don't cut it any more. At least Microsoft use proper threat modelling, disclosure and mitigation processes, documented KB articles and have literally tonnes of QA and test capacity. Not joking but they have tens of thousands of machines in their test labs.

</comment></comment><comment><USER25> The thing that _really_ bites about this is the idea that the NSA could have taken advantage of the vulnerability rather than alerting apple to it.

The idea that they are as fiercely hostile to the security of millions of americans as taking advantage of the vuln would require, is absolutely terrifying.

</comment><comment><USER26> I am not sure if such post has any value to add to our current state of affair. If this is not the bug they use to exploit iOS users, there are other bugs. So what is the point of this article? Are we going to do a _witch hunt_ and blame the developers who either overlooked at the diff, or the developer who happened to be an NSA mule?

I get it. NSA is behind everything. And at the end of the article, OP says "[so] if this bug, now closed,2 is not what the NSA was exploiting, it means there might exist some other vulnerability that remains open." So why are we writing this article if there are other bugs?

Okay. I will give the credit and think about it: anyone could be NSA mule. Anyone can contribute to your OSS and inject some clever code into your OSS codebase. And we usually overlook security and just accept anyone's PR as long as the code makes sense. Yeah, think about someone cleverly injecting a line into your docker release or your openstack release last month.

So, the point is: be alert? Be aware of spy everywhere? This reminds me of a scene in movie _Eden_. Bob, the corrupted federal Marshall, who was actually a PIMP, once said to other marshals: "So who are you [looking for human trafficking mules] looking for? The answer is everyone."

Hence, the main point is: trust is destroyed.

</comment><comment><USER27> My own conspiracy theory is that these times match up where they adopt some form of widespread XMPP. Google Talk, iMessage (2012), MS Messenger, etc... and aligns with the recent talk of re-doing encryption in federated XMPP: [https://github.com/stpeter/manifesto](https://github.com/stpeter/manifesto)

XMPP isn't just for chat, it's for video, server to server message passing, status updates, etc...

</comment><comment><USER28> From the article:

> NSA itself planted it surreptitiously.

> Apple, complicit with the NSA, added it.

Neither seems very likely given how visible the goto is. Something just a little more subtle like a semicolon at the end of the if() clause might look better.

Of course given how glaring it is, it could be a case of plausible deniability: would we do something to stupid, so unsubtle.

<comment><USER29> "A sneaky bug? Only the NSA could have pulled that off! An obvious bug? Only the NSA would be so brazen in trying to throw us off their track!"

 _If the witch had led an evil and improper life, she was guilty; if she had led a good and proper life, this too was a proof, for witches dissemble and try to appear especially virtuous. After the woman was put in prison: if she was afraid, this proved her guilt; if she was not afraid, this proved her guilt, for witches characteristically pretend innocence and wear a bold front. Or on hearing of a denunciation of witchcraft against her, she might seek flight or remain; if she ran, that proved her guilt; if she remained, the devil had detained her so she could not get away._ [1]

If you argue that an obvious bug is evidence of NSA involvement, then you must also believe a subtle bug would be evidence _against_ NSA involvement. You can't have it both ways.

1\. From Conservation of Expected Evidence [http://lesswrong.com/lw/ii/conservation_of_expected_evidence...](http://lesswrong.com/lw/ii/conservation_of_expected_evidence/)

<comment><USER28> > If you argue that an obvious bug is evidence of NSA involvement, then you > must also believe a subtle bug would be evidence against NSA involvement. > You can't have it both ways.

Thanks for taking the argument to a mathematical plane. My reasoning was the following:

P(is-involved) = P(is-involved|subtle)P(subtle) + P(is- involved|subtle)P(~subtle)

Now, we know that 0 < P(is-involved) < 1\. Assuming that there have been past instances of their involvement in both subtle and unsubtle bugs, I think my argument where I can attach a probability of their involvement in both the case was fair. Or do you think I missed something.

Note: I think I got it. Essentially your point is that given that I am using the unsubtle-ty of the bug to argue both ways, implies that this variable provides us no useful information and can be removed from the discussion.

Thanks for pointing out my muddy reasoning.

<comment><USER30> Shouldn't it be

P(is-involved) = P(is-involved|subtle)P(subtle) + P(is- involved|~subtle)P(~subtle)

</comment></comment></comment></comment><comment><USER31> _"Never ascribe to malice that which is adequately explained by incompetence."_

Just for the record and off topic, this is known as the Hanlon's razor. It's usually attributed to Robert J. Hanlon, not Napoleon Bonaparte.

</comment><comment><USER32> While Apple may not have intentionally added this (and I'm a bit skeptical-- you have to shut off unreachable code and indentation systems to let this through), they almost certainly intentionally _LEFT_ this in.

This is such an easy exploit that somebody found it and was using it. There is no way that this was not spotted by Apple in the field.

</comment><comment><USER33> I highly doubt that this particular bug was due to a shadowy government agency or that type of collusion. It's more likely that someone fucked up, it can happen to anyone. You have to look at it from a game-theoretic perspective. Assuming there is collusion between Apple and NSA, it would at least __look__ intentional.

</comment><comment><USER34> I'm so sick of all this conspiracy theory nonsense. If PRISM means Apple supplies data directly to the NSA there's no need for a MITM attack. I mean what's the argument? Plausible deniability?

> Never attribute to malice that which is adequately explained by stupidity.

A programmer screwed up. It happens every day.

I'm reminded of Chesterton's madman:

>The madman's explanation of a thing is always complete, and often in a purely rational sense satisfactory. Or, to speak more strictly, the insane explanation, if not conclusive, is at least unanswerable; this may be observed specially in the two or three commonest kinds of madness. If a man says (for instance) that men have a conspiracy against him, you cannot dispute it except by saying that all the men deny that they are conspirators; which is exactly what conspirators would do. His explanation covers the facts as much as yours. Or if a man says that he is the rightful King of England, it is no complete answer to say that the existing authorities call him mad; for if he were King of England that might be the wisest thing for the existing authorities to do. [...] Nevertheless he is wrong. But if we attempt to trace his error in exact terms, we shall not find it quite so easy as we had supposed. Perhaps the nearest we can get to expressing it is to say this: that his mind moves in a perfect but narrow circle. A small circle is quite as infinite as a large circle; but, though it is quite as infinite, it is not so large. In the same way the insane explanation is quite as complete as the sane one, but it is not so large. [...] If we could express our deepest feelings of protest and appeal against this obsession, I suppose we should say something like this: "Oh, I admit that you have your case and have it by heart, and that many things do fit into other things as you say. I admit that your explanation explains a great deal; but what a great deal it leaves out! Are there no other stories in the world except yours; and are all men busy with your business? Suppose we grant the details; perhaps when the man in the street did not seem to see you it was only his cunning; perhaps when the policeman asked you your name it was only because he knew it already. But how much happier you would be if you only knew that these people cared nothing about you! How much larger your life would be if your self could become smaller in it; if you could really look at other men with common curiosity and pleasure; if you could see them walking as they are in their sunny selfishness and their virile indifference! You would begin to be interested in them, because they were not interested in you. You would break out of this tiny and tawdry theatre in which your own little plot is always being played, and you would find yourself under a freer sky, in a street full of splendid strangers"

<comment><USER35> So you're still deriding ideas like this as "conspiracy theory nonsense," even after extensive documentation that the NSA is, in fact, surreptitiously introducing security holes in software?

Personally I've adjusted my Bayesian priors a bit.

<comment><USER34> Extensive documentation does not exist. It's all conjecture and speculation.

We know the NSA spies on foreigners, we know they have relationships with tech companies to make that spying easier and therefore have access to all that information. We don't the extent of domestic use. We know they collect phone metadata. We know they have infiltrated software abroad, they deny having done it domestically. There's just a whole lot we don't know.

Here's something I do know: the government is not infallible. In fact, just the opposite. Sure Snowden revealed a lot about the NSA spying programs, but he also revealed another salient fact: their background check process was a joke. Like every other government agency they display an incredible degree of incompetence.

Sleeper agents at Apple inserting bugs into code in order to bypass security checks as part of some grand scheme to infiltrate the communications of millions of Americans... it's not even a good idea on the face of it, but even if they tried to pull this off they'd screw it up somewhere along the way. Human beings make mistakes. You guys are giving way too much credit to the NSA.

</comment></comment></comment><comment><USER36> This just remind me of the slides from the NSA operation ORCHESTRA: Annual Status Report in FOSDEM, Brussels, this year - see video here: [http://t.co/8WSSjOFrLk](http://t.co/8WSSjOFrLk)

</comment><comment><USER37> No fix for iOS 6.x on devices capable of iOS 7 either. So now I have the choice of no SSL or destroying my phone's UX by upgrading to iOS 7.x :-(

</comment><comment><USER3> Another explanation is that it was an act of vandalism / code graffiti by a script kiddy or perhaps a real hacker with more skill than maturity.

<comment><USER38> Could you explain how that's a plausible explanation? I don't see this being the kind of thing a vandal would do.

Is external (hacker/SK) influence even possible? I know Apple releases the source, but do they actually take patches from the community?

</comment></comment><comment><USER39> So is there evidence yet of this out in the wild? And was it discovered by Apple or an independent researcher?

</comment><comment><USER40> And this is why you should always put curly braces around your if statement body.</comment>


Show HN: Interactive Abstract Syntax Tree Demonstration - <AUTHOR> https://martijnbrekelmans.com/gifs/constructor-ast.mp4 <comment><AUTHOR> # ... Interactive Abstract Syntax Trees? What?!

As you may or may not know, compilers and interpreters "read" source-code by first turning it into a data-structure called an "Abstract Syntax Tree".

## What am I looking at then?

I made a plugin for Sublime Text that renders this tree as a, real, interactive, well... tree! You can use the mouse to zoom in and out, pan the tree around, rotate the branches, and double click to use the selected branch as the new root for the tree.

The video is a short demonstration of this plugin, and shows a short interaction with the tree (with some tree-dancing halfway through!)

## Oh-my-god, why?!

Good question!

I'm still thinking about how I want to extend this concept to make it useful; ie, as an interactive map of your programs, similar to the "minimap" concept of Sublime Text, except 2d, and enriched with more information and data about your program.

Right now, it's just a proof-of-concept, and it looks pretty cool already! So I thought I'd share it here.

## Future

The somewhat longer-term goal is to extend this interactive vizualisation concept with recorded data about your project

I'm already working on tools that capture runtime information, ie, I wrote a tool that stores parsed PHP profile and trace files in a local sqlite db.

With recorded runtime data, it will become feasible to enrich the visualisation : "15 exceptions happened at this branch", "this branch is very slow", "this branch never got executed in the past month".</comment>


Ask HN: Is the OS stack a factor when developing deployable apps? - <AUTHOR>

For my next project I plan to develop a web service that is aimed soley at the enterprise.
While I'll also offer a SaaS option, I think most companies will prefer to install on their own servers. I was wondering for this scenario, if I should stick with .net/Java or installing configuring PHP/Ruby/Python is an OK requirement.
I'm well familiar with ASP.net and RoR but was leaning on RoR for this project (as my day job is .net and wanted a change) but I have that nagging voice in the back of my head saying most companies won't bother installing/configuring RoR to use my product. Any experiences? <comment><USER2> Hmmm - very scant on the details but overall I'd say yes, it's a factor. Like you said, if you deploy on RoR and I don't have it, I'm not likely to buy/use you because it means adding some "system" that I don't know into the mix.

That being said, here's an example of a company who has taken such a problem (Apache on Windows) and completely hidden it from the end user (or at least made it not a big deal): <http://www.visualsvn.com/server/>

Any .NET developer can now share SVN repositories without the fuss of installing and configuring Apache.

</comment><comment><USER3> Bigger companies often have a policy allowing only certain languages. For example I think Google only allows C/C++, Java Python and Javascript (source: <http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html> )</comment>


Using GNU parallel (YouTube tutorials) - <AUTHOR> http://www.youtube.com/playlist?list=PL284C9FF2488BC6D1 <comment><USER2> We've briefly used parallel for an internal tool when the site went "multisite" (i.e. multiple parallel instances that sometimes need to all do the same thing, such as post-deployment tasks).

We currently have a patch to remove it, and instead use regular task backgrounding and the `wait` shell builtin.

The way output is buffered was not particularly conducive to what we wanted to achieve.

<comment><USER3> THE way? It sounds as if GNU Parallel only buffers in one way.

GNU Parallel can handle output in a few ways:

      * --ungroup: With -u output GNU Parallel does not touch the output and output may mix
      * --line-buffer: This buffers a single line from each process.
      * --group: This buffers in files in $TMPDIR. $TMPDIR can point a RAM disk, if you want to buffer in RAM.
      * --sqlworker: This buffers in memory before saving output to an SQL server.

If you are using '&' \+ 'wait', it pretty much has the same effect as `--ungroup`.</comment></comment>


5000 upvotes, hundreds of comments, easy to verify, 100% wrong - <AUTHOR> https://kolemcrae.com/upvotes-comments-wrong/ <comment><USER2> I think framing this as a technology problem, as quite a few folks tend to do, is the wrong approach. There are plenty of nuggets of memetic knowledge that are simply false, but still passed around by word of mouth (or, in some extreme cases, by more systemic methods).

I hope a non-controversial example of this is the idea that vaccines cause autism: patently false, spread through a million different mediums, easy to disprove (if you look in the right places, as recommended in the article), yet still a pervasive thought.

> This is a serious problem that we need to face online - a culture of fact > checking needs to be pushed, even for small things like this.

It needs to happen everywhere, and it's not going to be a technological answer.

<comment><AUTHOR> You're right - this isn't just an online problem though it is likely the Internet speeds it up by a massive amount. A small false fact would be shared in the past and with time become a meme (in the traditional sense) but online it can happen in seconds.</comment></comment>


Ask YC: What's the best way to meet an angel investor? - <AUTHOR>

Hi,
We're a startup based in Palo Alto. We've been working on our project for more than 6 months and now close to a private beta. The problem is, my partner went to a full time job to pay rent, and can only work on the project on weekends. He does all the development and thus our progress was stalled.
I figure if I can get some money (15k~20k) to support him to work on our project for a few months, it would go live pretty soon. A little money would really help a lot.
I wonder if you guys know how to get in touch with a angel investor? We have presentation movie and prototype but can't find someone to pitch.
I've tried:
- Email VCs
- YC winter funding
- http://gobignetwork.com
- Also considering taking a loan.
Thank you,
Leo Lin <comment><USER2> A number of folks have already suggested that you need to be introduced, and that's normally the best way to proceed.

It seems like you can make progress without additional funding, just at a slower rate. Is your partner really committed to the project? Asking an angel to pay development salary for a co-founder may be a difficult sales pitch. It sounds like your partner may have lost faith and is now asking for money. You are much better off to proceed more slowly and not go into debt or waste time on trying to raise funds until you have something that you can sell, so that you can use additional funds to accelerate revenue. That being said there are several pitch events a month in Silicon Valley you can go to and meet Angels and VC's.

<http://www.vctaskforce.com/>

<http://www.sdforum.com/> see Venture Funding SIG

<http://www.svase.org/> see "First Impressions" event; also you might check out the Startup-U events, it's normally a chance to meet a VC or Angel.

<http://www.startupepicenter.com/> runs pitch events (with training) periodically

<http://www.angelsforum.com/> have a monthly pitch event (here an introduction probably helps)

<http://www.sandhillangels.com/> have a monthly event (again an introduction helps)

All of these are either free or a nominal charge. I wouldn't pay any "introduction fees or percentages" and I would not pay any "beauty contest fees" (e.g. Kieretsu forum charge $3-5,000 to present).

Our firm does not help with fund raising, our focus is on early customers and early revenue, but please feel free to contact me if you have additional questions.

Sean Murphy <http://www.skmurphy.com/>

</comment><comment><USER3> 15-20k could be mustered with friends and family, I think. Meebo maxed out credit cards before their A round.

If the angel route is where you want to go, then referral is best. VCs and anges love recommendations from professors, especially if you have a new tech. Try also contacting people you know in startups.

If that doesn't work, go through an angel network to see their process and a screening. A lot of angels are becoming more open to small YC type investments.

</comment><comment><USER4> This post got gscott the money he was asking for... you could try doing the same.

<http://news.ycombinator.com/item?id=73346>

<comment><USER5> Alas the attached .doc no longer exists at that URL - anyone got a copy?

</comment></comment><comment><USER6> >He does all the development and thus our progress was stalled.

My suggestion: Learn to code.

<comment><USER7> We joke about this, but it is deadly serious. My theory on 2 founders:

\- 2 hackers: Work your butts off, keep design simple and do it yourself until you have something functional. Then worry about finding a designer.

\- 1 hacker & 1 designer: One of you will be doing most of the (important) work. Guess which one? Frankly, I don't know how people pull this off. If you can, more power to you.

\- 2 designers: What are you doing here? Go get 2 jobs.

</comment></comment><comment><USER8> The _best_ way to meet an angel investor is to know someone and have them introduce you. That's the _best_ way, although probably not the easiest or most convenient.

I know of several angel investors, but it all depends on what your product is, and who your ideal investor would be. Why don't you send me a message and we'll chat? I'm one of the 3 guest bloggers at Go BIG Network.

</comment><comment><USER3> 15-20k could be mustered with friends and family, I think. Meebo maxed out credit cards before their A round.

If the angel route is where you want to go, then referral is best. VCs and anges love recommendations from professors, especially if you have a new tech. Try also contacting people you know in startups.

If that doesn't work, go through an angel network to see their process and a screening. A lot of angels are becoming more open to small YC type investments.

</comment><comment><USER9> i've heard people having decent luck with the angel forum.

from what i've heard and found myself, the best way is to be introduced to one. if that were going to happen in your case, it probably would have already happened.

a loan is really your only option. get it live, get some people using it, and then angel's will be much easier to come by.

</comment><comment><USER10> 1) Don't take out a loan, especially not one where either of you are personally guaranteeing it. Creditors will drive your company into ruin faster than investors, and you'll be left paying for it.

2) Talk to an accountant to see if there's any extra money you need (e.g. income tax withholding, etc.) to keep things legal.

</comment><comment><USER11> Best is to learn coding. Today or tomorrow you will need to do that to keep your bills in low range.

</comment><comment><AUTHOR> Hi, thanks for the advises. I wish I could code and help my partner. That would be great but I doubt I can become a good coder in a few months. I'm more of a design guy.

@Sean Murphy. Thanks for all the links. It helps a lot.

@jmtame I've sent you a message through GoBigNetwork.

@rakuten How do you contact another member here? Can't find your email on your profile page.

My email is

email@example.com

and our project page is

<http://bookvair.com>

</comment><comment><USER12> I love the people saying learn to code. Not everyone is a programmer, Ok us coders might find it easy but not everyone else does. also not everyone is using ruby and this might have been written in C++ so learning coding ain't going to help anytime soon :p

good luck with it. maybe look for another coder to helpout would be cheaper.

<comment><USER6> Anyone can code.

Anyone.

It is a question of motivation and effort, not intelligence.

<comment><USER12> Did I say that? No I did not and my point still stands and is not me being elitist. To become a good programmer takes time and for this guy to taking over the coding from a programmer when he has no knowledge is gonna take a long time. first he has to learn how to program, then get expereince with the lanuage and then hack someone elses code.

</comment></comment></comment><comment><USER13> <http://www.antiventurecapital.com/vc_approach.html></comment>


Is it possible to prefer typing on an Apple wireless keyboard vs. a mechanical? - <AUTHOR> https://www.quora.com/Is-it-possible-to-prefer-typing-on-an-Apple-wireless-keyboard-vs-a-mechanical-one?share=1 <comment><USER2> Sure, why wouldn't it be possible?

I enjoy both types (having started with mechanicals in the 80s), but usually find the Apple Magic keyboard faster and easier on the hands...</comment>


Bayesian analysis of ego-depletion studies favours null hypothesis - <AUTHOR> http://onlinelibrary.wiley.com/doi/10.1111/bjso.12236/full <comment><USER2> According to marines, will power depletion is bs. This is anecdotal, sure, but I believe in momentum. If you have momentum, at some point, you don't want to fail at any will power task, because you are on a winning streak.

<comment><USER3> Interesting. There is actually a concept from behavior analysis called "behavioral momentum." [1]

1: [https://en.wikipedia.org/wiki/Behavioral_momentum](https://en.wikipedia.org/wiki/Behavioral_momentum)

<comment><USER4> Reminds me of how the hardest part of many tasks is simply getting started.

</comment></comment></comment><comment><USER5> I'll have to look more closely at the paper, but am very surprised by this result! I've always figured the effect sizes were quite small, and there are good researchers who don't buy its main explanations, but the idea of ego depletion shows up in a lot of areas under different names (e.g. "resource depletion in working memory").

Pretty contentious area of research, so I'm sure this will be some nice fuel for the fire..

</comment><comment><USER6> Not disputing the paper or the scientific method applied here, but how is "bayesian factor" different than p-values?

<comment><USER7> In a nutshell: If the p-value is below some conventional threshold (in psychology it's usually 0.05), you can conclude that the null-hypothesis (no effect) is likely wrong and that something else must be the case. However, if p is above the threshold you can't conclude anything, because that means that there is either no effect or that the data was not sufficient to show the effect. So the p-value method (formally known as null-hypothesis significance testing, NHST) can only ever be used to reject the null hypothesis but not to support it. This is where Bayes factors are different. In that approach, you formulate not just one hypothesis but two. Then you test how well both hypotheses are supported by the data. Three conclusions are possible: Hypothesis A receives more support, the alternative hypothesis receives more support, there is not enough evidence to conclude anything with sufficient certainty. Presented this way, the Bayes factor approach appears to be strictly superior to NHST. But there are also some complications that make Bayes factors tricky (related to how you select and formulate the hypotheses) and some statisticians go as far as to say that Bayes factors are obviously non-sense (e.g. Andrew Gelman). The truth is probably that they are neither a panacea nor non-sense.

<comment><USER6> That makes a lot of sense, but can't you model two null hypotheses using the same data in some clever way?

</comment></comment></comment><comment><USER8> It feels like the fact that this is a bayesian-favoured study is some kind of sign that people (i.e. people that are upvoting, not necessarily the researchers) are actually taking that silly bayesian vs frequentist political war thing seriously. (Which I don't think is advisable.)

<comment><USER9> I agree, there is no reason to mention "bayesian" in the title other than using it as a hype term like "blockchain" or "deep learning".

Also, the real difference is whether they test a "null hypothesis" vs testing an "actual hypothesis". Like almost all psych, this falls in the first category.

<comment><USER10> You say this but then you go read a paper with a cruddy t-test and then injure your eyes with the spasmodic rolling that it induces, like I did.

It's kinda remarkable how many people don't actually use modern bayesian analysis techniques, which is why it's such a policy war. It's the difference between "older statistical methods uninformed by the glut of modern processing power" and "things which require a computer to do well, and preserve uncertainty."

<comment><USER5> I don't think it's an issue of old versus new methods. Daniel Lakens has an great string of blog posts / publications on how a lot of the same things can go wrong with Bayesian anaylses [1], and how p-values can be viewed as a "poor man's Bayesian updating function" [2].

[1]: [http://daniellakens.blogspot.com/2017/03/no-p-values-are- not...](http://daniellakens.blogspot.com/2017/03/no-p-values-are-not-to-blame- part-53.html)

[2]: [https://daniellakens.blogspot.com/2015/11/the-relation- betwe...](https://daniellakens.blogspot.com/2015/11/the-relation-between-p- values-and.html)

<comment><USER10> When I do not have a processor easily capable of bayesian mkmv sampling I'll consider using that method.

But I do and I guess this means I am rich? Sure.

</comment></comment></comment></comment></comment><comment><USER11> I always get the feeling from reading academic material on psychology that people are trying to apply the scientific method on top of unscientific principles. It feels rather like alchemists trying to explain fire via phlogiston: an attempt to quantify high-level phenomena when you don't understand any of the lower levels.

All the data comes from psychology students at a college in the US who either were able to use their participation for a course requirement or given extra credit. The method by which they generated and measured depletion seems adequate, but all the data is self reported based on how the test subjects felt.

The statistics gives evidence linking the amount of generated depletion and the reported depletion, but not any insight into what mechanism actually causes depletion. What use is this? Why build a map when we cannot effectively observe the territory?

<comment><USER12> It might not seem as clear cut as other natural sciences (which also get fuzzy once you go into the details) but there is credibility in psychological reasoning. The mechanisms that cause a certain behavior are represented as models in psychological research. Such models must, by design, simplify the real mechanisms. But, as opposed to the real mechanism, they can be discussed and disproven, which is what apparently happened here.

<comment><USER11> > _It might not seem as clear cut as other natural sciences (which also get > fuzzy once you go into the details) but there is credibility in > psychological reasoning._

Any "fuzziness" in the other natural sciences (thinking biology, chemistry, physics, astronomy, etc.) is usually limited by current technology or measurement methods. Newton's classical mechanics were observably true for a long time before their flaws started showing. In most situations, classical mechanics is all you need to accurately model a system. Is there any such well accepted theory that semi-accurately predicts psychological phenomena in a similar fashion?

I agree that sometimes psychological findings seem credible because they align with our personal models of how we think people work, but this gives you nothing in terms of the scientific method. Just because a model is intuitive doesn't mean that it is any more true.

> _Such models must, by design, simplify the real mechanisms._

What model? They essentially have a single claim backed by evidence. I don't see what predictive power their conclusion brings. We don't understand what "ego-depletion" is, how can we pretend to measure it? How can this "measurement" of something that we don't understand give us any more information about human psychology?

What real mechanism have they suggested as an explanation for this phenomenon? I didn't see one.

</comment></comment></comment><comment><USER13> ELI5?

<comment><USER11> Basically, there was a theory that exercising self-control would "deplete" ones "self-control reserves". The idea was that exercising your self-control, to say avoid a junk food, would temporarily decrease your ability to resist that temptation again.

This paper reports that not only were they unable to verify any of the prior research into this so called "ego depletion" effect, but they found more persuasive evidence suggesting that the theory is false.

<comment><USER14> This is reassuring. Every time someone told me this I figured it had to be bullshit. I think people used it as an excuse to make bad decisions.

<comment><USER15> ...and you're exemplifying confirmation bias right there, which is the whole reason this happened in the first place.

<comment><USER16> Having an opinion that is later vindicated is not the same thing as confirmation bias.

</comment></comment></comment></comment></comment><comment><USER17> It's disappointing to see links to the abstracts on the front page of HN (given the paper itself is behind a paywall).

In this case, the find some non-zero effect, but call it zero because the difference was not statistically significant.

That's likely a reflection of their small sample size rather than evidence for the null hypothesis as the title suggests.

But it's hard to know, or even have an intelligent discussion about it, since the paper itself is behind a paywall.

<comment> shaki-dora Sample size is, of course, one of the factors included in any analysis that gives you a p-value, or any other measure of confidence.

In this case, the abstract specifically mentions a "Bayes factor > 25". The Bayes Factor is the likelihood, i. e. the ratio of probabilities for two competing hypotheses. With no information whatsoever, it is 1. A factor of 25 means that the null hypothesis is 25 times as likely to be correct as the theory of ego depletion.

</comment></comment><comment><USER18> I'm all for replication and ensuring scientific accuracy - but this does not change my perspective of ego-depletion.

I have observed it in myself, time and time again. If not it directly, something similar enough. Even at a glucose level, various studies have shown relation between our blood sugar and ability to tolerate frustration and make decisions.

So while the accuracy of ego-depletion may be in question, I can still benefit from reasoning it to be true and challenging my emotions and expectations with that. if/when a better model or perspective comes around i'll surely adopt it.

But of course, if this news in some way helpful or freeing for you, by all means ride that wave. Success matters more than truth.

I've observed that psychology will sometimes split hairs - arguing over whats true and whats truer. Overall this is good - but it's helpful to consider the proliferation of blatant non-truths out there and how far we've come. Sometimes "good enough" is good enough. Fill in the blanks with the facts you can find today and be willing to swap them out for better ones tomorrow.

<comment><USER19> >Even at a glucose level, various studies have shown relation between our blood sugar and ability to tolerate frustration and make decisions.

I think it is exactly these kinds of studies that are being questioned. Can they be reproduced?

<comment><USER20> Stay hungry (e.g. On low calorie diet) for few days and then watch yourself more nerveus and making dumber decisions.

<comment><USER21> I fasted for few days on many occasions. The only ill effect was that it was difficult to fall asleep and the sleep was very shallow on second and third night. After that sleep got better. I have not noticed any dumbness. Subjectively perception even improves. This is in line with experience I read in books and articles.

Sometime I use that if I need to drive a long way. I stop eating the day before that ensures that I never fall asleep behind the wheel and my attention stays sharp all the time.</comment></comment></comment></comment>


Lyft Announces Q1 Earnings - <AUTHOR> https://investor.lyft.com/news-releases/news-release-details/lyft-announces-record-first-quarter-results <comment><USER2> Stunning.

Lyft is valued at $17bn on $776M revenue. Expenses for this revenue...

Cost of revenue: $462M Operations: $187M S&M: $275M Administrative: $376M

Total expenses: $1.3bn, i.e. 167% of revenue.

This is not a healthy company.

Uber's breakdown for quarter-ended March 31 isn't out yet. But looking at Dec 31 figures:

Revenue: $3.0bn Cost of revenue: $1.6bn Operations: $408M S&M: $974M Administrative: $555M

Total expenses: $3.53bn, i.e. 118% of revenue.

(note: the above excludes R&D and interest, depreciation, amortization expenses)

<comment><USER3> This tweet demonstrates a lack of basic finance knowledge. Stock prices are based on ==future== cash flows, not past. It's already a huge company still growing very fast and printing money on core product (non-pool rides in mature markets)(even overall contribution margin was a whopping 50%! And growing!).

<comment><USER4> Stock prices are based on the present value of future profits, so pointing out that Lyft is unlikely to be profitable for a long time is spot-on.

<comment><USER3> It could be massively profitable tomorrow.

<comment><USER5> For values of "could" that include "definitely will not be."

<comment><USER3> "Tomorrow" was facetious, I apologize. But based on existing 50% contribution margins it's quite clear it could achieve earnings in the near term.

But of course with such contribution margins and growth rates it would be silly to hang on to cash.

</comment></comment></comment></comment></comment></comment><comment><USER6> The net loss that they are running against revenue is staggering. It is also telling that they bury that in the text and don't move it to the summary infographic. What does a profitable Lyft/Uber look like? We haven't seen it yet.

This also proves a bit of the lie that the drivers are getting screwed out of earnings. The company as a whole isn't profitable and those drivers should be carefully considering their future when, not if, the market losses patience over these losses.

<comment><USER7> This is literally the top comment on every recently IPO'd companies earnings. "Why are they spending so much money, why aren't they profitable yet." It's like HN doesn't understand the purpose of going public is to raise money, and the reason you raise money is because you see growth opportunities that are worth spending money on instead of returning profits to investors.

<comment><USER8> "It's like HN doesn't understand of raising money on an existing valueless proposition!"

No seriously, I don't understand. Explain to me. I grew up in and around small businesses, I legit don't understand how this bulls __* flies. It 's all being propped up for god knows what reason, and ultimately your average citizen is going to have to pay for it when it all comes crashing down, like always. I don't care if a group of "visionary VCs" "see value" in it. We've replaced a sustainable industry (taxis) with Uber and Lyft, which only were able to because they were able to skirt by regulation, and now if and when they vanish because again, they have proven to be unable to _actually make profit to date_ , we will now have a crumbled public transit mode left to rebuild. Irrational investments that negatively affect the public should be faced with this intense scrutiny.

I am honestly obviously ignorant to whatever is going on here, so I am allowing myself to be educated here.

<comment> cljs-js-eval As someone who did not have a car for the better part of a decade, living in one city known for a good taxi system and one without a good taxi system:

"sustainable industry" is not the term I would use to describe taxis. Their dispatch systems __badly __needed replacing.

Things I saw in taxis pre-uber:

\- Calling a dispatcher and giving an intersection, to receive a "we don't pick up at intersections, you need a valid street address" message. This was in the city without a lot of taxis. Gee, wonder why.

\- Drivers speeding off once they realized you didn't mean to go to the airport.

\- Drivers intentionally using both feet to drive, so they would stay well below the speed limit. If confronted, it was in the name of "safety". Dispatchers couldn't track locations so they had no idea how long the trip should take, and weren't interested in you as a repeat customer enough to do anything to the driver.

\- Multiple broken card readers.

\- Generally, it was impossible to understand dispatchers. Almost every one I talked to had a thick accent beyond what I would expect from even a newer first-generation immigrant.

<comment><USER9> sure, taxis were horrible _and_ expensive. however, they made enough money to sustain themselves with their high prices, low margins, and crummy service. I guess the question is, what would Uber/Lyft have to charge to break even? 10% more? 50% more? What would they have to charge to justify their share price? Do they make sense as businesses?

<comment> cljs-js-eval Given the strides they've made in automated dispatching and the increased demand for taxis that has come about as a response, I'm guessing the model makes sense at a higher price than they currently charge.

I was literally the model customer for taxis. No car, disposable income, goes out drinking a lot. Even so, I actively avoided taxis whenever I could before uber hopped on the scene. It wasn't a question of money - their dispatch services actively left money on the table with their terrible, terrible quality.

Whether Uber/Lyft took out too much money remains to be seen. But the dispatching technology is an immensely profitable business by itself.

</comment></comment></comment></comment></comment></comment><comment><USER10> Lyft's reply re: profitability from the conference call:

 _" We anticipate 2019 will be our peak loss year as we then move steadily towards profitably on a consolidated basis," CFO Brian Roberts said..._

[https://www.businessinsider.com/lyft-cfo-says-2019-will- be-p...](https://www.businessinsider.com/lyft-cfo-says-2019-will-be-peak- financial-loss-year-2019-5)

</comment><comment><USER11> > For FY 2019, we anticipate:

> Total revenue to be between $3.275 billion and $3.3 billion

> Adjusted EBITDA loss to be between $1.15 billion and $1.175 billion

What's the size of their war chest? At $1+B/year of net loss this party can't continue forever.

</comment><comment><USER12> I just recently used Lyft while visiting Atlanta. I'd never used Lyft or Uber before. The app and service were both fantastic. I hope they keep it up. Awesome service at a reasonable price.

<comment><USER13> It is cheap because they are loosing money. (Trying to capture the market or something.) Let's wait until they are profitable to see the real price.

<comment><USER12> I did not mean to imply it was cheap, only reasonable. I would have paid more. Nice cars, polite drivers and quick service.

</comment></comment></comment><comment><USER14> This isn't completely on topic but ...

I wonder what happens to a company's culture once the employees see the stock absolutely tanking. The probably aren't fully vested, and so are just watching their payday shrink and shrink.

<comment><USER15> Even if they are vested, they are almost certainly subject to a 180 day "lockup" period where they can't sell for that long post-IPO.

</comment></comment><comment><USER16> > Lyft reported Q1 revenue of $776.0 million versus $397.2 million in the > first quarter of 2018, an increase of 95 percent year-over-year.

95% growth year-over-year? On first reading this sounds incredible. But then on the other hand, if they still had 100% growth left in them, why couldn't they raise another round of funding?

One theory is that they held back some revenue from their IPO documents to show a spurt. So, I really want to see their 10-Q to understand what really is happening here.

<comment><USER17> > why couldn't they raise another round of funding?

Isn't an IPO just that? A better round of funding that also provides liquidity to shareholders?

<comment><USER16> It depends.

If the company uses the proceeds for operations of the company it is another rounding of funding.

There are times when the company IPOs specifically to provide exit to the existing shareholder and not adding any money to operations.

That being said, public offerings get slightly restrictive on how the company can raise future capital.

If Lyft can still grow nearly 100% then I am sure they could have found a VC willing to fund them. And they could have gone public at say 30-50% growth rate.

</comment></comment></comment><comment><USER18> If that R&D doesn't pan out they essentially will go bankrupt quickly as their R&D spending was 81% of their revenue.

<comment><USER19> Why couldn't they issue bonds and get access to cheap debt like Netflix or Tesla?

<comment><USER20> Uber issued bonds: [https://www.bloomberg.com/news/articles/2018-10-16/uber- is-s...](https://www.bloomberg.com/news/articles/2018-10-16/uber-is-said-to- boost-bond-sale-to-2-billion-as-orders-swell)

Rated by Moody's as B3 and by S&P as B-, which is the bottom of "Highly speculative": [https://en.wikipedia.org/wiki/Bond_credit_rating#Credit_rati...](https://en.wikipedia.org/wiki/Bond_credit_rating#Credit_rating_tiers)

For comparison, Uber bonds are one grade lower than Argentinian bonds: [https://tradingeconomics.com/argentina/rating](https://tradingeconomics.com/argentina/rating)

Such credit ain't cheap, especially now that interest rates are no longer zero.

<comment><USER21> They sold $2billion in 8 year bonds at 8% yield. i think their cost of capital will go down now that their contribution margin is positive (9%)

</comment></comment></comment></comment><comment><USER21> Contribution margin is 50%. With fixed costs around $3billion / year. They need to double revenue to $6 billion to get to profitability.

Edit: By comparison Uber's contribution margin is only 9%. With fixed costs around 4 billion , it can probably get to profitability by increasing contribution margin to 40% with the same revenue, or by growing revenue 3x. Probably both contribution margin and revenue will go up 3x eventually.

</comment><comment> trevor-e Are developers in San Francisco really worth the cost? According to Paysa data on Lyft the average Software Engineer makes 263k and the average Senior Software Engineer makes 354k (I believe these numbers are total comp). If I'm reading the earnings correctly then $506,206,000 of stock compensation is going towards R&D. Unless you are hiring someone into a highly specialized role I don't see how these numbers make sense. Are these developers really worth multiples of developers in other cities?

[https://www.paysa.com/salaries/lyft](https://www.paysa.com/salaries/lyft)

</comment><comment><USER5> After hours investors don't seem particularly spooked, they're down about 3% as of this writing.

<comment><USER5> (Though now they're down 6% during the day, so that's more material.)

</comment></comment><comment><USER22> Would they be profitable if they fired all of their engineers and just let the already working product keep working? I mean...it works. It already works. It does everything that it's supposed to do. Millions of people use it happily. Could they just ride it into money?

<comment><USER23> This strikes me as odd also for Uber. I mean I get that they are a large high- tech company, but I don't get how they are developing huge js frameworks and similar. They are a taxi company. Don't they basically just need a reasonably simple web app, a mobile app and some infrastructure that runs on a (relatively) small AWS bill? Why is Uber and Lyft trying to reinvent the web? Is it to attract talent, because good talent really wants to develop cutting edge stuff? That's an argument I can understand. But how can Uber have 2000 developers who make 1000 microservices?

</comment></comment><comment><USER24> Lots of millionaires being minted. Congrats to the early engineers.

</comment><comment><USER25> Wow, this company is burning cash in a bonfire as fast as they can get it.</comment>


Five whys: The startup immune system, Part 1 - <AUTHOR> http://venturehacks.com/articles/five-whys

<comment><USER2> A few years ago I worked for a smallish company where the repeated "why?" would consistently release untold nightmares. The turnover rate was high, but there were a few old-timers who would tolerate a historical/political inquiry, and a few more whose reactions revealed things about history and politics in a different sort of way. At a glance, the product designs and manufacturing procedures appeared to have been born from pure ether. (This company made medical devices.) Design decisions were undocumented; what documentation did exist was _withheld_ out of general mistrust.

Problem: Applying the drug to the latest version of the device in the usual way gives a messy coating.

\- _Why is the coating messy on this design?_ Because the device's surface can't hold this much drug.

\- _Why are we applying so much drug?_ Because the previous products used the same dosage.

\- _Why was that dosage chosen?_ Because, in an animal study using sample size N=1-3 for each of three different dosages, this did slightly better than the other two. No further investigation was ever done. EOF

\- _Why can't this device cleanly carry as much drug as previous designs?_ Because the surface properties and geometries are different.

\- _Why did we change the design? What properties did the other design have that resulted in a clean coating?_ Because a partner company wanted out of the biz, created a durability test no existing product could pass, and used that to torpedo our product. And, wait, that design had a problem with the coating, too.

\- _Why didn't we catch these coating problems in previous products?_ Because quality is fucked in this pilot facility, and our other manufacturing facility is still trying to get up to speed with the first product made with this manufacturing method, and unable to duplicate our allegedly flawless results from two years ago.

\- _Why are we unable/unwilling to do serious QC work here? Or even basic science?_ We think the CEO doesn't intend to pass regulatory requirements or even launch most of these newer products, so it doesn't matter. These projects are window-dressing for investors. Yes, _of course_ we're all looking for new jobs on the side.

As it turned out, the real benefit to asking all of these whys was that I was able to abandon ship at just the right time. Shortly before I left for another job, having challenged the CTO about the scientific feasibility of his latest escapade during a meeting, a senior engineer showed me some years-old pictures of a device with exactly the same physical design as our flagship product. This young engineer was enlightened.

</comment><comment><USER3> This is great advice and can be used everywhere.

Beware that if you work for BigCorp this will make you unpopular.

<comment><USER4> The statement "Because that's the way it is" springs to mind.

<comment><USER5> When I worked for a larger company, I had the rare pleasure of working with someone who was at once brilliant and patient (something he actively cultivated.) When trying to get to the bottom of things, I usually was granted a purview into the historical technical and political _history_. While this was illuminating for a while, eventually it boiled down to: lack of approval to pay off technical debt -- the compromise was made knowingly and was the best decision at the time. Of course, this was something I thought to be true, but only really learned it after coming to the same conclusion time and time again.

<comment><USER6> I've had the benefit of similar illumination where I'm employed, although without the same level of patience. The same explanation was given time and again there, too; incurred technical debt due to prudence. They were small, and thus didn't have the financial wherewithal to afford a long term outage should some of that debt sudden become subject to a margin call, and so I dug deeper. And from that the true reason came out of why things had gone off the rails so bad. The political history of the company had been one where ego and authority ruled. The technical debt would not be repaid, because it would be an admission that the incurring of such debt was not _inevitable_. It would be a sign that one or more wrong decisions was made. And, due to the history of authority rule, no one would dare question the decisions, assuming both that the management was approaching the situation with full information and rationality, and any one else should assume to have neither. From what I've gathered, I'm not so alone in the universe with these experiences. But when the term "political history" comes out to explain something, I'll generally start reaching for my fine tooth comb, to better understand who it matters to and why.

<comment><USER7> What exactly is meant by incurred technical debt? How do you have "margin calls" on technical debt? Totally confused.

<comment><USER8> I agree with pmjordan's answer, but thought I'd add an example: Your company's product log messages of some kind into a database. The developers were lazy, and put everything in one table with the classic "key, value" SQL antipattern. Subsequently, it was discovered that values weren't enough, you sometimes needed arrays of values (or hashes of values, or ...), so a (probably crappy) serialization format was written for the values so they could be arrays.

Suppose now you were hired in to this position and you actually do a lot about databases. Now, your company gets a call one day from your biggest customer that while they've been putting up with your product getting slower and slower over time (without telling you of course), it's finally gotten to the point where "queries take over an hour and we really need them in less than 5 minutes"/"our daily reporting process now requires more than a day to complete" (which means the system clogs up with nothing but reporting processes, eventually)/"we've been sued and the court has mandated that we turn over some data by next week and we compute it'll take two months"/"the CEO just tried a query that took an hour and now he wants to cancel the contract"... or so on, you get the idea.

This critical problem comes back down to you, and you realize that the only way to fix it is to entirely restructure the databases using better practices. Conceptually, this is trivial. However, since _every single part_ of the system is built around this data system (and of course, there's no abstraction, everything uses the key/value store directly), the combination of the amount of time it would take to write the new schema, modify every program file in source control to use this new schema, write the migration script, and potentially even the time to run the migration script for the customer (during which time they will be off-line, which could be days, and which could be anything from unacceptable to impossible), oh, and testing, don't forget testing, could in fact be longer than your company can survive with a pissed- off major customer.

And if one customer is pissy now, it means every single other customer you have is a ticking time bomb.

(Everything in this message comes from things I've seen more than once in my professional career, except the hypothetical about getting sued (thank goodness). I'm not providing details because there are thousands of companies that could fill in the above!)

Your technical debt margin just got called. You couldn't cover it. It wasn't even your technical debt, but who cares? Buh-bye!

<comment><USER3> You just described my current day job. lol.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Looking forward to more.</comment>