The Oatmeal's lawyer responds to FunnyJunk - <AUTHOR> http://www.scribd.com/doc/96850920/FunnyJunk-The-Oatmeal-Response <comment><USER2> This is an absolute domination. Not only is it far more thorough than Carreon's original statement and quite clearly dismantles every single point he makes, but it's a very reasonable and human-readable letter that contains a number of well informed possible outcomes and suggestions for courses of action that funnyjunk can take.

Honestly at this point the best think funnyjunk can do is publish an apology. This whole issue has been extremely public and has not only completely ruined funnyjunk's reputation (if they ever had one), but also made Carreon (who seemed previously to be a relatively respected lawyer) look like an absolute idiot and a scumbag for his frankly stupid and uninformed research and attempts to take down a charity initiative.

Sometimes you have to realize that you have been absolutely dominated and just drop your pride and give in before it gets any worse. This is one of those situations.

<comment><USER3> I've worked w/Venkat before. He's always this good... He's the kind of lawyer, like grellas and Douglas Choi at <http://tangolaw.com> that makes you excited about the artful practice of law. When done well, responses like this are like a perfect movie review - so well crafted that the review itself becomes art.

<comment><USER4> "He's always this good... ...When done well, responses like this are like a perfect movie review"

How is his win record or success with settling or preventing lawsuits? In the end isn't that the thing that matters? (I ask the question regardless of the outcome of this particular event).

<comment><USER3> i think of three skills of a good lawyer (at least the skills i value):

a) skill at writing clear, concise contracts.

b) skill at understanding acceptable tradeoffs - do we really need to spend extra legal time on X? what are the consequences if we do or don't?

c) skill at responding to and diffusing adversarial situations like this

</comment></comment></comment></comment><comment><USER5> I know it's not in the fun tone of these particular proceedings, but consider that this exchange illustrates a problem that does exist on the Internet: the DMCA, as it exists today, seems to create asymmetric incentives for the infringement vs. protection of copyrighted content.

The collection of copyrighted content from around the web can be "outsourced" to the users of a site like FunnyJunk or (as the letter points out) YouTube. The content is then hosted and advertising run next to it, generating revenue for the hosting company.

This basically allows companies to leverage the fans of content against the creators of that content. People upload The Oatmeal comics to FunnyJunk because they like the comics! But by doing so they are enabling the redirection of financial gain from The Oatmeal to FunnyJunk.

To fix this redirection, the owner or controller of the copyright must then file DMCA requests for each individual instance of infringement at each individual website. It's an impossible task, as The Oatmeal has pointed out repeatedly. And I don't know of any way to crowdsource it--to incent The Oatmeal fans to do it for The Oatmeal.

We're all cheering for The Oatmeal now, but tell the same story with The Pirate Bay and Sony Music, or YouTube and Viacom, and would the comments below be of the same tenor? I would guess probably not. But the structural issue is exactly the same.

I'm not advocating for any particular solution, just trying to draw parallels.

<comment><USER6> It is too easy to characterize the issue as creators vs distributors. There is something oddly different about the case at hand.

Pirate Bay/Youtube vs Sony/Viacom have one thing in common: content creator doesn't understand new means of distributions, gets angry, sues the platform, pisses the internet off.

The Oatmeal acted differently. When he got angry at the new means of distributions, he didn't sue, he didn't even threaten to do it. He accepted the situation, made a funny/angry comment about it (where he didn't lie nor even exaggerate the situation), and went back to his comic drawing business. Is it unfair? probably. But his "moving-on" attitude draws respect.

We're all cheering for The Oatmeal because he didn't attack, he got attacked. The internet is generally favorable for artists who don't make a big deal out of freely copying their work. Once they get attacked, at least, the internet always got their back (and as the IndieGoGo campaign showed, those _freeloaders_ are more than willing to spend the big bucks to protect their proteges).

</comment></comment><comment><USER7> This is amazingly and impressively thorough. He cites relevant caselaw left and right; the two that particularly struck me were:

\- "FunnyJunk also alleges The Oatmeal's statements constitute false advertising under the Lanham Act. However, the statements made by The Oatmeal do not constitute commercial advertising or promotion, and therefore section 1125(a)(1)(B) of the Lanham Act is inapplicable."

\- "Even assuming that all of the content on FunnyJunk is uploaded by users and FunnyJunk otherwise qualifies for DMCA immunity, it's possible that The Oatmeal may be able to satisfy the "red flag" exception for DMCA immunity. See Viacom Int'l, Inc. v. YouTube, Inc., 676 F.3d 19, 41 (2d Cir. 2012) (discussing "red flag" test and reversing grant of summary judgment in favor of YouTube). It is also possible that FunnyJunk hasn't complied with the requirements of the DMCA and thus cannot take advantage of its protections. Among other things, the DMCA requires a service provider to designate an agent, provide contact information, and file a notice of designation with the Copyright Office. Without taking a position on the other issues, I'll note simply that FunnyJunk does not appear to have a notice of designation on file with the Copyright Office. This alone would be enough to undermine anydefense of immunity to claims of infringement that The Oatmeal (or third parties) may assert."

Great lawyer.

<comment><AUTHOR> Another interesting point is that the Oatmeal started a reddit-like site called <http://bearfood.com> 25 days ago.

I wonder if that could make him be considered a "competitor" to FunnyJunk in the eyes of the law.

<comment><USER8> I don't see the connection between defamation and competition. Would it change the nature of the lawsuit if he were a competitor?

<comment><USER9> It might make it easier to prove there is malicious intent. If I'm in a completely separate business and I make a remark about your business practices, one can see it as an outsider making a (negative) observation if the language is only mildly disparaging. If I'm in the same business as you, it might come off as more of an attempt at me undermining you or trying to gain some benefit.

Ultimately it probably doesn't make much difference, in that defamation is usually difficult to prove anyway, but the context could sway things a bit.

<comment><USER10> It doesn't look like <http://bearfood.com> has advertisements so he isn't looking to make money on it. That's not to say that ads won't show up at a later date though.

</comment></comment></comment></comment></comment><comment><USER11> So let's say Funnyjunk stops threatening and decides not to sue. What have they lost?

* Legal fees for sending a couple of threating letters.

What have they gained?

* A full-page spread in The Oatmeal advertising the fact to all readers of Slashdot, HN, and many other social media sites that Funnyjunk exists, carries user-submitted comics such as would be interesting to readers of The Oatmeal, and are friendlier to content submitters than they are to the DMCA.

* Massive SEO links. Four out of the first six search results for "the oatmeal" from DDG refer to Funnyjunk. Funnyjunk has an entire section on [http://en.wikipedia.org/wiki/The_Oatmeal#FunnyJunk_legal_dis...](http://en.wikipedia.org/wiki/The_Oatmeal#FunnyJunk_legal_dispute) and an entire article dedicated to the dispute.

Now most of us want to believe "But this is negative publicity and Funnyjunk couldn't possibly want that". But before you conclude that, consider how little people are going to remember about this incident in just a few weeks. For example, do you remember even today the name of the Funnyjunk CEO or of his lawyer? I don't, but I remember Funnyjunk whereas I had never heard of it at all before. I've even been to their site several times now (following up on links posted at The Oatmeal).

I hate to say it, but this was brilliant and The Oatmeal fell for it.

<comment><USER12> * FJ is a site that's been around for years and has had a steady falloff of users and who's popularity has been waning since 2006. This looks to me like an act of desperation, not a brilliant gorilla marketing tactic.

* Threatening a lawsuit against The Oatmeal, who in turn responds with charity and humor does not make FJ seem cool.

* DDG is obviously returning some pretty bad relevance, considering a search for "the oatmeal" on Google doesn't return a single reference to FJ except in the News section talking about what huge dicks they are. This is not positive SEO. Also, when I search DDG in an empty session, I only get 2/6, not 4/6, so either they've already fixed this oversight or you're getting some unique results because of your history.

* FJ does not get DMCA protections. As pointed out in the above letter, they don't have a DMCA agent on file, which means that even though Inman isn't going to go after them, as a result of this bogus legal threat against him, they've just painted a big bullseye on themselves. Anyone who feels like they want to pile on and get some free money out of FJ can now point to their works being online and sue. Someone less courteous could extract up to $150,000 per infringement, especially since there is clearly commercial intent behind this "unauthorized sharing".

I hate to say it, but you've completely read this situation wrong, and if anything, The Oatmeal has come out with vastly more positive press from this than FJ ever will.

<comment><USER13> > brilliant gorilla marketing tactic

Best homophone mistake ever.

</comment></comment></comment><comment><USER14> I love the summary:

"At the end of the day, a lawsuit against The Oatmeal in this situation is just a really bad idea"

Never has a lawyer summarised a situation so clearly and succinctly.

<comment><USER15> Clearer, and more succint: _A lawsuit based on these claims would have no merit._

Problems with the summation statement quoted: "At the end of the day" is superfluous and pedantic. "In this situation" is ambiguous and suggests that the statement only applies in the limited context of the facts raised in the letter, i.e., ignoring other potential facts which were not raised in the letter. "just" is superfluous, pedantic, and unprofessional. "a really bad idea" is superfluous, pedantic, and unprofessional. It is a really bad idea to use "a really bad idea" in a legal letter written to another lawyer.

<comment><USER14> It's bigger than having no merit as a lawsuit.

The reason I like the phrase is that it encapsulates the fact that this is wrong legally, from a PR perspective, morally and that there's much to lose and little to gain.

</comment></comment></comment><comment><USER16> The Oatmeal's lawyer, Venkat Balasubramani [1], is a regular contributor to Santa Clara law professor Eric Goldman's Technology & Marketing Law blog [2].

[1] <https://twitter.com/#!/VBalasubramani>

[2] <http://blog.ericgoldman.org/>

</comment><comment><USER17> Smart people have at times succumbed to the foolishness of representing themselves in court. This reply should be a testament to the invaluable help a great lawyer can be in making one's case (if it weren't obvious already).

<comment><USER18> > Smart people have at times succumbed to the foolishness of representing > themselves in court.

Ermmm. TheOatmeal isn't representing himself.

> This reply should be a testament to the invaluable help a great lawyer can > be in making one's case (if it weren't obvious already).

