Intel Considers Outsorcing Manufacturing - its-tony https://www.bloomberg.com/news/articles/2020-07-25/intel-stunning-failure-heralds-end-of-era-for-u-s-chip-sector <comment><AUTHOR> Intel has fallen so far behind over the years. Intel's CEO has a business administration background vs AMD whose CEO has a PhD in electrical engineering from MIT. I suspect that has something to do with why Intel has made decisions over the years that have favored short-term financial gains over long-term technology investments.

<comment><USER2> What long-term technology investments has AMD made that Intel hasn't? Especially ones that are relevant to manufacturing?

This seems very much a "Intel did invest, failed at hard problem, considers buying from someone who succeeded" vs "AMD couldn't afford own fabs, sold own fabs, when formerly-own fabs couldn't afford to develop an upgrade AMD was free to buy manufacturing from someone who succeeded".</comment></comment>


Ask HN: Accelerator book – Please help us choose a cover - <AUTHOR> https://www.surveymonkey.com/s/QY8LRYX

<comment><AUTHOR> A little background: The book was funded through a Kickstarter campaign where it raised a little over $12,000. The book focuses on 200+ startup accelerators from 48 different countries, and features advice and incite from 140+ of their graduates. Please share your feedback on the covers and any cover ideas below. Cheers! Luke

</comment><comment><USER2> I don't fall in love with any of them, sorry! I know I'm hard to please (being a designer/writer and have designed book cover myself)... I like the graph from the white one best - because it's going upwards -> speeding up, louder, bolder, etc. But I like the overall feel from the black cover, 3rd one.

<comment><AUTHOR> Great feedback thanks!

</comment></comment><comment><USER3> They all look like great covers. I like the white one with the vertical lines on the right the best. Excited for your release guys!

</comment><comment><USER4> My favorite design is the one that looks like mountains, followed by the bars on the white page. Great stuff!

</comment><comment><USER5> Exciting times!! Sorry being dumb Luke. Does 1 = 1st choice? Or 1 point?

<comment><AUTHOR> Haha it's kind of tricky isn't it. Basically you list each design 1-4 according to which you like the best. Thanks!

</comment></comment><comment><USER6> Love the designs, think the white ones my favorite!

</comment><comment><USER7> definitely like the bar graph options. Great book and should be on every entrepreneurs coffee table. Excited for the revised edition!</comment>


Google Says the FBI Is Secretly Spying on Some of Its Customers - <AUTHOR> http://www.wired.com/threatlevel/2013/03/google-nsl-range/?cid=co6199824 <comment><USER2> The scary part about surveillance is that we built it, the government didn't.

Instead of the government mandating some Orwellian telescreen that nefariously records everything you write, or a national registry that lists who your friends are, where you went to school, and where you log in from, we built schemes that would record everything anyway for other purposes, like facebook and gmail, and then handed the keys over. Evgeny Morozov pointed this out when he mentioned that the KGB used to torture people for this information. But we've voluntarily built and submitted to it!

I don't dispute the need for surveillance, so what can be done? The best I can think of is a throwback to Bill Gates' emphasis on measurement. Transparency is important precisely because if you can't observe something, you don't have any clue what it is.

I know this sounds too political, but the very systems we're worried about are ones that several people who frequent this place helped build, for different purposes. There's no way to know exactly how something you build will be used, but there is a way to monitor it, and that requires transparency almost by definition.

<comment><USER3> Don't forget the beautiful, shiny tracking devices most of us pay a lot of money to carry around.

<comment><USER4> I have no idea of the answer to this question but I'd like to hear from you folks: Given that these lovely shiny devices aren't going away (phew!), is there a technological fix to being tracked?

I mean, signals need to reach the phone so the location of the phone needs to be known. What is out there that could allow us to use this awesome technology without essentially handing our every waking movement to a 3rd party who can be easily forced to hand the data over?

<comment><USER5> As far as I can see, nothing. You need to authenticate to the cell networks to receive phone calls, and when you do that they get your location. Even if they don't know whose phone it is, it's not very hard to figure out based on where they go.

I simply don't carry a cell phone. I've found it does not impact my life as much as you would expect. I simply make plans ahead of time.

<comment><USER6> Can we at least build a device that tunnels everything we do on the device to one or more servers under our control in other jurisdictions via SSL so that the only information that can be gathered from a device is GPS location data and nothing else?

<comment><USER5> Yes, that's already possible as long as you trust the operating system. But it seems like people are really concerned about the GPS location data.

</comment></comment></comment></comment></comment></comment><comment><USER7> Why don't we stop working on petitions to the whitehouse to let us have more fun with our cellphones and start putting more effort into holding our politicians accountable for things like:

1) letting massive bank fraud slide at the expense of the taxpayer

2) murdering innocent civilians through massive amounts of drone strikes

3) allowing indefinite detention of American citizens

4) spying on all of us via internet and soon to come drones

5) all of the other countless civil liberty and constitutional violations happening

We're the people who affect the most change in our country right now, but we often focus more on the easy issues that benefit us directly and immediately while glossing over the ones that slowly eat away at the principles our country was founded upon.

edit: wanted to continue this rant a little more... I far more often hear stuff like "OMG, I can't believe Instagram changed their user policy and now they technically have a right to use a photo I uploaded in an ad for their company! This is ludicrous and they should be ashamed!" than I do ones akin to "I can't believe the government murdered an teenage American citizen without trial or due process because they believed he might be connected to terrorism." It's a bit sad, this echo chamber we live in.

<comment><USER8> Why? Because our moral and political culture, as a society, is in the shitter. It's probably too late.

<comment><USER9> When was the moral and political culture not in the shitter?

edit:

And when was it not "too late"?

<comment><USER8> Before the destruction of the Enlightenment by philosophers like Immanuel Kant.

<comment><USER10> When I read the 'science of man' and/or 'natural rights' accounts of political society and morality, I am struck my how astute Kant's critique was--that what we call conventional morality can't be found in anthropological conjecture.

But outside of the question of morality, his accounts of political society rest heavily on Enlightenment doctrine--it's basically a tale of the passions. That _was_ the Enlightenment, not so much the rehashed civic humanism/republicanism playing itself out on the streets of Paris. And as for his infamous maxim "Argue as much as you like, but obey" and his specific engagement with questions about what the Enlightenment meant, I would say this is pretty much the mainstream of Enlightenment thought. Sure, sovereignty might lay with the nation, but to emphasize the will of the nation, rather than its legitimate representation, is something fairly unique to Rousseau and the hard-core of the Jacobins.

I know there is a body of scholarship that pins the end of the Enlightenment to Kant, but I'm not familiar with it. Could I have the elevator version?

Edit: Perhaps I've overstepped the mark here. I'd be interested in any recommendations that link Enlightenment to a positive discussion of virtue-- ie. not a discussion of Enlightenment and 'why virtue is no longer required [compared to the classical republican polities]'.

<comment><USER8> So, the original question was "Why is society and culture in the shitter," and my answer was "Kant and his philosophical henchmen." I think the Enlightenment was going in the right direction, but there was a lot of not-so-great stuff there, too. So the Enlightenment is kind of secondary to the point I'm trying to make.

Basically, there were two high points in Western society: ancient Greece, and the Renaissance/Enlightenment* era. Right now, we're not on a high point, and the slope is negative. That's because of the philosophers like Kant that came towards the end of the Renaissance/Enlightenment era.

You are actually focusing on the politics of the Enlightenment, but I'm more concerned with how Kant eventually underminded culture by corrupting things on more fundamental levels. Specifically, the metaphysical level (especially the metaphysics of man) and the epistemological level (especially the functioning of man's mind).

I'm an Objectivist (i.e., I agree with Ayn Rand's philosophy). I know this isn't a popular stance, but extremely few people who criticize it (or even who profess it in the popular media) actually know what it entails, and world- changing ideas are usually universally ridiculed at first, so I hope you'll take me seriously, despite the unpopularity of the ideas I agree with.

So the elevator version is: Ayn Rand is a direct and complete rebuttal to Kant (though not written directly in that manner). You'll have to read her extensively to get the actual rebuttal. As far as supporting the claim that Kant ended the best period in Western history, Rand states this kind of thing, but doesn't try to prove it. Later people (specifically, Leonard Peikoff) have taken up that challenge.