How is this reply a testament to anything? You talk like TheOatmeal has lost the court case.

<comment><USER17> On the contrary, I'm saying that The Oatmeal was smart in deciding to hire a great lawyer. My comment was however more general than the specific case. As a smart person who is very competent in a given field, it's easy to fall prey of a cognitive bias which leads one to believe that you "know better" even within fields in which you lack the proper training and expertise. This is a testament, not because The Oatmeal made a foolish choice (he made a great choice), but rather because anyone reading the letter can appreciate the value and expertise brought in by such a competent lawyer.

</comment></comment></comment><comment><USER19> Personally speaking, I don't think it's necessary to send a letter of this length to rebut what is a spurious claim by FJ. The Oatmeal's lawyer has analysed the case well and is aware of its flawed nature, but this didn't need to be stated in the letter, as it would have sufficed to relay his analysis to OM.

I am fairly confident FJ's lawyer is aware of the flaws in his case and although an easy target, he is likely to be aware of relevant case law.

The point is that FJ's lawyer's letter was more akin to a shakedown used to obtain leverage, rather than a legitimate letter before claim detailing the full extent of the accusations present.

I would have responded in a blunt fashion denying their claims and asking them to prove loss to the value of $20,000.

<comment><USER20> Free* advertising and publicity for The Oatmeal. I found the letter quite entertaining, further embedding The Oatmeal in my mind since even his _lawyer_ appears to have a sense of humor.

*I know lawyers aren't free, but he'd be paying a lawyer regardless of the letter's style.

<comment><USER21> It's possible (although I have no idea how plausible) that Mr Balasubramani could have written that letter _pro bono_ , which would be excellent advertising given the coverage this is getting, and since he's on the Good Team, it's probably more valuable publicity than that of the other fellow.

I speculate (at the risk of demonstrating my ignorance) that this letter, at 1 page of background and ~4 pages of analysis, may not actually have taken all that long to prepare, especially for someone with intimate knowledge of DMCA and libel/defamation case-law.

Of course, it's a lot more complicated if he has arranged representation rather than just letter-writing, and the contact telephone at the end perhaps suggests he has, so it's quite possible I'm wrong.

<comment><USER20> Since Mr. Balasubramani has some background in writing (as mentioned above), it might just be a unique bonus to the service he offers.

</comment></comment></comment></comment><comment><USER22> "... I'll note simply that FunnyJunk does not appear to have a notice ofdesignation on file with the Copyright Office."

If true, that's pretty bad- that means that FunnyJunk's safe harbor status can be challenged (17 U.S.C. § 512(c)(2))

<comment><USER23> > notice of designation on file with the Copyright Office

What is that, exactly?

<comment><USER24> You basically have to have on file with the copyright office an agent designated to handle takedown claims, if you want to qualify for safe harbor provisions.

</comment></comment></comment><comment><USER25> Can someone post the text of this outside of Scribd? Their site always breaks in my browsers and I can't log in right now to download the PDF.