Among other things, Rand holds that man can perceive reality and (ultimately) gain knowledge about it, starting via sense perception. Kant held that sense perception itself acts as a filter that makes true knowledge of reality entirely impossible, basically rendering man's mind impotent.

Rand also has a unique theory of concept-formation, which is critical to establishing a solid epistemology.

Finally, Rand's ethical theory is based on the idea that the is-ought gap can actually be bridged; what is good is what is good for a man. This eventually leads to an actual justification for needing to impose individual rights (in the classic, Founding Fathers sense).

Kant was completely against all the above, and actually made the rise of Nazism, Marxism, postmodernism, and modern egalitarianism possible. In fact, I just though of this, but it's probably right to say that modern "humanistic" political thought is basically a reaction to fascism, but (unfortunately) still within the underlying paradigm Kant made possible.

For example, you need to believe that man has no access to true reality, to believe in dialectical materialism. Same thing to believe in the kind of Nazi racism and nationalism that was rooted in the ideas of the "German subconsciousness".

To elaborate on that: For Kant, the "reality" we experience was created by people's minds. So the German reality (or even the "proletarian" reality) is fundamentally different and incompatible with other "realities," and the only "proof" you need to assert that it is superior is bald assertion that it is so. I do think I'm essentializing a bit here; for example, other people after Kant took his more fundamental ideas to their logical conclusions in ways that may actually contradict other things Kant wrote, and other philosophers helped pave the way for Kant himself.

Anyway, this is just my best (condensed) understanding. I hope to whet your appetite, but don't take me as a representative of other people's ideas.

* And the high point of that era was the founding of the United States, which was the first country to be founded on the idea of the individual as sovereign.

<comment><USER11> As a former Randroid, you have my sympathy and my sincere hope that you too can recover.

<comment><USER8> What's your specific criticism of Objectivism? I'm genuinely curious.

<comment><USER11> Just to start with the low-hanging fruit, Rand contradicts herself by not being an anarcho-capitalist: <http://www.isil.org/ayn-rand/childs-open- letter.html>

Rand might respond by saying anarcho-capitalism doesn't make sense, which it doesn't, but if it's the inevitable consequence of the rest of your philosophy then you must have made mistakes further up as well. As Rand herself said, "check your premises". Specifically, I think the unworkability of anarcho- capitalism scuppers the non-aggression principle entirely.

Rand's (and your) reading of Kant is significantly flawed. From a historical perspective I don't blame Rand for this, as it seems she may have learned this misreading of Kant from her time in Soviet-era Petrograd State University. Admittedly, this is not a criticism of Rand's philosophy but rather her understanding of the history of philosophy, but it speaks to how misaimed your statements are.

<comment><USER8> Anarcho-capitalism is not the consequence of the rest of Objectivism, so that's the specific flaw in your reasoning. (Sorry to be blunt here, it's just easier.)

The letter you linked to is erroneous because, contra what it says, forming a "competing government" is an initiation of force. It is retaliatary force for the actual government to act to stop a "competing government."

(The next two paragraphs are kind of a tangent, the actual philosophical response to your mistake is after that.)

I don't think this is an interesting issue, though. Rand's philosophy is hierarchical: metaphysics, then epistemology, then morality, then politics. Derivative issues in politics are largely "implementation defined." For example, I don't think you can have a government without any taxes at all in today's world, whereas Rand thought no taxes would be the ideal thing to aim for. That issue doesn't have any bearing on whether Objectivism is correct or not.

As another example, I also don't care about who builds the roads, and stuff like that. If we had non-governmental roads from the start, we'd probably all live in private cities, and the world would be vastly different, but we're stuck with what we have, so who cares?

Let me change direction and go to a likely source of your error. Let me give an example. Honesty is an Objectivist virtue, so some people think you have to be honest all the time. That's not true: There is a certain context in which honesty is applicable. You don't have to be honest to a robber asking where your kids are. Likewise, non-initiation of force only applies under a system of laws and government. It's a political principle. It would not apply to people stranded on a desert island. It does not apply to a state of nature. It doesn't apply to people seeking to initially form a government. It also doesn't apply when the government is bad, past a certain "implementation defined" point (i.e., Objectivism doesn't have a specific principle for where that line is - it's too situational).

So, it's an error of context to say that the non-aggression is some universal moral rule that implies that we all have to have anarcho-capitalism. It's not a moral rule, it's a political rule. It's part of the next level up.