<comment><USER19> [https://www.dropbox.com/s/7lnsbd7363qkwdu/96850920-FunnyJunk...](https://www.dropbox.com/s/7lnsbd7363qkwdu/96850920-FunnyJunk- The-Oatmeal-Response.pdf)

<comment><USER26> Thank you. Scribd is usually more trouble than it's worth.

</comment></comment></comment><comment><USER27> The Oatmeal's donation campaign to the Wildlife fund and Cancer Society (and 2 other charities) is up to $168,000! <http://www.indiegogo.com/bearlovegood?a=700062>

The only winners in this legal brouhaha are the charities, how's that for turning the world up-side-down.

<comment><USER28> And the lawyers!

</comment></comment><comment><USER29> Carreon has certainly been owned by The Oatmeal's lawyer.

For those that didn't read it, I believe the answer from The Oatmeal in his blog is absolutely hilarious: <http://theoatmeal.com/blog/funnyjunk_letter>

</comment><comment><USER30> Nicely dismantles all the relevant points pretty easily, needs more bear fondling older ladies. B+.

<comment><USER31> It is also as surprisingly readable as it is thorough.

<comment><USER30> Yeah I noticed that as well, it kept everything short without wandering into the usual legalbabble that seems permeate most legal letters.

</comment></comment></comment><comment><USER32> This article estimated the time of the "Blog Post" by saying the first comment was about "10 months ago", so the posted time must be before that.

This actually points out a very annoying thing that many bloggers do: They don't date the blog posts. For some reason, they think that the posts are timeless. This is especially annoying for technical articles, where the knowledge of time of publication is crucial.

My suggestion is: date your articles.

</comment><comment><USER33> "(Interestingly, the subsequent blog post contains a screenshot of a statement by FunnyJunk that, under FunnyJunk's own logic, would constitute defamation: "[t]he Oatmeal wants to sue funnyjunk andshut it down!" The Oatmeal never threatened to sue FunnyJunk, nor did he ever indicate thathe wanted to shut down FunnyJunk's website.)"

Damn. You need some ice for that burn?!

</comment><comment><USER34> From two years ago and perhaps the site has a different owner now, but a revealing look at FunnyJunk:

[http://www.wickedfire.com/affiliate- marketing/97419-250k-uni...](http://www.wickedfire.com/affiliate- marketing/97419-250k-uniques-6-million-impressions-day-zero-revenue.html)

You need to register to see the thread, but the main part:

Posted: 07-23-2010, 04:28 PM

"My site, Funnyjunk.com has about 6 million page views a day and 250k uniques a day. It currently has no ad networks.

Valueclick, Adsense, and Casale kicked me off for adult content.

What adult content you ask? Nothing worse than you would see on youtube. The porn gets flagged and such."

</comment><comment><USER35> This is probably some of the best advertising Venkat can do for himself.

</comment><comment><USER36> Nice letter, and very well written.

I never read anything written like this in portugues. The lawyers here abuse in use legalese.

<comment><USER37> Most English-speaking lawyers do the same. This letter was refreshingly clear in its use of language.

</comment></comment><comment><USER38> So, one question that I had initially was addressed in the response, namely: does FunnyJunk actually qualify for DMCA fair harbor status?

From what I've read, it's a pretty simple and strict guideline - register an agent with the US Copyright Office so that you can receive notices of infringement. If you do that, you're protected from user-uploaded content.

In the response, Venkat alludes to the lack of a registered agent, so I went and looked it up (<http://www.copyright.gov/onlinesp/list/f_agents.html>). I can't see Funny Junk listed anywhere. If this is the case, they should consider themselves very lucky that they aren't getting counter-sued into oblivion.

Am I correct in the need for an agent? Am I looking in the right place?

</comment><comment><USER39> A successful defamation case in America requires proof that the offender had committed so called actual malice. This is very hard to do.

<comment><USER40> _A successful defamation case in America requires proof that the offender had committed so called actual malice._

Only a subset of plaintiffs in defamation cases are required to prove "actual malice" (a specialized legal term defined below). The general law in the United States is

"Depending on the circumstances, the plaintiff will either need to prove that the defendant acted negligently, if the plaintiff is a private figure, or with actual malice, if the plaintiff is a public figure or official."

[http://www.citmedialaw.org/legal-guide/proving-fault- actual-...](http://www.citmedialaw.org/legal-guide/proving-fault-actual- malice-and-negligence)

"The First Amendment requires that a defamation plaintiff prove actual malice or reckless disregard of the truth when the plaintiff is a public official or public figure. New York Times v. Sullivan, 376 U.S. 254 (1964). This is a much higher burden of proof for a public figure plaintiff. Instead of showing objectively that a "reasonable person" knew or should have known the defamatory statement was false, a public figure plaintiff must prove the intent of the defendant was malicious, or that they acted with reckless disregard for the truth. This allows the defendant to prove its good faith intent and efforts as a defense."

It's a debatable question in this case whether or not FunnyJunk's role in this litigation triggers the requirement to allege "actual malice" (it is certainly not a public official), so maybe FunnyJunk doesn't need to allege "actual malice."

"Actual Malice

"In a legal sense, 'actual malice' has nothing to do with ill will or disliking someone and wishing him harm. Rather, courts have defined 'actual malice' in the defamation context as publishing a statement while either

"knowing that it is false; or

"acting with reckless disregard for the statement's truth or falsity.

"It should be noted that the actual malice standard focuses on the defendant's actual state of mind at the time of publication. Unlike the negligence standard discussed later in this section, the actual malice standard is not measured by what a reasonable person would have published or investigated prior to publication. Instead, the plaintiff must produce clear and convincing evidence that the defendant actually knew the information was false or entertained serious doubts as to the truth of his publication. In making this determination, a court will look for evidence of the defendant's state of mind at the time of publication and will likely examine the steps he took in researching, editing, and fact checking his work. It is generally not sufficient, however, for a plaintiff to merely show that the defendant didn't like her, failed to contact her for comment, knew she had denied the information, relied on a single biased source, or failed to correct the statement after publication."

[http://www.citmedialaw.org/legal-guide/proving-fault- actual-...](http://www.citmedialaw.org/legal-guide/proving-fault-actual- malice-and-negligence)

</comment></comment><comment><USER27> The Oatmeal's donation campaign to the Wildlife fund and Cancer Society (and 2 other charities) is up $168,000! <http://www.indiegogo.com/bearlovegood?a=700062>

The only winners in a legal brouhaha are the charities, how's that for turning the world up-side-down.

</comment><comment><USER41> The only sad thing about reading this, is the incredible expense of creating such a response. In my experience, response letters such as these littered with appropriate references can easily cost several thousand dollars. I guess just the 'cost of doing business' on the internet.

</comment><comment><USER42> This back and forth public argument feels a lot like the hype up for a professional wrestling, boxing, or mma match. Both sides talking themselves up while the audience picks sides and eats it up.

I'm sure this wasn't intended but it's fascinating to say the least.

</comment><comment><USER43> This letter is surprisingly readable to non-lawyers. I wonder if this is sometimes done intentionally if the lawyer writing it knows it may/will end up publicly available like this.

</comment><comment><USER44> From a layman's POV, this just looks like abusing law for profit. There is no potential justice here, just profit. Call me a simpleton, but how is that not a crime in its self?

</comment><comment><USER45> It's been a big week for the Streisand Effect. Between The Oatmeal and Never Seconds, nearly a quarter million dollars has been raised for charities.

</comment><comment><USER46> "At the end of the day, a lawsuit against TheOatmeal in this situation is just a really bad idea"

My favourite line.

</comment><comment><USER47> Oatmeal shouldnt have said they mirrored his site.

</comment><comment><USER48> Carreon just got lawyered</comment>


Requirements volatility is the core problem of software engineering - <AUTHOR> https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/ <comment><USER2> I am reminded of how linguists, when trying to document a language from one of the last living native speakers, don't just ask them to tell them the rules of it. They have to task questions like "how would you say this?" Then they try to reverse-engineer the grammar, syntax, etc.

In most cases, the people who are giving the requirements either: 1) don't actually know them (e.g. they are in upper management but the software will be used by line workers) 2) have internalized the details of the process so long ago that they are essentially subconscious now. They would tell you the real requirements if they could, but they just can't, they will instead tell you what they think the requirements are. Then, once you build it and they try to use it, like the native speaker of a language hearing you speak a sentence in it using the grammar rules they just told you, they will immediately know that it's wrong.

So, the best way to find the _real_ requirements for the software, is to build the software, and have them try to use it. Stop planning and endlessly documenting someone's fantasy or best guess at what the requirements are; the only way to really discover the requirements is to build the thing.

<comment><USER3> Here's another good example: what is the correct way to order multiple adjectives in English? If you are a native speaker, you probably don't have any idea, you just know that you say "an old big brown cardboard fridge box", rather than "a cardboard brown fridge old big box". The order is very specific and any deviation is obviously incorrect. Try it for yourself!

But any ESL student can tell you the order is quantity, opinion, size, age, shape, color, origin, material, purpose. We'd had to reverse-engineer the rules, and then teach it to newcomers.

<comment><USER4> Then it must be "big old brown cardboard fridge box".

<comment><USER5> Incidentally that's exactly how I would have worded the sentence as a native speaker. But only because "big ol'" is a common phrase by itself

<comment><USER6> To me, also a native speaker (UK if it makes a difference), "big old" implies size alone(fairly large) rather than age, while "old big" would definitely mean old and large

</comment></comment></comment></comment></comment><comment><USER7> I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".

<comment><USER8> > I often hear people say that software engineering is a joke compared to > civil engineering ...

I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the _actual_ requirements first like any real engineering job would have you do.

And it looks like everyone is pushing it more into this ass-first direction with agile. Let's not even try to plan ahead! You know what you want next week, so this short-sighted focus leads to chaotic development and once the real requirements are figured out 9 months into the project, well too bad it's too late to redesign and rewrite it all properly. So it's forever going to be a bumpy and crooked bridge on the verge of collapse, held together by more and more duck tape, hot glue and occult ceremony. And there's a plastic tunnel hanging underneath it. Only the brave will crawl through.

<comment><USER9> Manager and Director are the people who are pushing "agile". They want quick results, and SE can only do what they want. You simply really can't "gather" requirement and finish a feature and do proper testing in a 2-week sprint.

I do agree there are a lot of bad practices in SE as well, but let's not blame everything on them.

<comment><USER8> Yeah I'm not really blaming individual software engineers (I'm in the same boat, fighting a slow trickle of feature after feature without really being given a chance to step back and consider the overall design & its future evolution), but the industry as a whole. As I said in another comment in this thread, all too often SEs are just tasked with cooking sh*t to vague spec (as laid out by sales & other non-engineers) instead of being active at the earlier stages where engineering should already begin.

It's like sales people together with the customer decided the shape and colour of the bridge, as well as the number of pillars it has, and how many lanes it has, and what material it's made of -- here's the stack of things you build with -- and what other fancy features it has, and now finally we can call the engineer so they can hop on a bulldozer and start engineering with their hammer for the next two weeks and show the result so we can adjust the shape if it's not as pretty as we imagined. Actual engineering didn't happen.

</comment></comment></comment></comment><comment><USER10> > Requirements change. Every software engineering project will face this hard > problem at some point.

> There is really only one answer to this: you need to find a way to match the > requirements-development-delivery cycle to the rate at which the > requirements change.

Honestly, I believe that much of the problem is with the word "requirements" and I so wish we could kill this use of the word. Bottom line, for systems built for humans, ploughing through backlogs of requirements is the path to mediocracy (or worse) – as the OP discovered.

A less misleading framing: you need to find a way to match the delivery cycle to the rate at which understanding changes. In other words, your development process is a learning process.

<comment><USER11> 100% agree learning is the core problem people in large organizations really don't know how to learn and the typical corporate environment is the perfect quasi academic environment geared towards pursuing metrics that amount to chasing grades

</comment></comment><comment><USER12> This quote is old and explain very well why early software was often high quality:

> "Walking on water and developing software from a specification are easy if > both are frozen."

― Edward V. Berard

The more you plan ahead and the less you change goals while writing software, the less problems you have.

Software is the only field of engineering where you can change things at any point in time. But it doesn't mean you HAVE to change things. Software should really take lesson from other fields of engineering. Companies always want to cut costs, and with software, they really can.

<comment><USER13> The ongoing discussion in the EU about a legal obligation of X years of update support comes to mind...

</comment></comment><comment><USER14> The article mentions how one part of change is that regulations may have changed.

I work in a heavily regulated industry, and am dealing with a set of regulators nearly all who depend on just one particular auditing company to ... effectively write their regulations for them. To the point where a new jurisdiction happily refers to their draft regulations as documents prefixed with the auditing firm's name on them. (This is not a joke or hyperbole.)

That particular company has trained their own workforce to evaluate acceptance criteria according to their internal workflows and practices. This in turn means that almost _all_ industry regulations are geared not towards functionality, but to make sure the auditing company has the least amount of training to do. As far as I am concerned, this is a particularly perverse form of regulatory capture: it's not even the industry at large writing their regulations, but an already entrenched gatekeeper acting on _their_ own interest, crippling both the regulators and the companies in the industry.

Now, I have no problem with regulations as such, because for most parts the rules tend to make good sense. But I do have a problem with regulations shaped after the desires of this particular auditing company. Instead of focusing on results, quality, transparency, accuracy, recoverability and functionality, they have a fixated view on particularly dubious change management processes.

I am _convinced_ that at some point in history, someone has done extensive research into 70 years of software engineering best practices - and gone to extreme lengths to expressly reject as many of them as possible.

Two examples: they insist that even unit tests _MUST NOT_ be written by the engineers who work on the code; and they are mortally afraid of the idea that engineers who work on a problem could ever _understand and evaluate_ the problem. (Not to mention that the very concept of a workflow tool is completely alien to them.)

The end result is that you can either try to do software well, or you can try to do it according to regulations.

<comment><USER13> Understanding and evaluating the problem is the main job of an engineer?!? (Compared to a technician...)

<comment><USER14> It's definitely part of the job. If you don't understand what the problem is that you're trying to solve, how can you verify that the constraints you are working with actually make sense?

</comment></comment></comment><comment><USER15> Greg Young described a good way to deal with requirements volatility: optimize from the beginning to be able to delete your code, and structure your code so that any part of it is no bigger than 1 week's worth of coding. So that any part can be re-written in 1 week.

[https://vimeo.com/108441214](https://vimeo.com/108441214)

<comment><USER16> That was an insightful talk, thanks for sharing!

</comment></comment><comment><USER17> The only software project I ever worked on in which the customer didn't report so much as a single bug had the requirements done properly, up front, and agreed all round. Of the thousands of identified requirements, I think less than ten changed over the lifetime of the project, and each change underwent significant examination for consequences.

The project was waterfall all the way.

The quality of software that can be built if you know before you start what it's meant to do, and that doesn't change, is _astounding_. Truly astounding.

<comment><USER18> I have worked on huge government projects that has been specced and planned for years before arriving at my team's desks. It takes a few days before we will have questions. Things not defined good enough, inconsistencies, glaring holes etc.

I think having all reqs upfront is a utopia that will not happen. Those projects I was involved in would have been better if the reqs and scope was done in conjunction with us implementing it.

<comment><USER17> We had some good requirements people. Really good. They didn't just write things down. There was a lot of examination and analysis and plotting and so on, and they were good at it. They'd all begun their careers as software engineers and gradually specialised into being really good at requirements.

 _I think having all reqs upfront is a utopia that will not happen._

What can I say? It happened to me. Only with one company in seven or so worked for so far. I would not be surprised if people worked two dozen jobs and never experienced it.

You do need high-quality customers, though, and they are hard to come by. I've worked for a company that has turned down customers on the grounds that the potential customer just isn't good enough; they worded it differently, but that's what it was.

</comment></comment></comment><comment><USER19> It's not a problem of software engineering, it's a property of software engineering.

<comment><USER20> Yes, that is very true. If changing and complex requirements are a problem, you are doing it wrong. This is the main reason why code quality must be as high as possible. It is the best chance there is to be able to accommodate new and changing requirements in a reasonable time frame. It is also the reason why automated tests are a necessity. Otherwise it is way to easy to satisfy one requirement while not noticing that at the same time one is destroying three others.

<comment><USER21> If the subject is Software Engineering and you said "If changing and complex requirements are a problem, you are doing it wrong" the it in that sentence should be Software Engineering - but the changing and complex requirements seldomly come from the Engineers.

<comment><USER20> No, they do not come from the software engineers. It is like being a DJ who is taking requests. You are not playing music for yourself but for other people. It the DJs task to make them sound good. On the other hand, one sometimes also needs to clarify what is wanted because the customers will ask for a rock song with a slight edge of metal in it and as the DJ you will need to know what song fits that description.

<comment><USER21> It seems that when I say that requirements seldomly come from the software engineers you have somehow misunderstood me as meaning that requirements do come from the software engineers?

<comment><USER20> No, it is just that your post sounded to me like you were saying that it is a problem that the requirements are not coming from the software engineers. My post attempts to say that this is not a problem and that it actually is how it should be.

<comment><USER21> How could you possibly interpret what I wrote in that manner?

I quoted your statement "If changing and complex requirements are a problem, you are doing it wrong" and pointed out that it was not reasonable to say someone is doing Software Engineering wrong due to changing requirements, as the engineers are seldomly in charge of requirements.

<comment><USER20> Ah, now I understand what you are trying to say. Yes, the 'it' in my post is indeed referring to software engineering.

It is not so much that they are doing software engineering wrong due to changing requirements as that the changing requirements make clear that the quality of the engineering is not that great. Another engineer who is working with a higher quality perhaps could have handled the changing and complex requirements without much problems. And in another project the requirements are perhaps quite simple and there is not much requests for changes and both engineers would have done equally well because their skill was not tested much.

Of course, there also has to be some limit in changing and complex requirements beyond which it is no longer reasonable for anyone to be able to keep up...... but we do call it SOFTware as opposed to HARDware because it is supposed to be changeable.... and if that which is supposed to be changeable actually is not, there must be something wrong.....

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> By now, I'm rather convinced that the "core problem" of software engineering is that it's too easy. Yes, despite the myriad failures in delivery, once you actually get some working software onto the market, its value immediately multiplies as a sole function of your marketing (and, incidentally, I think this is one of the reasons why US based companies are more successful than e.g. European ones: they can start out with a big single market). And even when you're not profitable, VC money is being pumped into the most ridiculous of companies right now.

Of course, when faced with this kind of situation, why bother getting things right and professionalising? I've seen big companies with the most insane development cultures where things would constantly break, and yet it didn't really have any big negative impact on profits. Maybe the well will dry up at some point, but so far it doesn't look like it.

</comment><comment><USER23> Developers who believe they can forsee the future are more dangerous than missing business requirements.

The problem with missing business requirements are that developers often are either to focused on writing the code instead of actually understanding the business.

You cannot build something you do not understand.

Understand small and expand your understanding. Code is not the goal, it never is. It's a means to a goal.

Another thing about software is, that a lot of it should never ever be written. It's the last thing you do, is write code for overcoming a challenge, because rarely you really need it.

<comment><USER24> Nicely put. In my nearly three decades of software development, the most successful of my various colleagues have been the ones motivated by understanding the problem and its wider context, rather than the tech/process/language _de jour_.

This is a multiplier because it allows them to detect and ignore non-problems and work on problems whose solutions _will_ deliver value.

</comment></comment><comment><USER25> It is funny to compare that to traditional product design. Let's say your goal is to design a chair. The most important tools in your toolbox are variants and iterations. The worst you could do as a designer is constantly working on one (final) chair. Because every change that goes aginst the initial concept will have you saw pieces away and glue them to other spots till you end up with a completely irrational whole.

The problem is of course, that a low effort design prototype still looks and feels like a low effort design prototype. But the customer sees 5 variants of the low effort prototype and can decide which one is iterated on further.

If you program a low effort software prototype, it should still kinda work and this is where the customer would decide to run with it.

Also software (like graphic design) is a field where people without any skill tend to have strong opinions about how things should look or work, which makes manipulazing the customer into taking a decent solution part of the job.

<comment><USER26> > Also software (like graphic design) is a field where people without any > skill tend to have strong opinions about how things should look or work

Business too. You do not have to be a good strategist to "succeed" as a VP in a medium or larger sized organization. In fact, you can be downright terrible.

<comment><USER27> But when you're writing business software to solve business problems, many more people have a "right" to an opinion. Usually the business people know a lot more about the problem domain than the programmer. They are also the ones who will use the solution.

I've been thinking that this is one of the key differences between software and bridges. When you design a bridge, very few people have a "right" to an opinion on the bolt sizing. But when you design an order entry system, the business users (and users of the downstream data) have a valid right to an opinion.

<comment><USER25> Agreed, if it is their profession they know it better. The thing I was initially refering to is stuff like people who do a horrible layout in word and ask to to literally do the same thing without having any qualification on the matter. Or people who want you to put a whole page of text nobody will ever be able to read onto a roadside sign.

This feels like if one would ask a electrician to use wires without insulation because they like them better — you can totally have your taste, but some stuff is just plain stupid and won't work as intended.

Graphics e.g. is about communicating certain things, and a graphic designers job is to be aware of what this communication does and how effective it does it. And so just like with a bridge (but arguably less dangerous) there can be design that does the job and design that does the polar oposite of what your customer intended.

</comment></comment></comment></comment><comment><USER28> The key difference between software vs all other engineering: building it is instant & free & repeatable, vs expensive & slow & singleton.

If bridges could be replaced in minutes for pennies, we'd build them iteratively too.

<comment><USER29> Buildings certainly _do_ change. I just finished 3 months of work on a structure that was "finished" 20 years ago. We had the client coming to us with changes to our changes several times a week.

The problem with software is that we don't build it in a way that makes changes easy (or at least not all the types of changes that clients frequently want to do), and we do a terrible job of communicating the costs of changes.

Give me any program, and I can change a couple words in its requirements which would cause more than half of its lines to need to be changed. That's just how we write software today.

(We diligently made 'time_t' a typedef, and then we embedded the physical size of it in every file format and API and protocol so we can't actually change it without breaking everything.)

Maybe we need a new type of specification system, to encode the distinction between "this is a decision which is immensely expensive to change and will necessitate rewriting half the program" and "this is just part of the facade and we can change it cheaply at any time".

</comment></comment><comment><USER30> After 50 years of activity in attempting to improve software project metrics with little to no improvement, we have to admit that we've been looking in completely the wrong place for effective change.

It's not how the developers work that is the problem. We've changed languages, team sizes, project cycle lengths, everything. Except one thing.

The one thing in common with all of these failed software projects is corporate, top-down management. I would say it's even gotten worse, to counterbalance the real productivity improvements we have actually gained from improved tools. You look at all the companies that _can_ deliver software on time and budget and they have one thing in common: they aren't ran by Harvard MBAs. You look at all the once-great companies that eventually faded away into obscurity and they also have one thing in common: imposition of MBA-imposed corporate management structure to "cut costs" (aka, "throw out the baby with the bathwater"). It killed Bell Labs. It killed Xerox PARC. It killed Apple once, which then was reborn from its own ashes, and is in the process of killing Apple again.

It's impossible to be a great developer in an environment that denies that there can be unique skills and knowledge to individuals. Anywhere developers are "resources" they will be treated as interchangeable cogs.

</comment><comment><USER31> I will say that our experience is that the happy path for virtually any customer is to ship the MVP as soon as humanly possible. This also means each new/revised feature after the fact. Only once the customer is actually screwing around with your app or feature will they start to develop a true understanding of what is unfolding relative to their daily life or business.

Our customers have extremely high expectations for the quality of output from our application. Their entire business hinges on whether or not we marked a specific checkbox correctly on one of many insanely-complex forms. We started out on this project with a mentality of "its gotta be perfect and we gotta be done at some point". As a result, our development cycles dragged on for months with the customer testing everything all at once on a single "drop dead day". Thankfully, we were able to get away from this mindset. We went from 'almost killing the company' to 'everyone is extremely happy' simply by delivering features to customers on a daily basis. Having that nearly-immediate feedback on new code from the customer means that the responsible developer likely still has most of the abstract concerns loaded into their mental cache and can quickly iterate if needed.

One other aspect that really started putting leverage behind us was building our own integrated tools for easily investigating exceptions or other issues in customer environments. If a user of our application experiences an exception, we are typically reviewing it within 5 minutes (without them having to report it to us explicitly), and if its a trivial affair, a build with a fix would be available for update that same day. Having the ability to trace user events through our application is probably the single most impactful troubleshooting tool available to us aside from the raw logs.

Ultimately, all of the above is the acknowledgement by us that software development is a very hazardous affair, and that we need processes and tools available for rapidly engaging these hazards when they arise. The sooner you realize you have the wrong answer to a problem, the sooner you can go off and find the correct one.

</comment><comment><USER32> I disagree with the title. I've used waterfall and still found engineering hard.

Even you have a bulletproof requirements document, implementation and engineering still produces unforeseen eventualities and unexpected consequences.

I think software engineering is hard primarily because it's the coalface between abstract and concrete.

We're wired to be great at concrete, but capable at abstract. With software it's like we can get ourselves into a perfect storm of intractable-for-us problems.

Other forms of engineering, civil, mechanical, etc are still really hard, but I think we're better wired for them because they're less abstract, more concrete.

But in software, abstraction is part of your bread-and-butter daily-grind tool-kit.

</comment><comment><USER33> If requirements volatility is the core problem, the next question to ask is, Why is this the core problem here and not in other engineering disciplines?

I think it stems from a mismatch between the perceived cost and the actual cost of changing software, which one of the first comments on the article captured:

> That's my take – the perception that software is simple to change, which > stems from the lack of understanding of its inherent complexity by users, > and the fact that it is, up to a certain point – is what makes requirements > volatile.

Part of the problem too is that the actual cost of changing software varies by an order of magnitude or more, depending on how fluent the developer is with the tools they're using, and how good they are at accommodating change. If that's not something even we as a profession (if you can call it that) have been able to reliably quantify, expecting a client to understand it is beyond the pale.

I've been programming for most of my life, so if I see an app then most of the time I can get a sense for how long it'd take to build. But I still have this nagging feeling that building software — the act of translating what's in your head into working code — seems to take way longer than it ought to.

<comment><USER34> > Why is this the core problem here and not in other engineering disciplines?

Software is the blueprint of a process. Software engineering is basically the art of exact specifications.

Once you've _unambiguously_ specified what it is you want, you're done. The rest is pretty much an appropriate language an a compiler but we have plenty of those.

</comment></comment><comment><USER35> There is a whole industry of people who are in the business of telling programmers what to do but not how to successfully complete a project because they do not know anything about how to actually finish the things they tell people to start. "Just use agile everything will be OK!"

<comment><USER35> Oh and lets not forget the project managers themselves that blame the client/users instead of their own inability to meet the requirements; [http://owensoft.net/v4/item/2368/](http://owensoft.net/v4/item/2368/)

</comment></comment><comment><USER36> This, along with the cost of development, is why I have a pet-peeve for hard- coded business logic directly in the code (in most cases). I.e. when a frequently changing business process like a finite state machine for an approval procedure is only change-able by a developer that means there's always the cost of that developer's "need-to-know" for a straight forward change in the business operations. The cost of a given change is greater than a declarative capability that took into account operational changes in the first place.

That said hard coding business logic is often so much quicker to deploy that in many situations you just want to hard code the logic, deploy, get feedback, then introduce flexible to the kind of change needed then continue. If you have engineers who know how to ask the kind of questions that get to the real requirements (usually not juniors) you can have a maintainable code base. Worst case scenario is if you have the "yes I shall do anything and everything with my new code power" developers who just implement out of eagerness and conflict avoidance; this can be the worst of every world: hard coded business logic so convoluted only the junior knows how to make changes.

<comment><USER37> > This, along with the cost of development, is why I have a pet-peeve for > hard-coded business logic directly in the code (in most cases).

I've built systems both ways. Requiring a developer to make changes definitely has costs, but it does have benefits as well. Systems configured in data rather than code will almost invariably be untested and prone to configuration bugs. Overall, I've spent probably double or triple the time debugging configuration of complex business rules systems than I would have if it was just written in code and unit tested.

<comment><USER36> Agreed. I guess my point is that we need to focus more on making declarative business rules systems more tenable as an approach in general. If we consider the framework + CRUD generators as the most productive way to build a web app (probably has been since Rails) - that's a result of tooling built around an approach. What happens when we focus similar efforts of tooling towards these Rule Based components?

</comment></comment></comment><comment><USER38> Agile is about giving developers the illusion of control, so they are more comfortable committing to an endless cycle of nonsense.

<comment><USER39> No agile is just micromanagement. Control every task the developer works on, make them report status on a daily basis.

<comment><USER40> Ask 10 different developers, Agile salesmen, and product owners and you'll get 10 different explanations of what Agile is.

Occasionally you'll come across somebody with a healthy dose of skepticism.

[https://news.ycombinator.com/item?id=5406384](https://news.ycombinator.com/item?id=5406384)

<comment><USER41> I think a lot of people are conflating Agility with SCRUM. If you look at the official SCRUM guide, you'll find ZERO references to agility. And if you look at the original Agile Manifesto, you'll find ZERO references to stories, sprints, story points, velocity, standups or any other thing that we consider agile.

For me, the essence of agility is: break down large projects into smaller and smaller projects until the "mini-project" becomes simple enough for you to execute. But each such mini-project _must_ delivery something that works. Also, don't show documents about the software, _show the software_.

</comment></comment></comment></comment><comment><USER42> The two most common patterns I've experienced:

1) Poorly communicated goals. Sometimes not communicated at all. If you don't know where you're head and _why_, it's damn near impossible to get there.

2) Wants being confused with actual business needs.

3) Clients / stakeholders not able or willing to put in the time for essential discussions and critical decisions.

</comment><comment><USER43> The article talks about the one contract that had the requirements fixed -- but then fails to talk about how contracts should be laid out to embrace changing requirements.

People have known for a long time that volatile requirements are a core problem, but that typically hasn't really affected the way software and software development services are procured.

This might be different in other parts of the world, but my impression is that even custom development contracts are procured the same way that you would a big shipment of physical goods, which is just insane.

Once you work as a developer in a project that was procured in such a way, it's already too late. The knowledge that requirements will change and will totally disrupt your development process is there, and it doesn't really help you.

</comment><comment><USER44> As an addendum to this, I would frame the problem as "complexity," one aspect or symptom of which is requirements volatility.

Complexity comes from two sources in software projects. The first is the domain. As other commenters have pointed out, domain experts are usually half- aware of their domain requirements because much of the complexity has been buried under their expertise and intuition. Domain requirements also inherently change over time as markets, professional standards, and technology evolve. So the process of development involves a shifting discovery of new aspects of the domain as things which were unconscious become consciously learned.

The other aspect of complexity is the technology applied to the problem. Computer technology is inherently complex, and the imperfect mapping between domain problems and technology adds a third angle.

The best books I've seen for dealing with these problems are "Clean Architecture," "A Philosophy of Software Design," and "Principles of Product Development Flow." The first two explain how to build good systems that encapsulate complexity and are geared towards changeability. Such systems are flexible as new aspects of domain complexity are discovered over time. The latter book takes a higher level view of how to design projects to cope with the discovery process in a way that is economically viable and justifiable to the people financing projects, and also in a way that arranges work so that developers can actually be productive and not become swamped by the complexity problem or bad processes and practices.

</comment><comment><USER45> > As a consequence of this, software is never finished, only abandoned.

Ditty of mine from around 1988 or so. The hardware is old and obsolete but the software never is complete.

One thing I realized a long time ago was that you need enough resources to keep up with the requirements drift or you will never finish. That's what's behind YAGNI and Minimum Viable Product.

There is this other thing which is a successful product 'creates it's own weather' as far as requirements go.

</comment><comment><USER46> Is it primarily requirement volatility, or primarily ill-defined requirements? (If it's the later, that's some super-irony.)

That would explain at least a couple of further issues mentioned here. Like rewrites: software doesn't always define it's own outcomes well; the requirements don't change they're just poorly defined.

Requirements changing, and feature creep are subtly different too -- with static ill-defined requirements features could change as the requirements in a particular facet of the software become more clearly mapped out further on in the project.

For example, in the Berlin airport situation (in a comment here), adding a new floor could be due to a realisation that a static requirement for floorspace want going to be obtained, because (say) a static requirement for through-flow hadn't been fully defined and expanding the capacity to meet that requirement then limited the available floorspace. None of the requirements needs to have changed.

Perhaps that's to much of a philosophical distinction.

(Not a [software] architect, or project manager or anything, feel free to tell me I'm talking rubbish.)

</comment><comment><USER47> > Requirements change. Every software engineering project will face this hard > problem at some point.

Rich Hickey calls this a 'situated' program in his talk from Clojure/Conj 2017, where the program has to deal with information and real-world irregularities for extended periods.

While agile disciplines help you from one perspective, your tools (e.g. program language) might also help you solve some of the problems. In this framing, Clojure certainly tries to help where the it matters most.

Highly recommended to read the transcript or watch the video, even if you are not interested in the language itself.

Video: [https://www.youtube.com/watch?v=2V1FtfBDsLU](https://www.youtube.com/watch?v=2V1FtfBDsLU) Transcript: [https://github.com/matthiasn/talk- transcripts/blob/master/Hi...](https://github.com/matthiasn/talk- transcripts/blob/master/Hickey_Rich/EffectivePrograms.md)

</comment><comment><USER48> Don"t rewrites also fail all the time, even if requirements are not expanded?

Rewrites would mostly be successful by the articles premise.

<comment><USER49> Well rewrites have two conflicting goals - simplifying the code/improving performance and consistency with the old version. Even if the requirements are nominally the same "unwritten" ones pop up

<comment><USER48> Sure, but "unwritten" requirements pop up all the time for any requirements, so the two situations are still broadly equivalent.

</comment></comment></comment><comment><USER50> Honestly the desire for simple unit economics and legacy property rights really fucked it up. People pay for "a software", but what they really need is a change in the collective software commons. Of course, no one expects any change order to be the final one, so the the volitility is natural and expected.

</comment><comment><USER51> Just to nitpick, there are counter examples of finished but not abandoned software. As usual, Tex comes to mind.

Or they just could. E.g. we could probably take the current Python 3 and freeze it and debug it for 20 years, at which point it would be basically finished, and maintenance could still continue (but way much less would be needed)

IMO a good part of requirement volatility is a self inflicted wound. Some are essential, of course, but some changes are for the sake of changing and giving PM, UI, and software engineers jobs, and I even don't know lot of people who appreciate too many gratuitous changes in e.g. software GUI.

My general advice is to slow down. And fucking finish things before starting new ones. We don't let half-constructed bridges around just because we start to build new ones with fancier materials.

<comment><USER13> I guess that slowing down doesn't pay well in an industry where a startup can get from zero to billion in a few years?

<comment><USER51> Probably that plays a role. However, not everything is a startup. Accumulating technical debt during even just a few years like there is no tomorrow is also a non negligible risk. You can _also_ go from billion to zero in a few years...

</comment></comment></comment><comment><USER52> My honest opinion is that software conceptually __was created __to allow for volatility of the requirements.

If you want to have static requirements (or changing once per 5-10y), then that's what you have _hardware_ for.

Software has "soft" in the name for that exact reason.

Embrace the constant change.

</comment><comment><USER53> A really big influence to me has been the work by prof Harel on Behavioral Programming (aka scenario based programming) which makes coding similar to how requirements change, evolve and sculpt the software.

His take is much more pragmatic than the Agile manifesto hinting at entire new languages (live sequence charts) and paradigms (bthreads) where requirements can actually be executed

This wonderful video by Harel himself is a good intro on these concepts: [https://vimeo.com/167925763](https://vimeo.com/167925763)

</comment><comment><USER54> >In an agile project, ideally, there is a working partial implementation starting very early in a project, and observable progress is being made toward a satisfactory product from the first.

Can anyone give a practical example of how this works in the real world? Like, what's a complicated workflow that needs automating, and how would you build it iteratively? Also, how could you predictably alot a time budget in this case so that you are not endlessly chasing satisfaction on a specific product or feature?

</comment><comment><USER55> As part of a project I interviewed a lot of "crossovers": people who worked as both traditional engineers and software engineers. According to everyone I talked to, requirements volatility happens everywhere. Two civil engineers had to move a bridge. One "system engineer" worked for Boeing and was part of a team who's only job was to figure out how to reconcile existing work whenever they changed requirements.

</comment><comment><USER56> I change the requirements of my personal projects all the time.

Once I get a prototype working I get lots of ideas of how to improve things. I also see that some of my initial plans did not work I out as I envisioned and have to iterate on them.

If I can't get the requirements right on my own projects, then I have no expectations that others could do so either.

Have the expectation that requirements are wrong on any project. It is better to embrace that these will change rather than try to fight them.

</comment><comment><USER57> Requirements volatility does not fully explain the frequency with which basic security flaws keep reappearing, long after they have been recognized and documented.

</comment><comment><USER58> That's true of any form of engineering, not just software. Requirements change because circumstances constantly change, and people simply are unable to imagine it completely beforehand. One has to build it and try it out.

As software engineers, we build things to be adaptable to change. That's why it works to build things out of encapsulated components.

</comment><comment><USER59> Requirements are fairly volatile -- but the real problem isn't that the requirements themselves are volatile but that the true requirements are so poorly understood (and, thus, the apparent requirements shift rapidly as understanding of the problem domain changes throughout the software lifecycle).

</comment><comment><USER60> As someone somewhere said, writing software to a spec is like walking on the water - Easy when it is frozen.

<comment><USER61> Still slippery though.

<comment><USER62> Better make it a rough spec then.

</comment></comment></comment><comment><USER63> Requirements are hard, but the _core_ problem of software engineering is complexity.

</comment><comment><USER21> This is somewhat triggering for me right now as I am just getting done with a project that is quite a few degrees hotter on the Requirements volatility scale than is currently assumed.

</comment><comment><USER64> Hopefully the existence of this article will not make it legitimate for managers to change the specs all the time.

</comment><comment><USER65> > _The goal of software engineering is to make that development predictable > and cost-effective._

Is this true?

</comment><comment><USER66> "Requirements volatility" is just another word for: A/B testing software :). Let's get used to it

</comment><comment><USER67> The weird thing (IMO) is that computers are already universal machines, so why isn't _any_ programming language already enough for _any_ task?

In other words, why hasn't Excel _fully_ defeated all comers?

It's widely known but seldom appreciated that _Excel_ is the most popular and successful programing language in history. And not just a little. It wins by a large margin. So why do people still pay you and I to "make things go"? (Yes, that's a Pakled reference. [https://memory- alpha.fandom.com/wiki/Pakled](https://memory-alpha.fandom.com/wiki/Pakled))

I think to answer this question you have to understand the difference between what we have now and what we could have.

What we have now is a stack: OS, WM, "Desktop" -> Separate "Applications" often with their own GUI (in addition to the OS-provided defaults) -> Web "apps" where anything goes (up to and including "dark patterns" like fake widgets designed to mimic OS-level modal dialogs.) All of this is conceptual _overhead_ that adds nothing to the achievement of the prime tasks (that humans are using computer for in the first place.)

What we could have: I have _two_ examples: The Oberon OS and Jef Raskin's work.

[https://inf.ethz.ch/personal/wirth/ProjectOberon/](https://inf.ethz.ch/personal/wirth/ProjectOberon/) [http://www.projectoberon.com/](http://www.projectoberon.com/) Try it live in your browser: [https://schierlm.github.io/OberonEmulator/emu.html](https://schierlm.github.io/OberonEmulator/emu.html)

[https://en.wikipedia.org/wiki/Jef_Raskin](https://en.wikipedia.org/wiki/Jef_Raskin) [https://en.wikipedia.org/wiki/The_Humane_Interface_(Book)](https://en.wikipedia.org/wiki/The_Humane_Interface_\(Book\)) [https://en.wikipedia.org/wiki/Canon_Cat](https://en.wikipedia.org/wiki/Canon_Cat) [https://en.wikipedia.org/wiki/Archy](https://en.wikipedia.org/wiki/Archy)

> These ideas include content persistence, modelessness, a nucleus with > commands instead of applications, navigation using incremental text search, > and a zooming user interface (ZUI).

The core idea is to get "applications" and even modes out of the way, disintermediate as much as possible between the user and the raw computing power of the machine.

In sum, we spend an enormous amount of time and energy working on things that have _no_ intrinsic bearing on the tasks we hope to accomplish, largely due to the lack of awareness that it's possible to dispense with _most_ of what is today considered normal UI. We are "turd polishing".

If you get out of the users' way, they can implement their own requirements.

\- - - -

Here's RMS talking about secretaries extending Emacs with Lisp:

> programming new editing commands was so convenient that even the secretaries > in his [Bernie Greenberg] office started learning how to use it. They used a > manual someone had written which showed how to extend Emacs, but didn't say > it was a programming. So the secretaries, who believed they couldn't do > programming, weren't scared off. They read the manual, discovered they could > do useful things and they learned to program.

[https://www.gnu.org/gnu/rms-lisp.html](https://www.gnu.org/gnu/rms-lisp.html)

</comment><comment><USER68> <rant>I don't think most people know what they're doing when it comes to managing the delivery of software. The field is full of canards, facile simplifications, and self-referential, circular reasoning. A few examples.

\- The problem is requirements. Is the system broken? Yes. Do the requirements say for it to be this way? Yes. Must be broken requirements, right? Since requirements are the "driver" of the process, if the process is broke so must be something about requirements.

\- Software is never done. Bullshit. Do I need somebody to reprogram my decades-old mp3 player? I do not. Would it be nice if somebody did? Maybe, but it's not required for me to enjoy the software. The software is written, does its job, and needs no maintenance. It's done. There's plenty of software being updated today for pretty good reasons that for all intents and purposes is done. Just nobody wants to admit it. If it's possible to add stuff or update it, we do. It's what we do.

\- FTA, "...Requirements change. Every software engineering project will face this hard problem at some point..." That's true, but woefully incomplete. Your job creating software is not to meet the requirements, it's not to change and add stuff as the requirements change. That's viewing the work, once again, as requirements-driven. No matter what your process or paperwork, the work is ultimately user-driven, not requirements-driven. Your job is to scope a domain, anticipate change in that domain, and provide easy-to-use configurable software that anticipates that change. You do that by knowing the users and the work, not by reading requirements or responding to updated requirements. That kind of thinking removes the key piece of the entire work, the user. By the time somebody gives you a requirement, it's too late. Your design is whack.

How do we make aviation and space travel gear safe? We fly the hell out of it. What's the wrong way to go? Build one-at-a-time and ask for changes and complete reworks for every new project. How do we build software today? Like we used to build rockets; using the wrong metaphor. We need reusable, configurable, capabilities-driven software, not endlessly worked-on huge hunks of bytes from BigCorp feature factories.</rant>

EDIT: Just to clarify the rocket metaphor, we'd be far, far better off using COTS tools and writing minimalist, simple code that only does a few things, then pounding the hell out of it with actual usage to figure out which "axes of change" we missed. Instead, more and more everything has some unique tech stack, a byzantine testing and deployment deployment system, the entire thing fun of tons of complex one-of code everywhere ... then we stick on new features one at a time every time there's something a user wants that it doesn't have. From a managing-complexity and managing-cost standpoint, it's actually worse than the Big Project rocket situation we had for decades.

</comment><comment><USER69> Perhaps that is the core problem, but that problem is caused by not knowing the requirements to begin with. Which again is usually caused by not knowing what your customer wants (which you should be able to do, even if they don't know themselves what they want), or not knowing who your customers are. Contract work is the best environment for fostering a culture of not knowing what your customers want, because it is the ultimate exercise in fence- throwing (often to somebody who's just going to throw it over yet another fence).

Problems tend not to change so dramatically over the course of a project. What usually happens is some stakeholder realizes at some point that they didn't actually understand the problem the first time around, and thus need to change the requirements. Even significant regulatory changes won't usually cause that. In almost all cases, regulatory changes have a significant amount of time between announcement and enforcement.

Making your development practices more responsive to change is a good goal, but it doesn't solve this problem. Because this problem is typically created before the first line of code is written. If the defined requirements don't actually solve the customers problem, then they're going to be delivered a non-functional solution, whether it takes one year to deliver, or one day.</comment>


Visualize Sports Stats - <AUTHOR> http://statplot.com

<comment><USER2> Get this in front of Bill Simmons immediately. He keeps begging Dork Elvis (Houston Rockets GM Daryl Morey) for all of the secret stats that they collect on just about everything that happens in an NBA game. Get the Sports Guy to blog, chat, tweet, or podcast about this, and you'll have more traffic than you know what to do with.

<comment><AUTHOR> I've tweeted and emailed him. We'll see if he responds...

</comment></comment><comment><USER3> Really cool. Pretty easy to use overall. I plan to play around with it a lot. My feedback is geared towards fantasy football, but here are my thoughts and suggestions:

1\. Some stats categories aren't clear. Which one do I select to graph rushing yards allowed per game for a specific team?

2\. How do I create a motion chart? I couldn't see how to do that and I didn't find any to copy from.

3\. I'll never want to put an image in the background of a graph.

4\. Add a category for fantasy points. Just use a simple default scoring system.

5\. Can I resize the image or flash graph? I don't like the thumbnail because you can't tell what it is, and I want to be able to embed a graph that's about half the size of the current embedable graphs, like 400 pixels wide.

6\. Any thoughts on a simple API? I see that the embedded graphs don't have any parameters. They have to be saved graphs. It would be cool to be able to embed a graph on different player pages by just changing parameters to the graph. For example, I'd like to be able to embed a graph into this page that shows stats for Pierre Thomas last year. <http://www.fantasyfootballchatter.com/pierre-thomas>. Bonus points if it doesn't require knowing player IDs and is just something like [http://statplot.com/graph/nfl/pierre-thomas?cat=rushing- yard...](http://statplot.com/graph/nfl/pierre-thomas?cat=rushing-yards). There could be a lot of sites out there that would embed charts if it was easier and didn't require creating an account and saving each one individually.

<comment><AUTHOR> Great feedback...

1\. Pretty common feedback. I need a glossary, but there are so many stats (over a thousand and growing). For "rushing yards allowed per game", you'd want to select Game Offense -> Rushing Yards and Game Opp-Offense -> Rushing Yards. I created an example chart here: <http://statplot.com/e/2821> 2\. It is under the "Chart Options" section on the left hand side beside the graph. 3\. Ok 4\. Can you tell me more about what this would include? <http://statsheet.com/contact> 5\. Yes, this is also under the Chart Options section. You can set whatever height and width that you want. 6\. StatPlot is the free version of a subscription site I'm working on now. I'm creating a service that will allow you to do just what you ask for, but there will be a fee (hopefully reasonable). If you are interested in learning more, let me know. I'm looking for beta testers now. There will be an API.

<comment><USER3> Great, thanks for the response. It seems that I missed the entire Chart Options section. I guess my main UI feedback then would be to put those options directly beneath the graph and move the background image stuff somewhere else.

Good to know there's more planned. I'll follow up with you on the fantasy points stuff.

</comment></comment></comment><comment><USER4> it's a great concept but there's a lot there and it's overwhelming.

there's definitely a demand for this but the real challenge is presenting sophisticated stats in an easy-to-use manner.

i would suggest dumbing down (simplifying) the presentation but not the content. cool idea though.

<comment><AUTHOR> This is the dumbed down version :-) I know what you mean though. It is a fine line between giving people simplicity and complete flexibility. I've thought about creating niche versions of StatPlot for specific teams. So you if you are a Dallas Cowboys fan, perhaps I could streamline the interface for a Dallas specific version of StatPlot.

Or I could just create a dirt simple version of StatPlot. Then the current version becomes the "Advanced" option.

Thoughts?

</comment></comment><comment><AUTHOR> I'm interested in any feedback about StatPlot!

<comment><USER5> How about Sparklines? They're perfect for some sporting data.

<comment><AUTHOR> Could do it pretty easily, but how would you want to use them? For embedding in a website?</comment></comment></comment>


Show HN: Loststories.tv – An infinite playlist of unknown YouTube videos - <AUTHOR> http://www.loststories.tv <comment><AUTHOR> Hello, here the creator.

LOSTSTORIES.TV is an infinite playlist of unknown and obscure IMGXXXX YouTube videos.

The titles of these videos are random strings based on the default media file names of some popular devices, such as iPhone or Samsung Galaxy. Some examples of these titles would be IMG_8869.MOV, DSC 0711 or MVI 6710.

All the videos, requested in real time, are not more than one year old. They are almost undiscovered, usually with very few views (or not even one).

Any feedback is welcome. Thanks! :)

<comment><USER2> Thank you for sharing/creating this. I love the concept behind this and also like how simple the user interface is.

<comment><AUTHOR> Thank you! My idea from the beginning was to create a very simple and "brutalist" design to focus the attention on the videos.</comment></comment></comment>


Big Lonely Doug - <AUTHOR> http://thewalrus.ca/big-lonely-doug/ <comment><USER2> Any relation to the Doug Flag?

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

<comment><USER3> According to your link, the Doug flag was created about 15 years before Big Lonely Doug was discovered.

<comment><USER2> Heh, yes, I mean is using "Doug" just an obvious thing to do for Douglas Firs, or is there a deeper meaning in the PNW?

<comment><USER4> "Doug fir" is a very common shorthand for Douglas fir trees, and not PNW- specific.</comment></comment></comment></comment>


What It Looks Like When the President Asks People to Snitch on Neighbors - <AUTHOR> https://splinternews.com/this-is-what-it-looks-like-when-the-president-asks-peop-1819077393 <comment><USER2> [http://chicagotonight.wttw.com/2016/12/02/new-hotline- deals-...](http://chicagotonight.wttw.com/2016/12/02/new-hotline-deals-solely- reports-discrimination-hate-crimes)

Whether it's considered snitching or reporting by concerned citizens depends on your political views.

<comment><USER3> The line can surely be blurry, but I'd say that reporting people for doing something that has no effect on you, and harms no one, is snitching.

Being an undocumented immigrant in America is no more harmful to society than being a jew in 1930s Germany.

<comment><USER4> _

<comment><USER5> Wow. The translation of your "How do you know that such an imigrant is not being a criminal?" to the equivalent statement in 1930's Germany is so direct and so poignant, I would have thought you were trying to support the parent's post, but I believe you're using that line to try to fault their thinking (which I find genuinely frightening in terms of the object lesson it presents on the ease of vilifying a "them" group, and how easily that kind of rhetoric can creep into polite conversation)

<comment><USER4> This was posted as an opposite to what OP posted, to point out his sided point of view while fortifying his opinion with pretty much unrelated, emotional part of history.

I made sarcasm very obvious, especially with exactly saying it was that, in the second line.

Learn how to read in between lines.

Edited the post so no one else thinks it is the real reply.

<comment><USER5> When talking about potentially inflammatory topics on the web, expecting the reader to "read between the lines" as you say is probably never a workable idea as there can be and are enough potential speakers across the entire spectrum of opinion that any intended meaning could be possible and potentially valid for "reading between the lines" (hence Poe's Law[0] and other challenges in the discussion of complex topics on the web when the range of speaker opinions and audience opinions is large and unknown).

No one ever expects Poe's law to apply to their own sarcasm, but unfortunately it always does.

[0][https://en.wikipedia.org/wiki/Poe%27s_law](https://en.wikipedia.org/wiki/Poe%27s_law)

</comment></comment></comment></comment></comment></comment><comment><USER6> Anyone surprised? This is exactly how it went in East Germany where everybody was encouraged to rat out their neighbors to the authorities about "staatszersetzendes Verhalten", just like what China is doing to its citizens still.

This stuff is the hallmark of a police state.

<comment><USER7> I loathe the comparison of Trump's presidency with fascism or now eastern bloc denunciation. I would appreciate it if we could criticize bad policies on their own merit, without the exaggerated historic comparisons. In my opinion, this is just fuel for division.

<comment><USER6> I don't see that as a Trump specific thing. As mentioned in other comments, other facilities for the same purpose existed before. VOICE just makes it much more visible.

I totally disagree that this is an exaggerated historic comparison. As someone who grew up in East Germany, all the measures which restrict the individual freedoms, which were put into place, over the years, make me sad and angry. And having historical examples which show the bad effects of such policies in a very striking manner is in my opinion a very useful shorthand, instead of elaborately discussing a policy (with an expected outcome). Especially the effects of Stasi methods are well researched, so they are a very useful comparison indeed.

I just wanted to pint out that what the article discusses has very close parallels to what we know about the "usefulness" of the same methods in e.g. East Germany.

</comment></comment></comment><comment><USER8> At the risk of invoking Godwin, I have to say that this frighteningly reminiscent of the stories that Milton Mayer details in his 1955 book "The Thought They Were Free: The German's 1933-45" .

<comment><USER9> Other than the fact that the Jews were living there as legal citizens, not illegal immigrants.

<comment><USER8> I'm sorry, I should have been more clear. The parallels that I see are related to the institutionalization of neighbor spying on neighbor. All that's missing are sanctioned and codified Blockleiters.

</comment></comment></comment><comment><USER10> This same behavior is why the IRS does not allow for anonymous reporting of tax violations. I think this article is overreaching in their fear, and perhaps fear-mongering. If a crime has been committed then a citizen is well within their rights to report it. You may not like that as a matter of politics, but it is legal. We should not be afraid to report behavior we feel might be illegal due to political correctness[0], or politics but at the same time, retaliatory use of law enforcement for crimes not justified should be punished.

[0] [http://www.dailymail.co.uk/news/article-3344736/Neighbors- Sa...](http://www.dailymail.co.uk/news/article-3344736/Neighbors-Saudi- husband-wife-San-Bernardino-shooters-noticed-acting-suspiciously-did-NOT- report-fear-racial-profiling.html)

</comment><comment><USER11> This is just obscene on so many levels.

</comment><comment><USER12> This needs to be flooded with legit sounding cases to dilute it out of existence.</comment>


Brazil Drafts An 'Anti-ACTA': A Civil Rights-Based Framework For The Internet - <AUTHOR> http://www.techdirt.com/articles/20111004/04402516196/brazil-drafts-anti-acta-civil-rights-based-framework-internet.shtml

<comment><USER2> Maybe Orson Scott Card is right. Maybe Brazil will be a place of great influence in the future. I would very seriously consider moving to a country that actually focused on governing its people while allowing business to continue in an intelligent fashion.

Sadly, I don't know where that would be at the moment, but I wouldn't feel bad about learning Portuguese if it turned out to be Brazil.

<comment><USER3> > Sadly, I don't know where that would be at the moment

At the moment that would probably be the US, or Canada, or one of the European powers. Probably not any emerging country. Certainly not Brazil.

I'm Brazilian. Brazil has come a long way in the past 20 years, but corruption is still way worse than the corruption that happens in the US. To sum up, in the US you have a music industry lobby donating money to candidates which then vote in favor of copyright laws. In Brazil we have Colombian drug lords associated with the ruling party.

Just because people in UK and US are protesting in the streets it doesn't mean that things are in any way close to the crap that happens in developing countries. It just means you have different standards.

<comment><USER4> "In Brazil we have Colombian drug lords associated with the ruling party." I'm also from Brasil. Whhaaat?? from where did you take this man? there is no evidence or anything about that, don't just say things you can't prove. Thats not even on the good media.

<comment><USER3> > don't just say things you can't prove.

It was on Estado de Sao Paulo e Veja, as diego_moita said.

(in English) [http://en.wikinews.org/wiki/Brazilian_President_party_receiv...](http://en.wikinews.org/wiki/Brazilian_President_party_received_money_from_FARC,_say_documents)

(in Portuguese) [http://pt.wikinews.org/wiki/FARC_pedem_para_participar_mais_...](http://pt.wikinews.org/wiki/FARC_pedem_para_participar_mais_ativamente_do_Foro_de_S%C3%A3o_Paulo)

Info on a related incident was leaked to wikileaks too. <http://wikileaks.org/cable/2006/07/06BRASILIA1511.html>

> _In a decision taken and kept in secret, the Brazilian National Committee on > Refuges (CONARE) July 14 granted political refugee status to Francisco > Antonio Cadena Collazos (known in Brazil as Olivera Medina), the so-called > Ambassador to Brazil of the FARC (Revolutionary Armed Forces of Colombia), > who was arrested in Brazil in August 2005 at the request of Interpol, based > on a Colombian arrest warrant which included charges of murder for terrorist > purposes, kidnapping, extortion and terrorism._

<comment><USER5> Being in the media is not any kind of proof, specially the media you just cited.

<comment><USER3> The second link has a transcription of the FARC website. It's not a rumour, FARC used to be present in the Foro de Sao Paulo meetings. But of course you're free to reject any evidence you want.

</comment></comment></comment></comment></comment></comment><comment><USER6> India is doing good in software patents and drug patents as well. Software cannot be patented and drugs have to be innovative (incremental is not good enough).

[http://articles.timesofindia.indiatimes.com/2011-01-13/india...](http://articles.timesofindia.indiatimes.com/2011-01-13/india- business/28379392_1_leena-menghaney-ritonavir-patent-applications)

</comment><comment><USER7> This is a great piece of legislation, it's sad that here in Canada we're seeing the opposite with the current government proposing a pretty draconian copyright bill:

[http://www.theglobeandmail.com/news/politics/law-cracks- down...](http://www.theglobeandmail.com/news/politics/law-cracks-down-on- digital-piracy-in-canada/article2184521/)

</comment><comment><USER8> You know what's weird? I'm brazilian, I follow up this kind of content and I just found out about this here on Hacker News. I haven't seem an article about this in any of the big portals.

Anyway, IMHO, one of the most important parts of the bill are the Article 14 and Article 15. I've seen some increase in bloggers getting sued because of other people's comments on their blog, and the problem also spits out on social networks and other user generated content sites every now and then. Finally we get a sign that someone is looking into that.

<comment><USER4> Me too! the mainstream midia in Brasil is in really bad shape.

<comment><USER9> Mainstream media is in bad shape everywhere and Brazil is no exception. Unfortunately our media outlets appear to make extra efforts not to anger current government (whatever the current government is).

You want an example? It took weeks for Occupy Wall St to be mentioned on CNN. I don't remember I saw anything on the police abuse happening there either.

</comment></comment></comment><comment><USER10> I'm brazilian and I don't think that its a WOHOO act or something. It's just that US and EU governments are so full of interests(and shit) that it looks good.

We don't have a big(and stupid) elite like the US does, so things stay reasonable.

<comment><USER11> Wait until subverting your government gets a bit more lucrative. Then, enjoy the ride :-)

<comment><USER12> I think that Brazil is anything but immune to money in politics:

<http://www.economist.com/node/15580390>

<comment><USER10> "Brazil is probably no more corrupt than other countries of similar size and wealth. It came out better than China and India and a long way ahead of Russia in the latest index of perceptions of corruption compiled by Transparency International, a German NGO. Brazil is blessed with competitive and aggressive media and tenacious institutions that investigate such scandals, revolving around the public-prosecutor's office, a semi-autonomous part of the federal government and its local equivalents. This scrutiny has a price: the government thinks that another watchdog, the audit tribunal, is holding up spending on infrastructure unnecessarily."

</comment></comment></comment></comment><comment><USER13> ACTA hasn't been waved around in front of normal people enough to get to the point where everyone can articulate why it is a bad idea.

<comment><USER14> Its a bad idea because it propagates class ordering on the basis of knowledge.

</comment></comment><comment><USER15> wow! this needs more international support!

</comment><comment><USER11> >ACTA is the last-gasp attempt of the US and the EU to preserve their intellectual monopolies.

If only. No doubt when this fails the bastards will think up something even more draconian, perhaps forced re-education or lobotomies for downloading μTorrent.

Western governments have been thoroughly captured by interests that represent a fraction of a percent of their populations. Anyone who expects this to come to an end while these governments still exist, is deluding themselves.

</comment><comment><USER16> All laws in brazil are well thought and mostly free of influence.

The problem lies in the executive.

Basically, there's no enforcement of most laws and others are interpreted as they want.

<comment><USER9> > All laws in brazil are well thought and mostly free of influence.

I wouldn't go as far.

Starting a company is insanely complicated. Shutting one down is ten times as bad.

<comment><USER16> because of dumb bureaucratic stuff.

most of the time your papers stay in one place for no reason for years ...mostly when it's going trhu the IRS equivalent.</comment></comment></comment>


Show HN: I created a Chrome extension to block videos - <AUTHOR> https://github.com/bullno1/nomovdo <comment><USER2> Cool mini project. I looked briefly at the extension.

Maybe consider looking into <iframe> and <embed> elements also instead of just <video>.</comment>