This is true in the same way (more or less) that honesty is not a universal moral rule. Understanding the context for honesty requires understanding the actual more fundamental principle it derives from, which is to always act in a way that serves your own life and happiness. (Which, itself, even has a context that depends on hierarchically previous ideas - Rand was not against suicide in the case of losing a precious loved one, for example, if you can't conceive of living happily without that person.)

> Rand's (and your) reading of Kant is significantly flawed.

I don't claim that I can provide evidence for the things I say about Kant, because that evidence presupposes agreement on fundamentals of Objectivism, and that's not something I can provide evidence for either, other than pointing to reality and suggesting someone undertake a multi-year study of the Objectivist literature. So, the stuff about Kant is just intended as a "sampler," something to get someone thinking and maybe intrigued.

Putting the Kant stuff aside, I'd be genuinely interested to see what your reaction (again) to what I've said.

(Two more tangential paragraphs follow.)

By the way, normal people do not have the epistemological background to _not_ make errors that have to do with disassociating abstractions (concepts, principles) from the concretes they refer to. Ayn Rand calls that "rationalism," and I think that's the category in which your mistake falls. Many normal people (especially those drawn to programming) habitually think this way. That's how I was for most of my life, and the only thing that kept drawing me back to Objectivism was honestly realizing that nothing else made sense, and knowing that there was more background to Objectivism that I still lacked.

Most people who aren't rationalistic people just don't trust abstractions _at all_. For example, pragmatists who say that there are no rules, or people who say that no knowledge is really trustworthy. This is throwing the baby out with the bathwater.

<comment><USER11> > forming a "competing government" is an initiation of force

How?

> I don't think this is an interesting issue, though. Rand's philosophy is > hierarchical: metaphysics, then epistemology, then morality, then politics. > Derivative issues in politics are largely "implementation defined." For > example, I don't think you can have a government without any taxes at all in > today's world, whereas Rand thought no taxes would be the ideal thing to aim > for. That issue doesn't have any bearing on whether Objectivism is correct > or not.

Surely one derives from the other, and contradictory conclusions at one level should indicate flaws at a higher level. "Check your premises."

> So, it's an error of context to say that the non-aggression is some > universal moral rule that implies that we all have to have anarcho- > capitalism. It's not a moral rule, it's a political rule. It's part of the > next level up.

Then surely this defines Objectivist politics down towards nothing at all, since it can be violated at the point where it's necessary for a government to maintain monopoly over the use of force, and it can be violated before there's a government, and so forth.

If you want to abandon Objectivist politics entirely you may, but the main selling point of Rand is her ability to derive "privately owned roads" from "the validity of the senses" (qua "concepts in a hat": <http://mol.redbarn.org/objectivism/ConceptsInAHat/>)

> I don't claim that I can provide evidence for the things I say about Kant, > because that evidence presupposes agreement on fundamentals of Objectivism, > and that's not something I can provide evidence for either, other than > pointing to reality and suggesting someone undertake a multi-year study of > the Objectivist literature. So, the stuff about Kant is just intended as a > "sampler," something to get someone thinking and maybe intrigued.

The stuff about Kant is, to give largely the same handwavy explanation, utterly wrong as well. Rand may have built up Kant as a kind of straw man, but this isn't an honest or realistic reading of Kant. Rand's misreading of Kant is an honest mistake and a historical accident, not a useful introduction to Objectivism.

> normal people do not have the epistemological background to _not_ make > errors that have to do with disassociating abstractions (concepts, > principles) from the concretes they refer to. Ayn Rand calls that > "rationalism," and I think that's the category in which your mistake falls

I think it's Rand who makes this error by making measurement omission so central to her epistemology.

> the only thing that kept drawing me back to Objectivism was honestly > realizing that nothing else made sense

It's interesting that you have this psychological need for everything to make sense to you within a comprehensive system. This is the biggest and most problematic appeal of ideologues and systematists in philosophy, whether Rand or Hegel.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Is Google allowed to disclose the number of FISA requests it gets? I was under the impression NSLs were being used much less since the PATRIOT Improvement and Reauthorization Act (2005) weakened them, and were largely replaced by obtaining secret warrants from the FISA court.

FISA is scarier. Under that law, secret surveillance can begin before a warrant is issued, warrants are issued by judges who keep no records of their opinions made in complete secret, and the surveillance can continue even during a challenge over and appeals of that warrant. When the EFF made a FOIA request for information about the FISA court, it got an ominous response: a letter saying there were documents they'd never see, zero court records, and a completely redacted version of an investigation into FISA's constitutionality. By completely redacted, I mean they returned pages where every word on every line was blanked.

The only difference is that a FISA warrant has to be connected to a foreign person or body in some way. That can be as little as "we think by wiretapping this American, we'll learn something about this organization in another country". For those not living in the US, it means Google/Facebook/Microsoft/etc. can be compelled to surveil your communication through their service secretly without an NSL.

<comment><USER13> If you're a foreign national on foreign soil with data in us data centers held by us companies I don't believe it's common practice for these companies to require a warrant, fisa or otherwise, to share information with national services.

Consider the case of the NSA warrantless wiretaps. The telcos were voluntarily providing bulk access, there was only a legal issue because US citizens on were involved.

<comment><USER14> Didn't they get around that by deciding that copying the data and storing isn't considered "search", only when a person accesses and looks it when the Constitution starts to get in they of "business".

I would pretty much guess that is the purpose of the data storage center NSA is building in Utah -- to just archive everything sent anywhere.

It would also seem that when a warrant is obtained it is obtained for historical data and there is no window. So if you commit some act that is deemed dangerous enough to issue an warrant to search your history -- theoretically all your history since birth could be searched. Everything you ever did online that was recorded becomes game.

</comment></comment></comment><comment><USER15> None of this is a surprise. Google does business in the USA, and is forced to follow US law. Which it does. Despite the USA not being nearly the country that I wish it was on these matters, on the whole the USA is not horrible either.

See [http://communications-media.lawyers.com/privacy-law/Your- Ema...](http://communications-media.lawyers.com/privacy-law/Your-Email-isnt- as-Private-As-You-May-Think-It-Is.html) for a glance at what is and isn't protected here. See this article for an idea of how tiny the affected numbers are in the USA.

What is far more troubling is that Google _also_ has to follow the law in _other_ countries that it does business in. Many of those countries have different laws and corruption levels than the USA. While Google did choose to stand up to China, they don't in many, many other countries.

In fact I am personally aware of an HN user outside of the USA who was physically tracked down through information coughed up by Google in response to bogus legal requests. (I will not confirm or deny any information about this case beyond what I just said, so don't bother asking.) My non-US social circle isn't that big, so if I'm personally aware of it happening, how many people does it happen to that I don't hear about?

Frankly the non-US situation scares me more than the US one.

<comment><USER16> Indeed. Also on the "bright side interpretation" is the fact that only about a thousand of these NSLs are issued per year (and given Google's size, that's probably a good guess at the total number of such investigations). A thousand isn't small, but at the same time it's only a tiny fraction of the number of law enforcement investigations. At least this is proof the NSL mechanism isn't being used for blanket surveillance state activity. That's something.

<comment><USER17> What if the questions being asked are more along the lines of, please give us the full account archive of everyone who's ever emailed an address in a .ir domain? Or, here is a semantic filter that you must apply to all mail that transits your system, hand over everything related to any account sending or receiving mail that it evaluates as a match.

Given the lack of transparency, and the fundamentally undemocratic nature of the National Security Letters infrastructure. It would be a good idea if we had a list of the sorts of things.

Personally, I'm comfortable with a few civil liberties being trampled in pursuit of loose nukes and engineered plagues; but I'm much less sympathetic to a policeman who wants updated intel on what a bunch of hippies are planning to write on their signs at the next Occupy protest.

<comment><USER16> They appear to have counts for impacted users, which are of the same order. So your worry about unbounded access is unsupported by the data.

I'm not saying this _can't_ be an infringement on fundamental rights, or that it's a good program. I'm saying that, given the data at hand, it does not appear to be the blanket surveillance program that many people (including you, c.f. your first paragraph) think it might be.

That's a good thing, right?

</comment></comment></comment></comment><comment><USER18> This headline is quite misleading. Nowhere in it does Google actually state what the article claims in any way.

If anything, what makes me happy is that Google can even disclose any of this at all. NSL's are a tool that has little oversight and a bit more awareness may help keep them from being abused.

<comment><USER19> I'm happy Google has found a way to disclose this, too.

The headline ("Google Says the FBI Is Secretly Spying on Some of Its Customers") seems fair to me.

Google is reporting that it got more than 1 and less than 1,000 "National Security Letters", about more than 999 but less than 2,000 of Google's customers. Because the exact subjects of these letters can't be shared, the FBI's actions are being done "secretly". Because they allow the FBI to receive private information it wouldn't otherwise have without the subjects knowing, this activity fits the colloquial meaning of "spying". All the elements of the headline are supported by the reporting.

<comment><USER20> If we had an estimate of the number of in-links and out-links in the inbox, we would have a more accurate sense of the number of people whose communications were actually swept up under this surveillance. The number might be more accurately portrayed as "greater than 49,950 and less than 100,000 people" assuming the typical mailbox contains traffic from 50 people. Not all would be Google's customers, but it would portray the scope more clearly.

<comment><USER21> If you read the whole article closely you'll find this:

Google noted that the FBI may "obtain 'the name, address, length of service, and local and long distance toll billing records' of a subscriber to a wire or electronic communications service. The FBI can't use NSLs to obtain anything else from Google, such as Gmail content, search queries, YouTube videos or user IP addresses."

So inboxes are not being opened up for the FBI as part of these requests.

</comment></comment></comment></comment><comment><USER22> "Google says some of its customers are the target of authorized FBI investigations, but we've got to sex it up for Threat Level"

</comment><comment><USER23> I tend to think these National Security Letters violate the 4th Amendment by authorizing warrant-less searches and seizures - but is it really a secret the US government is doing that?

Wireless searches of phone calls, Internet activity (Web, e-mail, etc.), text messaging, and other communication has been public knowledge since Attorney General Alberto Gonzales confirmed the existence of the program, first reported in a December 16, 2005, article in The New York Times. [http://en.wikipedia.org/wiki/NSA_warrantless_surveillance_co...](http://en.wikipedia.org/wiki/NSA_warrantless_surveillance_controversy)

In 2006 EFF filed lawsuit against AT&T after the US government installed monitoring equipment in an AT&T's switch room. <http://en.wikipedia.org/wiki/Hepting_v._AT%26T>

Warrantless searches and seizures and monitoring? Please that is so...1984. On August 30, 2010, the CCR and ACLU filed a "targeted killing" lawsuit, naming President Barack Obama, CIA Director Leon Panetta, and Secretary of Defense Robert Gates as defendants. They sought an injunction preventing targeted killing of US citizens, and also sought to require the government to disclose the standards under which U.S. citizens may be "targeted for death". Judge John D. Bates dismissed the lawsuit, holding the claims were judicially unreviewable under the political question doctrine inasmuch as he was questioning a decision that the U.S. Constitution committed to the political branches.

Back to the OP the only thing that shocks me is that Google and/or the individual employees, who are being personally slapped with a non-court ordered gag-order, have not sued the US Government. I am sure the EFF or ACLU would join as co-counsel to defer some of the resources, and if Google keeps complying maybe they will sue Google like EFF sued AT&T.

</comment><comment><USER24> The FBI may be spying on some of Google's users, but the odds that they are spying on Google's customers is pretty slim.

</comment><comment><USER25> I don't know about you, but the article points out those complying with NSL demands blindly even wrote NSLs for the FBI. That's pretty scary.

</comment><comment><USER26> Anyone else notice that the United states is more than __every other country in data request and 14* in user accounts. The percentage of data produced being almost 100% is just scary beyond belief.

</comment><comment><USER27> Yeah, and I heard that the government used to get these things called wiretaps to listen in on people's conversations, and THEY DIDN'T EVEN TELL THE PEOPLE THEY WERE LISTENING IN. Imagine that.

Google is doing the right thing by publishing information that allows us to see the scope of the activity by the government. If part of an active investigation, then there's no need for anything further.

</comment><comment><USER28> So are Google saying that there should be ZERO ability for law enforcement or TLA's to enforce the equivalents of HOW's (home office warrants) on their customers.

If you don't like the heat don't run gmail G+ and get out of the phone biz.

</comment><comment><USER29> I would be surprised if they were not "secretly spying".

</comment><comment><USER30> It's headlines like this that make me wonder if my Give-a-fuck isn't just broken.</comment>


Why you should never ask permission to clean up code. - <AUTHOR> http://cdevroe.com/notes/code-maintenance-dont-ask/ <comment><USER2> _never ask for permission for things you know are vital to your work_

I agree to an extent. It can be easy to fool yourself about what constitutes good code -- in the sense of making a product better or work on it easier. Sometimes bad code is better left as is. Even working totally unconstrained, I prefer not to refactor something unless I have a pressing _reason_ in mind.

My rule of thumb is this: as a programmer and an employee, I am professionally bound to produce quality software efficiently. If I know I can complete an assignment faster (or in equal time, but leaving behind a better code base) by rewriting something, building a tool, fixing something architectural . . . I will silently do it. No point in asking permission. It's in my charter.

On the other hand, if I want to take a lot of time to rearchitect something -- an order of magnitude more than it would take to just do whatever it was that brought me there -- at that point, it's a strategic decision and management deserves to know about it.

The way I see it, management has no right to require me to produce an unprofessional product in my day to day work. And I have no right to force management to use engineering considerations only in strategic decisions.

<comment><USER3> Then again, refactoring without permission could be a really bad idea. You need to ask yourself a few questions before you proceed.

Do you have thorough unit tests for the code that you are trying to refactor? If not, be aware that there is no way to know for sure that your refactoring won't break the functionality of the code.

Suppose it breaks the code. Have you thought about the operational impact to clients and the financial costs?

Let's say the costs are low. How big and political is your organization? What kind of trouble will you find yourself in? As the hysteria rises, will you be fed to the dogs over this?

How bureaucratic is your company and how many people do you need to interact with to fix a functionality breakage? The more people you will need to interact with, the more damage you will do to yourself and your reputation. Others will resent working in panic mode to clean up after you (now widely known as the "rogue" programmer).

<comment><USER4> These considerations apply to a much lesser extent if you're at a shop that uses version control.

<comment><USER5> Are there really still shops that don't? It's not like it costs money.

<comment> T-hawk Oh heck yeah. We at HN are immersed in tech. Our experience is with companies whose core domain is tech and take things like source control for granted. But what about your local gym or sports franchise or restaurant chain or newspaper? There are millions of companies that don't have any kind of technical director or direction. Where some manager thought it would be a good idea to have a web site, and hired a programmer who's measured on how fast he can throw it together. What's a testing server? Heck, what's a server?

</comment></comment></comment></comment></comment><comment><USER6> This is something that took me 2 years or so to learn. One day I realised nobody was really looking at my timecards in depth so I started allocating extra time to things and using the extra time to fix the things I thought needed fixing. Once I started delivering on this I showed my manager who agreed that it was a good use of time. I was given free reign to fix anything I felt would add maximum value, provided the bug fixes continued to be delivered without any major compromise.

Since that time I have refactored quite a few of our codebases; added unit tests, fixed some build processes, improved performance and generally feel happier at work for getting things done that are important to me.

Dont get stuck in constant bug fix mode would be my suggestion. If you cant get approval to fix things then change jobs because bug fix after bug fix is depressing and will bring you down.

<comment><USER7> This is awesome.

<comment><USER8> That's what the up arrow is for.

<comment><USER9> Sure, but considering this is the author of the article we're commenting on, I think an exception is reasonable here. I'm interested in which comments the author's aligned with. It's a discussion, after all.. one that this person started. I'm not saying vote up.. but we could lay off the down arrow.

<comment><USER8> Fair enough. I admit I hadn't noticed it was the original author making the comment.

</comment></comment></comment></comment></comment><comment><USER10> The reasoning behind _not_ cleaning up your code is that if you wait long enough, the problem will often go away - literally! Technology moves fast enough that your feature is usually obsolete within a year or so; if you're not on the critical path that everyone is building upon, chances are your project will just be canceled and all the time spent polishing your code will be wasted. Better to get stuff out there so you have a better chance of being on that critical path, and dealing with the inevitable messes and complaints of "this is shit code!" later.

This is the "cascade of ADHD teenagers" development methodology, which is much maligned by professional programmers, but actually seems to work quite well. Google, FaceBook, and Twitter all use it to varying extents, and the entire valley startup ecosystem is based around it.

<comment><USER11>
      > Technology moves fast enough that your feature is
      > usually obsolete within a year or so

That depends on your industry. My company has some core infrastructure running on code written in the 90's when characters were scarce (8-character variable names) and actual loops were even scarcer (goto's instead).

Feature-sets like "processes transactions" never go away just because technology moves forward. Some of that almost feels like you've had "too much of the Kool-aid."

<comment><USER10> My company barely existed in the 90s - it was some research project at Stanford.

And feature sets like "processes transactions" absolutely do go away because technology (and its applications) moves forwards. This was a large part of the success of MySQL: relational databases started getting used in applications where transactional integrity really wasn't that important, and they were better off working around it (or just showing inconsistent data to the user) rather than paying the price for transactions.

Or look at this recent discussion surrounding Google Megastore:

[http://glinden.blogspot.com/2011/02/comparing-google- megasto...](http://glinden.blogspot.com/2011/02/comparing-google- megastore.html)

Megastore suffers a large latency penalty for ACID semantics. In many applications, it's better _not_ to take that latency hit and instead settle for eventual consistency instead.

<comment><USER11> I meant transactions as in actual exchanges of money, not as in the computer science / database term.

<comment><USER10> Financial apps are a different story. I interned on Pay.gov in college, and then spent the first 2 years of my career at a financial software startup. The standards are _much_ different when you're handling money (or avionics, or medical devices, or anything that's "mission critical"). And even in the finance world, the standards vary a lot depending on whether you're doing analytics or transaction processing.

But while that software will never go away, it becomes a smaller part of the whole software industry. Much of the interesting growth is in areas of software that have nothing to do with money, other than being able to make it. It's silly to apply the same standards to software that processes $10M/sec (as one program I once wrote did) as to software that lets you throw virtual sheep at each other.

<comment><USER11> I also think that it's silly to assume that all software follows the same rules as software that allows you to throw virtual sheep at each other.

</comment></comment></comment></comment></comment></comment><comment><USER12> I'm sorry to see that the owner of promosthatrock.com has let the site they set up at colindevroe.com fade away (presumably the domain expired).

It included a full archive of his email exchange(s) with Colin Devroe, chronicling the frustrating experience of paying a developer thousands of dollars and then getting the runaround for months and ultimately getting nothing for their money.

If you have the patience to use the wayback machine, give it a look. Perhaps the customer Colin ripped off will see fit to comment here as well.

[I'm a longtime HN user with a handle connected to my real name - I don't want to get into it with Colin, but I know him (he took me for a couple grand also) and it bothers me enough to see him on the HN homepage giving advice to a community I respect that I'm posting this]

<comment><USER7> It stinks that you're deciding to remain anonymous. If I "took you for a couple grand" I am very sorry about that but I can not defend myself there without knowing who you are.

That being said, the promosthatrock situation was over 7 years ago. I definitely made a mistake there and do not deny it. Again, if I wronged you then I am sorry.

</comment></comment><comment><USER13> From the article: "Can I take some time to clean up this code? It is horrendous." The answer should always be yes to this question.

No, it shouldn't. This entirely depends on the long-term prospects and importance of the code. Assuming that your boss is doing his job, he might understand the trade-offs between having you doing 'code gardening' in subsystem A vs. building new functionality in subsystem B. He may even understand them better than you.

Mileage varies, of course, depending on Pointy-Hairedness.

<comment><USER7> I think the perspective I was taking in my post was that many bosses do not fully understand the inner-workings of the codebase for their own product and they also don't need to maintain it. So developers truly are the best person to help weigh the need for maintenance.

Of course, there are bosses that fully understand all of this and if you're lucky enough to work for one - awesome.

<comment><USER13> The other point here is that the new code is new code.

The old code may have been old, but maybe it has been running for a long time without problems. Maybe some of the ugliness of the old code has to do with handling bugs and corner cases that the programmer has forgotten about.

The boss may not have to maintain the codebase and maintain the code, but he/she may have to take the heat for things when someone goes and breaks code that was ALREADY WORKING with their rewrite.

"Why did you let this idiot break our product?" will be the question that the boss will be asked, in this question, and when they say "Well, I didn't know that he was making changes for no reason" someone is on an express path to getting fired.

<comment><USER14> > Maybe some of the ugliness of the old code has to do with handling bugs and > corner cases that the programmer has forgotten about.

That's why I add comments to counter-intuitive pieces of code, often with a ticket number or a short explanation what goes wrong otherwise.

</comment></comment></comment></comment><comment><USER9> You shouldn't ask permission for it because on most of the time you shouldn't be doing it. It's like going to the grocery store hungry, without a shopping list.

I'm a big believer in:

1\. You don't modify code without intent to change it's behavior. You're there to fix a bug, or add a feature.

2\. You leave the code you better than you found it. In fact, you elevate it to your/the-team's standards du jour.

3\. That's the cost of doing business. There are no multiple estimates. It's not _"Well, an hour to just fix it with a hack but it really deserves a day"_. That's a day. Deciding on the team's values and coding standards is a group- decision. Deciding on when to apply them isn't.

<comment><USER4> "You don't modify code without intent to change it's behavior. You're there to fix a bug, or add a feature."

This makes a lot of sense. If you clean up code on anything other than a just- in-time basis, you risk fixing up something that will never need to be modified before it goes out of use.

Choosing coding standards makes a lot of sense too. If you're coding a MVP, the probability of code going out of use is higher and your standard should be lower. Your team's comfort level with modifying dirty code (how much does it demoralize them? does modifying dirty code fit with their style?) is another consideration.

I think it could make sense to vary the desired code quality depending on the personality of its primary maintainer and how likely it is to get thrown out. A corollary is that if different coders on your team have different preferred levels of code quality, you should assign them to different parts of the project on that basis.

I think there is a fair amount of room to apply microeconomics-type thinking here, along with behavioral economics-type thinking about what biases (e.g. hyperbolic discounting) might cause one to choose the wrong level of code quality. And there's also the opportunity for professional development as coders become more comfortable programming at different spots on their personal output speed/code quality potential possibility curves.

<comment><USER9> Thanks. Regarding _'dirty code'_ though, you've reminded me of another point I believe in.

4\. All code is temporary. I said _du jour_ for a reason. It's all wonderful for a little while, but there's no such thing as "Okay, that's been refactored now", in an lasting sense. We're building and maintaining sand castles. Either the world around the code changes, or our opinions about it do. _"dirty"_ code doesn't exist to me, at least not in some conveniently boolean state. The half-life of a piece of code depends on a number of variables, but there's no such thing as code that doesn't start decaying the moment if leaves your keyboard.

So yeah, it's all dirty, pretty much.

<comment><USER4> But code can be _dirtier_ if its implementation was poorly thought out, half of it was modified to reflect new assumptions while the other half was worked around and left intact, etc.

</comment></comment></comment></comment><comment><USER15> My algorithms professor engrained an idea in me that has stuck throughout my career: first you make it work, then you make it better. When it comes to code, we want an almost mathematically-provable correctness, but the real world doesn't care. The real world cares about getting something that solves their problem; ugliness, code smells, and technical dept are irrelevant to them. So I wouldn't write off the managers and their fancy business needs as just some conspiracy keeping good coders down. I think this need for pragmatism is something that separates a computer scientist from an engineer.

It goes both ways though. Sometimes the shit is just terrible. When the cost of any change is introducing a new bug, you've got to take a stand and I think your insight is spot on here. The developer is in the best position to know when the cost of change has gotten to high. I don't bother asking permission, but I've never had to ask forgiveness either. The manager is my customer: he just cares that what comes out of me works, and because I stop to clean up, it does.

</comment><comment><USER16> This article is kind of the equivalent of saying if one aspirin is good, ten must be great.

The better logic for follow, when cleaning code, is the concept of technical debt (<http://gettingreal.37signals.com/ch10_Manage_Debt.php> or [http://www.codinghorror.com/blog/2009/02/paying-down-your- te...](http://www.codinghorror.com/blog/2009/02/paying-down-your-technical- debt.html)). Essentially the concept is that quality code is an investment, and hacked code is a loan. Too many loans and you'll file bankrupty, too much time on quality and you'll not be able to build fast enough - balance is key. This idea is easy for everyone, from noob to pro to manager, to understand and establishes a common lingo.

As a manager, if I found a fresh code monkey doing nothing but assuming they had the aptitude to pay down my standing code depts, I'd promptly show him the door for grossly undervaluing the abilities of his peers.

<comment><USER17> It isn't quality that stops you from building fast enough, it is yak shaving in the guise of quality.

Programming is a weird thing, unlike almost everything else higher quality almost always translates to lower costs and faster delivery.

To explain this counter-intuitive phenomenon, partly this is due to the exponentially increasing costs of fixing bugs.

E.g.

fixing a bug at design time = $1,

fixing it at coding = $10,

fixing it during testing = $100,

fixing it once it has been deployed = $1000.

\----

Also, the phrase "code monkey" is no longer politically correct. The correct phrase is "software simians" :D

<comment><USER16> Can anyone in the web-based software realm back up that scaling costs mythos? I get it in the hardware realm, and to a lesser extent in the distributable software realm... But having worked with everyone from Salesforce.com to Facebook to Amazon, I've never seen any indication of exponential costs from coding to testing to deployment - at worst I would say it is linear.

<comment><USER17> See also:

[http://www.superwebdeveloper.com/2009/11/25/the- incredible-r...](http://www.superwebdeveloper.com/2009/11/25/the-incredible- rate-of-diminishing-returns-of-fixing-software-bugs/)

If I recall from my Software Engineering courses this is based on research that IBM did, back when they still did research into this sort of thing.

There is nothing magical about the "web-based software realm" that separates it from other sorts of software and development and allows it to bypass the issues that cause the cost of fixing a bug to sky-rocket like this the later in the process you leave it.

<comment><USER10> "There is nothing magical about the "web-based software realm" that separates it from other sorts of software and development and allows it to bypass the issues that cause the cost of fixing a bug to sky-rocket like this the later in the process you leave it."

Sure there is - _people writing easily deployed consumer software don't write code like this_. It's crazy to spend months designing software, based on things you _think_ you know, when you could just build and release it and have far more information in far less time. Anyone who writes software where the deployment cycle is measured in minutes to hours (that's anyone on the web, or desktop or mobile apps with auto-updaters) relies on an iterative process of code -> release -> gather data from real users -> refine the product -> repeat.

People who don't do this get creamed in the marketplace, because their competition _does_ , and their competition gets far more information to build a better product through it.

Most of the stuff taught in Software Engineering courses is complete bullshit when applied to the types of problems that actual practitioners face. This is because the field of software engineering is far broader than most people can imagine, and certainly more than you can teach in an undergrad education. A development cycle like you site is pretty much the norm if you're writing embedded microcontrollers for avionics (actually, the cost increases are probably even steeper). Very few people are writing embedded microcontrollers for avionics. For the majority of us, who're working on software developed and deployed over the web, the cost curve you cite is ridiculous.

<comment><USER18> Meh.

The best web developers I know are also the fastest I know; they write unit tests like crazy. They write good code.

I guess you're assuming that writing good code takes longer, which is the basic fallacy in software engineering. Writing good code is way faster, almost from the get-go. You reap the benefits on _day two_, literally.

I am not sure what they taught you in SE - I found most of what I learned to be true in the field, however, I also found it shocking how little this seemingly common knowledge is used out there.

I directly benefit from the incompetence of most software engineers out there, but I much prefer to work with good people.

<comment><USER19> _The best web developers I know are also the fastest I know; they write unit tests like crazy. They write good code.

I guess you're assuming that writing good code takes longer, which is the basic fallacy in software engineering._

You keep saying this as if you believe that writing unit tests automatically means you've written good code. You can possibly have good code without unit tests. You can, more importantly, have awful code _with_ unit tests.

For me, a major axis of "good" for code is maintainability. Therefore, writing good code means spending some time considering names rather than just using the first ones that pop into your head as you type. It means thinking about whether these superficially similar pieces of code are really related enough for code reuse to be beneficial, or whether it's only incidental similarity and really should exist in both places independently in your codebase. It's about writing small pieces of functionality yourself when otherwise you'd drop in a library that dwarfs your written code -- sure, dropping in the library is fast and easy, but if something goes wrong, you're now debugging 100K lines of someone else's code instead of the 1K lines of in-house code it would have taken to do just what you needed...

Writing good code in this way often takes considerably longer than just cranking out something that works for now, and the largest factor is not time to write unit tests, but time to _think_ about what you're doing rather than coding at the speed you can type.

<comment><USER17> "You keep saying this as if you believe that writing unit tests automatically means you've written good code"

Actually he didn't state there was a causal link between writing unit tests and writing good code. In fact, if you look closely, you see that there is a full stop in between those two statements, they are in different sentences!

I'd happily believe that someone who writes good code can also write good unit tests.

I'd also strongly assert the negative of that. Someone who writes bad code _cannot possibly_ write good unit tests, because unit tests _are_ code.

Everything else you say I agree with 110%. Good names for code entities: yes, indeed. Taking some time up front and _thinking_ about the design and how it will fit together... yes, a thousand times yes.

However, the last bit about it taking longer to do this than just cranking something out I (and I think the person to whom you are replying) would disagree with _except in the most trivial cases_.

If what you are doing can be done by banging out a perl one-liner, by all means do that and move on. Except that of coruse if you _ever_ need to debug it or maintain it there is a higher cost involved. For all code, _as soon as you start debugging it_ you start reaping the rewards of doing it properly. For _non-trivial_ code, those costs will rapidly outweigh the initial savings of just banging something out.

<comment><USER19> _Actually he didn't state there was a causal link between writing unit tests and writing good code. In fact, if you look closely, you see that there is a full stop in between those two statements, they are in different sentences!_

Well, idiomatically, the second sentence is a kind of restatement of the first. My comment was really a reply to all nikster's similar comments in this page; he's talking about unit tests, and those he's talking to are mentioning good code, so it seems as though he believes that good code is essentially the same as "have unit tests", which is what I took issue with. :)

 _For all code, as soon as you start debugging it you start reaping the rewards of doing it properly. For non-trivial code, those costs will rapidly outweigh the initial savings of just banging something out._

I actually don't disagree with this at all. It's just that I don't think the costs will necessarily be in hours spent, though sometimes they will be. Sometimes the cost will be that you have to find someone at least as smart as the original coder, and that might be hard. It might be so hard that hiring someone to completely rewrite the system from scratch might be cheaper.

So, I'm not saying that people shouldn't take the time to write good code. I'm saying that it's possible to write working code at the speed of typing for some people on some projects, and this can be kept up for long enough for the savings to completely outweigh the other costs if the number of bugs is small enough. I wouldn't recommend depending on this being possible for a given team and project, but I've seen it done -- I've done it myself. The result wasn't what I'd call good code, but it worked and it was done in time to be sold for enough to keep the wolf from the door; if I'd spent half my coding time writing tests on that one, I would simply have failed to deliver.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> As long as you are the only person usually working on the affected parts, sure. Just go ahead.

But if multiple people are working with this component or are calling it (in case you want to fix a broken interface), I think some discussion with your fellow team members would be in order as they will have to adapt to whatever you produce.

I agree on the general sentiment of not telling the boss though: It's hard to make non-programmers understand the burden that is ugly code. They think in features and whether something is "visible for the customer" (if it isn't, then it might as well not exist).

Such an attitude can lead you to having to make a decision when implementing a feature: "Oh - this code here is really shitty. I could now a) clean this up and cleanly add the feature or b) just hack the feature in somehow, maybe breaking encapsulation a bit more"

Bosses and people concerned about their free time think b), I tend to think a).

The problem with b) is that you get to your goal much more quickly (which the feature-oriented people like as it makes you seem more productive), but you are incurring dept. Now the bad code just got worse until at one point, something really breaks badly and then you WILL have to pay the price for cleaning up. This might very well be at a time where you are pressed by some deadline which means a lot of after-hours work for you.

Then again, in a team, the might or might not be you that has to clean up (you certainly hope it isn't you).

So doing it the quick route isn't just irresponsible to the project, it's also irresponsible to your team mates because they might be the unlucky ones the bad code breaks over.

So if possible, try to take those extra hours to do it the clean way. The product as a whole will get better and your team mates will not be pissed if they have to clean up your mess.

</comment><comment><USER21> _Why is this the typical reaction? Because bosses don't have to read, edit and support the code._

I dunno about that -- mine actually watches SCM check-ins and flips out if there's some unauthorized code cleanup happening (it "adds risk", supposedly).

And yes, I've also been asked to remove unit tests because they were "making things break" (really just causing builds to fail if a regression was introduced).

<comment><USER22> Time to move on?

<comment><USER21> I've mentally checked out of this place for quite a while already.

</comment></comment></comment><comment><USER23> I disagree with this article for several reasons:

1) Cleaning up code adds 0 value to the customer today. It may add value for the customer down the road, but see #3

2) Most engineers underestimate the time & effort to clean up code without altering it's behavior, and any alteration of its behavior is almost certain to introduce regressions and/or bugs

3) If you knew for certain that your code was still going to be used and hacked on 5-10 years from now, then it would probably be a net positive, but you can't predict that. If you think you can predict that, you're wrong.

</comment><comment><USER24> While I agree with the concept 100% - doing this could land you in trouble if you're billing for your hours.

My approach is different (I run a consulting company): when we take over existing code base, I always talk about it upfront with the client: "we're going to take 10% of the time to clean up the code and do necessary refactorings". I then explain to them about technical debt and broken windows theory. Works about 95% of the time - and funny thing is, clients that don't agree with it, end up not working out anyway ...

<comment><USER18> I bill for hours and I'll definitely go and refactor something - but only if I need to touch the code anyway in order to implement a new feature or fix a bug.

I'll fix _every_ bug the right way, the first time; that may involve refactoring underlying design weaknesses that caused the bug in the first place. I also make sure that this or a similar bug don't happen, which also may cause refactoring.

No one's ever complained... I guess that's because it's actually very time efficient in the medium and long term, and usually also in the short term.

</comment></comment><comment><USER25> A good boss will say, "Sure, just make certain that you have adequate unit tests and code coverage before you start cleaning it up."

</comment><comment><USER26> Great idea until your code clean up creates a bug that isn't in the original 'ugly' version and suddenly you've gone from not asking permission to begging forgiveness. Depending on what you're working on that might be too great a risk.

</comment><comment><USER27> This is highly subjective. There is often much more at stake than clean code. On one end if you are shipping source code to an SDK of some sort, the clean code is extremely important, as it is documentation for your users. But, if it's an ancillary system on an internal project, well, sorry, but it probably isn't worth the time cost and risk of introducing new bugs by refactoring. Talk to your boss about it. If they can't articulate the reasons why it's not a good idea to clean up that code, then you should get a different job. Also (self promotion), see: [http://www.jdconley.com/blog/archive/2009/01/26/put- down-the...](http://www.jdconley.com/blog/archive/2009/01/26/put-down-the- abstract-factory-and-get-something-done.aspx)

</comment><comment><USER28> The real issue is that you shouldn't have much code to clean up in the first place.

If you occasionally need to hack something out to ship it before its effect is lost — go for it. Clean it up the next time you touch it.

If you're constantly writing code under pressure like this, you have a management problem. Your boss probably doesn't code. Sucks for you.

If someone constantly ships poor code, you have a talent problem. Mediocre talent can kill a startup. Get rid of the bad apple ASAP.

<comment><USER29> It's not just poor code which does it, it's code that has become tangled due to subsequent extensions and interactions.

Also, hopefully after a few months of project and codebase specific work, better ways to do what you did will start coming to mind - that's not the same as being a poor coder in the judgmental sense.

</comment></comment><comment><USER30> I'm surprised noone pointed out this post from Sriram Krishnan, a product manager at Microsoft:

Stuff I've Learned at Microsoft [http://www.sriramkrishnan.com/blog/2009/12/stuff-ive- learned...](http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned-at- microsoft.html)

"Ask for forgiveness, not for permission ... Any sufficiently large institution has something to lose...Corporate systems are optimized for saying no. Maintain the status quo. No risk of failure and a spectacular blowout...This is exactly why you are better off going ahead and doing something without asking first. If you don't ask, no one can tell you to not do it."

I'd argue that the specifc principle "never ask permission to clean up code" can be generalised to "never ask permission", especially for software houses that have grown large and sclerotic. But YMMV; in a previous job I once told my manager I had an exciting idea for an automated test platform that I'd be willing to implement and test in my free time. His response was "And when you're finished, who's going to maintain it? I'd need to hire someone at least as skilled as you to keep it running. Please don't make it."

</comment><comment><USER31> At my current job, I basically started cleaning up code in my spare time, just because I was leaving. But just deciding, oh wait, I'll just ignore my boss, and whatever culture is in place, on company time, is basically saying "I'm inexperienced."

Someone here recently talked about a factoring algorithm that some entry level programmer just decided had to be "cleaned up." He had to be lectured about the bits he failed to understand.

</comment><comment><USER32> I think this depends on how experienced you are. If you are only a few years out of University, then perhaps you should go and find the original author and ask them _why_ the code is the way it is, before you dive in to "fix" things.

On the other hand, if you've got decades of experience then you probably know what you're doing - don't waste time, just get on with it.

</comment><comment><USER33> Be _very_ careful starting down this road though ... _especially_ if you don't have tests in place or are not intimately familiar with the codebase or you might find that your 4 hour sugar high turns into a nightmarish week of trying to fix random bugs from your refactoring effort.

</comment><comment><USER34> If you do clean up code, please put it in a separate commit, not mixed in with semantic changes. Thanks!

</comment><comment><USER35> How long the application is supposed to live, should be relevant here. Some stuff can be a piece of crap, even if it goes against some sensibility of a developer, if it isn't suppose to live long and can give you something back. Some times it should be up to the people that know how long it'll live. It's first when you make the money to pay for the refactoring, you should do it.

But hey, make it perfect from the get go ;)

I know, temporary stuff has a tendency to become permanent. But if you see this trend, then you and your manager should be grown-up enough to have the discussion of rewriting it for something more longterm. (It all depends on what sort of project it is).

Long term projects should never voluntarily allow technical debt. It's just bad for business.

</comment><comment><USER36> Simple rule of development: You should always leave code in better shape than you find it.

<comment><USER37> Sounds like a hacker's spin on Dan Savage's campsite rule.

[https://secure.wikimedia.org/wikipedia/en/wiki/Savage_Love#....](https://secure.wikimedia.org/wikipedia/en/wiki/Savage_Love#.22Campsite_rule.22)

</comment></comment><comment><USER38> Standard practice should be to refactor as necessary as part of any major code change and to always leave a code base cleaner than you found it. With that you only need a few targeted dedicated code clean-up projects.

</comment><comment><USER39> This is a paraphrase of the advice that Martin Fowler gave in the book 'Refactoring: Improving the Design of Existing Code'. Kind of a shame no one mentioned that, but then it's been ten years.

</comment><comment><USER40> Did anyone else get a huge Web of Trust warning from this site?

<comment><USER7> You got a warning from my site? It is just a Wordpress site. Nothing too special going on that I know of. Let me know if you still get it and, if you know, how I can make sure it doesn't happen for everyone.

<comment><USER40> I'm very confused as to why my previous comment got downvoted. HN confuses me occasionally. Is it because I use WOT? Or because I brought attention to an issue with the site? Or "playas b hatin"?

Also cdevroe, here is the WOT rating--my guess is someone didn't like a post or two: <http://www.mywot.com/en/scorecard/cdevroe.com>

</comment></comment></comment><comment><USER7> Thanks for submitting this jakedahn! If anyone has any questions, I'm around to answer them.

</comment><comment><USER7> I thought by reading and responding to the discussion here on Hacker News that my karma would go up, not down. :(

I'm left with no choice; I LOVE KITTENS! AND BACON!</comment>


Machine produces the largest human-made waves in the world - <AUTHOR> http://news.sciencemag.org/europe/2015/10/machine-produces-largest-humanmade-waves-world <comment><USER2> If you're in Amsterdam, and have a little free time, I highly recommend the Normaal Amsterdams Peil visitor center in the City Hall.[0] There are large sight gauges, showing the water level at various points in the canal system. It gives a great sense of how far below the North Sea surface you may be.

[0] [http://www.normaalamsterdamspeil.nl/en/](http://www.normaalamsterdamspeil.nl/en/)

<comment><USER3> That's nice. Devils Lake ND went with a little blue wave sign attached to the street lights to tell you how high the lake level is. It does make a person very mindful of what happens if the dike breaks.

</comment></comment><comment><USER4> You can see that the reflected waves have a big impact on the shape of the incoming waves as soon as the first of them reach the far end. I'm no hydrologist but it seems to me that the shape of the trough concentrates this effect in a way that would not happen in a more natural open environment like a shore or dike. I suppose they can account for this in their experiments. Very cool machine in any case. I love large-scale experimentation like this.

</comment><comment><USER5> We have a wave generator at my old university, nothing to that scale, but it it had an array of paddles on one edge of a cube, and you could generate different shapes of wave. Like a CNC wave generator. You could even generate a swirling vortex. It was a pretty cool thing. We tested robots and offshore energy harvestors.

[http://osl.eps.hw.ac.uk/virtualPages/experimentalCapabilitie...](http://osl.eps.hw.ac.uk/virtualPages/experimentalCapabilities/Lab%20facilities.php)

</comment><comment><USER6> Not largest human-made waves by any definition of largest or human-made.

<comment><USER7> Largest I can think of are waves produced by underwater nuclear tests. Wikipedia claims the Operation Crossroads test produced 29m high waves, and that was only 23kt yield.

[https://en.wikipedia.org/wiki/Operation_Crossroads#Sequence_...](https://en.wikipedia.org/wiki/Operation_Crossroads#Sequence_of_blast_events)

<comment><USER8> Those are not active right now. It's the difference between oldest living person, and longest a person has ever lived.

</comment></comment></comment><comment><USER9> Here is a good video that shows how the (older) delta flume was used in the application of developing "living shorelines", as noted at the bottom of the article:

[https://www.youtube.com/watch?v=bDwoq71bCPw](https://www.youtube.com/watch?v=bDwoq71bCPw)

<comment><USER10> That is super cool. I would love to know though how long the willow branch mattress would last though before vegetation growing on it would also help it rot, get water logged and sink.

Would one also want to include the drum based floats underneath to help keep it above water?

It would be interesting to see these made and just placed out in various areas to grow, like little artificial islands or marsh patches. It would also be a boon to the willow stick industry :-) (any idea why they picked willow branches aside from the fact that the willow just grows a boat-load of vine-y sticks?) (pun intended)

</comment></comment><comment><USER11> MACHINE produces the largest HUMAN-made... wait, what?

<comment><USER12> Human made machine produces largest machine made waves ever? Is that ok for you =)

</comment></comment><comment><USER13> And not a single surfer showed up!</comment>


Ask HN: Why there is no drug to convert fat into muscles? - <AUTHOR> Obesity is becoming a very common problem. Why aren't there startups which target this problem? For some people, exercising and limiting their consumption is more or less outside of their willpower or atleast they feel so and find themselves helpless. <comment><USER2> Convert visceral fat into antimatter thus solving space travel while you're at it /s

</comment><comment><USER3> After reading your prompt, I think an alternative would be a drug to convert fat into pure willpower.

</comment><comment><USER4> Because lipids aren't amino acids.</comment>


Ma.gnolia is now Gnolia - <AUTHOR> http://gnolia.com/blog/2009/10/05/now-by-another-name

<comment><USER2> I heard they had trouble restoring the backups of the first two letters of their name.

<comment><USER3> Good one, I now need to clean soda off my monitor.

</comment></comment><comment><USER4> Well there we go... hate to say it but I feel bad to have cut Larry some slack back in the submission last week.

Anyone with 10 minutes, wikipedia, the US copyright/trademark website and a bit of thought could have worked out they had no real claim on the name.

Having minor experience in a similar matter I emailed Larry with some info I found useful at the time... I wish I hadn't now, and that sucks.

<comment><USER5> "What I'm really interested in is developing the community and service, and – on a bigger scale – the open web. I'm not interested in pouring my time and resources into an open-ended legal confrontation."

Your legal opinions aside, his choice is quite reasonable. Not everyone wants to fight the good fight. Or when you were cutting them some slack last week and emailing free advice, did you also have your wallet open for his legal fund?

<comment><USER4> He didnt need a legal fund; a polite letter or simply ignoring them would have sufficed.

There were no lawyers involved. They had no case :)

<comment><USER5> I do understand your point of view. Ignoring it was a valid option. However, if he ignored it and the other side actually filed suit, now you have real costs without regard to the suit's merit. These guys made a decision to not let this tie up any further time or potential cost. It does feel like they rolled over too easily, but hey, its their decision.

<comment><USER4> I seriously doubt the court would accept a suit straight up like that. At the very least they would have had to send a legal take down letter.

What he got was a personal note from the owner (or whatever); it might have been couched in legalese but there was no legal document :)

People get these letters all the time; best to just ignore them (or send a polite but short response).

Hey yes it's his decision to roll over; I'd never use Gnolia now though. He hasn't exhibited any common sense.

<comment><USER5> I have been involved in court cases. Here is my experience: you don't win. You don't get your money back for legal costs. At best, you get to decide when to walk away, let go, and get back to your business if your lucky enough that its still viable after all the energy and money you put into the fight.

Courts do not decide to "accept a suit". A judge acts on "evidence" presented by each side, they do not provide their own advice or due diligence in the case. A plaintiff files and the other side defends. Both sides immediately assume costs. If the court does throw the case out for lack of standing, jurisdiction, or other preliminary matter, ok, the defendant "won" that round, but you don't get your money or time back. If you want your money back, you have to either counter sue or petition for it. This puts more time and money at risk.

Its a very tough call to decide when to give up or fight. This guy made the decision that his name was not the most important aspect of his business and decided not to fight very early. I think he acted on common sense. Sure he could have waited and gotten drawn into a suit. He decided not to and that is a sign he wants to focus on his product and users, not worry about a moral victory over a name.

</comment></comment></comment></comment></comment></comment><comment><USER6> there should be a co-operative you can join to be able to get good legal backing so the little guy doesn't have to give in because nothing else makes economic sense. a legal system where by default "might makes right" is pretty scary. when the little guy rolls over to most demands from the big guy because he doesn't have the resources to fight, it completely distorts how a civil society is supposed to operate. you see this in many different fields and yet, very little has been done lately by the little guy to fight it.

sad.

<comment><USER7> I tweeted the other day about something similar. I think there are many cases where basic legal resource could save a lot of heartache. For really "cookie cutter" situations, ideally there'd be something in-between pro-bono, and "make an appointment at my full rate." A directory of cool lawyers, basically. Jay Parkinson, MD is a cool medical doctor who is really trying to change medicine, and does appointments over the Internet for example, people could pay with Paypal. What if lawyers did the same? <http://jayparkinsonmd.com/>

</comment></comment><comment><USER8> Sounds weird. Are there no other flower names that could have been used?

</comment><comment><USER9> I guess this is the upside of using a un.usual.ly dotted domain.</comment>


Ask HN: develop/promote work based on a soon-to-expire patent? - <AUTHOR>

Let's say there's a patent that's expiring in the near future, and I want to ship on day-one of the patent expiring.
I'd say I'm morally (if perhaps not completely legally) justified in developing the infringing program in the comfort of my own home, not showing it to anyone, and then releasing it on day one. First, do you see any problems with this?
Now the real issue: can I talk about my plans? Say all over the internet "get ready for this product on this date?" Would just acknowledging the fact that it's in development while the patent is still enforced hurt me in any way before/after the patent expiration term?
Basically I don't want anyone to say, before/after the patent is expired, "you MUST have developed this while the patent was still active, thus you owe us money" despite me not releasing anything until after the patent expires.
I don't think this should be an issue, given how quickly new generic meds come out after a pill patent expires. Or do those companies not "officially" start manufacturing until after the entire patent term?
Would this be complicated by taking preorders or otherwise getting money from it, before the expiration, but only delivering the goods after?
Thanks. I Am Not A Lawyer, perhaps one of you is. <comment><USER2> IANAL, and neither is Wikipedia, but Wikipedia says this:

 _> More specifically, an infringement may occur where the defendant has made, used, sold, offered to sell, or imported an infringing invention or its equivalent._

[http://en.wikipedia.org/wiki/Patent_infringement_under_Unite...](http://en.wikipedia.org/wiki/Patent_infringement_under_United_States_law)

It _looks like_ doing anything of the sort would infringe, theoretically.</comment>


Ask HN: Advice on a passion project in a small (but growing) market - <AUTHOR> tl;dr; I'm building a fitness tracker for rock climbers[1] that will be sold though rock climbing gyms. The climbing gym market is small and we have heavy up front costs to bring to market. I'm looking for advice in getting past this hurdle.
Two years ago I gave a talk at a tech conference called "Lessons learned prototyping a wearable for rock climbers with Node." I'm an avid rock climber and I was looking for a way to connect climbing with my passion for tech as well as find a project that would give me a chance to learn more about hardware and embedded systems programming. I continued working on the project after the talk and have made a good bit of progress but I'm at a critical point where I need to decide if I should continue with this project and if so, how to fund it.
The climbing industry is still relatively small (~600 gyms in the US, thousands more in Europe). The sport will have a debut in the 2020 Olympics and there are a number of new rock gyms that are sprouting up each year so the overall outlook of the industry is positive. I have 20 prototypes that I'm currently testing at one gym and three more gyms that have offered to test.
My buddy and I both have full time jobs and do this for fun on the side. I'd be happy to continue to bootstrap this project, but we have several hefty costs (in the hundreds of thousands) that we're going to get hit with if we want to bring this product to market including injection mold tooling costs, FCC certification, first batch of units, some (expensive) final engineering work, etc.
Does anyone have experience getting over this hurdle in a hardware project? The original intent of the project was to build something cool with no real dreams of turning it into a business, but in order to actually make the idea a reality I don't see another path. We need gyms to be on board and in order to do that we have to be able to provide them with a polished (not 3D printed) product.
[1] https://www.climbalytics.com <comment><USER2> Can you not build this as an app for an Apple Watch using NFC tags? Or any other commercial wearable. That'll save you a boatload of money, and probably be more appealing to climbers who usually do other sports as well and would rather have a single device.

When it comes to raising money, investors will want to know how big your moat is. For instance, if in the future Garmin or Apple added a climbing feature to their product, can you keep growing?

<comment><AUTHOR> I wish we could use NFC on an Apple watch. It would have saved a lot of trouble. Unfortunately the read range of NFC is too short to work on a climbing wall. The climbers wrist will sometimes be up 12+ inches away from the closest point on the wall. This was the challenge that I ran into with our first prototype.

As for moat, I think we have some patentable IP (another potential large cost to file for that patent) and because our model hinges on a relationship with the climbing gym, the big guys would have to establish a salesforce to sell into these gyms, which I think for the size of the market would not be worth it for them. If we can solidify a decent market share it would probably be more likely that they'd try to buy us out rather than fighting for those relationships, but I'm not certain about that.

<comment><USER3> You might want to consider alternate technological approaches. Have you considered using an IMU to deadreckon the route and detect rests and falls? I think this would be an perfect application. Then you wouldn't need the rfid tape. You could also probably use an existing 3rd party hardware. I think developing the hardware and managing its production will kill you in the end. Plus, who wants yet another doodad to buy and wear.

Another possible method is to use computer vision and video to capture the climbers motion.</comment></comment></comment>


As Google for Education tools enter classrooms, parents are asking to opt-out - <AUTHOR> http://www.cbc.ca/radio/spark/as-google-for-education-tools-enter-classrooms-across-canada-some-parents-are-asking-to-opt-out-1.4694939 <comment><USER2> Sadly, whatever "digital hub" they come up with as an alternative to G Suite is going to suck. Let's face it, it's a school board not a product development team.

Perhaps there's some kind of clever business model to be worked out here by the right entrepreneur.

</comment><comment><USER3> I'm curious what data the parents think Google will be able to mine out of 100,000 badly written docs/slideshows about the life of George Washington.</comment>