It's A-Me, HTML Mario - <AUTHOR> https://github.com/nbarkhina/MarioHTML <comment><USER2> So what is novel or unique here? It's a half finished demo/game of derived assets. This is like the stuff I made as a beginner.

I thought based on the name that it was some clever hack using only HTML and CSS (with maybe just a little cheating for input). But it looks like just a regular old js demo.

Edit: A search of github will show hundreds of similar projects, most of them for undergrad assignments. Maybe I am a snobbish dick but I expected something more notable than run of the mill undergrad projects when coming here.

<comment><USER3> It also looks to me like something made by a beginner. But from that impression I have the opposite take: why write this comment at all? Your comment only will serve to discourage this person, who is just getting started and not sure if they should continue down this path.

Does this project belong on HN? Probably not. Does your comment contribute anything? Definitely not.

<comment><USER4> > Your comment only will serve to discourage this person, who is just getting > started and not sure if they should continue down this path.

I don't know about that, if nobody told me that my kid projects sucked I may not have tried to make them better and would have stayed content with their sorry state and would just have doubled down on them without ever seeing what's wrong... and then I would make everyone cringe around me like 30 years- old spouting cringy RPG Maker games :-)

<comment><USER5> The original comment is only discouragement, not critique. There's a huge difference! Some people work harder when simply discouraged; it sounds like you're that type of person. Not everyone is like that.

<comment><USER6> But it wasn't discouraging the work itself, just it's submission here.

</comment></comment></comment></comment></comment><comment><USER7> Hmm, looks like JavaScript Mario, not HTML Mario. HTML Mario would have been much harder, if not impossible to make.

</comment><comment><USER8> This definitely won't attract any attention from sue-happy Nintendo.

<comment><USER9> If it bubbles up to their attention it would be pretty routine:

* A cease and desist form letter to the author

and

* A DMCA Takedown Notice to Github to remove the repository

<comment><USER10> Maybe I shouldn't have voted this up. :/

<comment><USER11> Clone, then upvote :)

</comment></comment></comment></comment><comment><USER12> Really cool!

The physics is "different" enough from SMB that I feel a little disoriented, but that could also be because I'm not used to controlling motion with my right hand, and jump/run with my left.

Anyway, looks like a fun hobby project!

<comment><USER13> It's funny about that because I grew up playing keyboard-controlled games like Jazz Jackrabbit where it was right hand arrow keys and left hand jump/shoot/action. This is still natural to me today, and indeed, games like Hollow Knight and Celeste have this control scheme as the keyboard default, despite that pads have always had movement on the left thumb, and kb/mouse games like shooters also put the movement on the left hand.

Anyway, it was just funny watching my 8 year old daughter struggle to play a game with right hand arrow keys recently, and realising that her only experience has always been left thumb gamepad— she did much better once I paired up a DS4 for her to use.

</comment></comment><comment><USER14> "Super Maryo World" has been doing this since 2005:

[http://www.janis.or.jp/users/segabito/JavaScriptMaryo.html](http://www.janis.or.jp/users/segabito/JavaScriptMaryo.html)

</comment><comment><USER15> Was expecting this to be Mario Teaches HTML.

</comment><comment><USER16> Looks like some kind of bizarre Korean knock-off

<comment><USER17> If the author's bio is accurate, it is in fact a bizarre US-American knock- off.</comment></comment>


Immuni Code – Commissario straordinario per l'emergenza Covid-19 - <AUTHOR> https://github.com/immuni-app <comment><USER2> As far as I remember from the public discussion, unfortunately this application relies on the centralized model, rather than the decentralized approaches proposed. IIRC uses the same approach that Germany originally proposed, then scrapped.

</comment><comment><AUTHOR> Immuni is a technological solution that centres on an iOS and Android smartphone app. It helps us fight the COVID-19 pandemic by notifying users at risk of carrying the virus as early as possible—even when they are asymptomatic. These users can then isolate themselves to avoid infecting others, and seek medical advice.</comment>


Is it time to dump the "Lean Startup" Approach? - <AUTHOR> https://medium.com/@seyi_fab/is-it-time-to-dump-the-lean-startup-approach-4eb6be23c941 <comment><USER2> Most of the lean startup methodology is all about 'determining requirements'. The leanness is about not bothering to spend too much time creating things without determining requirements. Sometimes, the requirements are your own and the requirement in question is creating things (like art) and so you can't possibly spend too much time on whatever it was you you were creating. Sometimes requirements need a very long study in order to determine them. Nobody is arguing against long study exercises, especially for wicked problems. Sometimes 'long termness' turns out to be big problems that are made up of lots of little requirements. You need long-not-lean studies and while they are being done, you may also want to try quickly evaluating shorter term hypotheses. So yes, we can talk about where the lean startup fits in to long- termness and wicked problems and yes, claiming that lean startup is over is a great stimulus for debate, so thanks, OP.</comment>


What the Rich Won't Tell You - <AUTHOR> https://www.nytimes.com/2017/09/08/opinion/sunday/what-the-rich-wont-tell-you.html <comment><USER2> Stealth wealth is pretty despicable: 'I might have x million dollars but you aren't allowed to know that and hey, I'm just like you!!'

No, you are not, because your wealth means you have a whole world of options that average people do not have.

</comment><comment><USER3> The New York Times, showing its usual compassion and concern for the problems of rich white people.</comment>


HanselCrush - A Website for Hanselmaniacs - <AUTHOR> http://hanselmancrush.com/ You have a bit of a man crush on Scott Hanselman. It's ok. This is a safe place. I want you to feel comfortable. We're all friends here and you're not alone; there is no need to feel bad about it. <comment><USER2> This is just crazy.</comment>


Alex – catch inconsiderate, offensive writing - <AUTHOR> http://alexjs.com <comment><USER2> No thanks, I'll apply my own standards to what I write thank you very much.

</comment><comment><USER3> Boogeyman is inconsiderate? "Person with a limp" is an accurate/inoffensive replacement for "cripple"?

I respect the attempt but I don't think I'll be using this any time soon.</comment>


Create a Self Signed SSL Certificate on Nginx for Ubuntu 15.04 - <AUTHOR> http://syscoding.com/tutorials/23/create-a-self-signed-ssl-certificate-on-nginx-for-ubuntu-1504/ <comment><USER2> Free SSL certs: [https://buy.wosign.com/free/](https://buy.wosign.com/free/) [https://startssl.com/](https://startssl.com/)

Nginx SSL config: [https://cipherli.st/](https://cipherli.st/)

</comment><comment><USER3> I don't see what's hackernews worthy about this.

<comment><USER4> I didn't get it either. does 15.04 provide a special or easier way of doing this. The info looks like something that could've been found on stackoverflow</comment></comment>


Google's Blacklisted Terms: "Conservatives Are" - <AUTHOR> http://www.theguardian.com/technology/2016/feb/08/forget-conspiracy-theories-heres-why-googles-conservatives-are-blacklist-is-worrying?CMP=fb_gu <comment><USER2> I think they would have been better off not blacklisting anything. That way they wouldn't have to justify each and every item on their list - they could just blame them on who is searching for what and leave it at that.

</comment><comment><USER3> I'm not sure I understand why these search suggestions are so powerful that we should worry about their editing.</comment>


Why Programmers Are Bad at Estimating Time - <AUTHOR> http://java.dzone.com/programmers-are-bad-estimating <comment><USER3> A simple multiple is not the answer. This is an incredibly well studied problem. At the basis of all of the reasoning is the inherent uncertainty of the task. Estimation is only accurate when all the details of the required task are known. For example, you can estimate how long it will take to assemble 5000 widgets if you know the average time it takes to assemble 10 widgets, and that time is consistent between executions.

With programming, there is no atomic unit of work that is consistent between projects, thus highly accurate estimation is next to impossible. What seems similar from a conceptual standpoint is often completely different depending upon the input factors: lanuage used, experience of the team, specific project requirements.

This problem has given rise to many new ways of working on programming projects. Solving this issue inside a company means building understanding of the inherent uncertainties with management and stakeholders. Solving this issue as a freelancer means inflating estimates and hoping and praying that you can keep the customer in check, because "we can't estimate that" just doesn't work for consultants.

<comment><USER4> Watts Humphreys made the point that any seriously constructed estimate is _still_ more useful that no estimate at all.

The SEI have claimed that organisations with well-defined processes working on problems where they can control many factors such as language and tool choice, with stable staff and so on can in fact get to within 5% variance (sorry, can't find the source right now).

If your software shop is working on same-y tasks (and many do), using historical data as a guide to future performance is perfectly reasonable.

<comment><USER5> In my anecdotal experience, at large corporations with well-defined processes, the 5% variance is the result of huge time estimates. Then you make sure you don't implement any faster than the estimate. (Even if it turns out you could have done it half the time.)

<comment><USER6> I was thinking something similar. In my anecdotal experience [1], large corporations can control variance by normalizing everyone's velocity. For example, in order for me to finish a feature, I had to write a document describing how I would solve the problem and convince my manager and tech lead that it would work. After spending about two months getting my plan approved [2], they let me implement it, which took me about four hours. At that ratio, the actual development time is practically negligible, so it's easy to have low variance. The side effect is that you also have very low productivity.

Imagine the opposite scenario, where they let me implement it first and then approve it if it works. Let's say it takes me a couple days to finish it (this time has to include some of the time that it took me to figure out how to solve it originally). Now the feature is getting done in a matter of days instead of months. The flip-side is that you can have higher variance, because if there's a problem with my initial implementation, that adds more time to fix the problem. In this scenario, the time it takes to finish features is more dependent on the engineer's ability than the time it takes to pass through the bureaucracy, and there's going to be more variance in the abilities of individual engineer.

[1] I worked at Microsoft as an intern in the summer of 2009.

[2] There were many days that I literally couldn't do anything except wait for clearance to go forward.

</comment></comment></comment></comment><comment><USER7> I must strongly disagree with the article. The problem and its true cause are well known.

Manager: "How long will it take to build X."

Experienced developer: "I'll need a couple weeks to prepare an estimate."

Manager: "I don't have two weeks. Just a rough estimate, no pressure."

Developer: "This is a big project with a lot of uncertainties, with Abdul, Karen, and Jim, we might be able to get it done in 12-18 months, minimum, assuming there are no scope changes."

Manager: "No, that's wrong, we need it in three weeks maximum, and you can only have Amy."

Developer: "The new girl? It will take months just to get her up to speed with the skills. It's impossible."

Manager: "Make it possible."

Developer: "Wishing doesn't make it possible."

Manager: "You geeks are unprofessional and your bad attitude is damaging the company. Where is the can-do team spirit like the sales team has?"

Later...

Executive: "How long will it take for the new project?"

Manager: "Five weeks, just like you wanted, assuming the dev doesn't spend the time posting on the internet."

Executive: "Good I am giving the project the green light then."

One, two, three and four weeks later:

1: "Here are some scope changes."

2: "Here are some change requests."

3: "This should be done completely differently."

4: "The way ABC works has been changed to DEF. Should just be a minor tweak."

End of five week death march:

Executive: "Why is this not done?"

Manager: "The stupid geeks are unprofessional! Please refer to this chart I found on the internet about how these losers don't know how to estimate!"

<comment><USER8> Even with a couple of weeks the risk of the estimate being wrong is high.

</comment></comment><comment><USER9> Why blame the programmer?

Bad estimates, like bad anything, have all kinds of possible causes. The programmer's "estimating weakness" is just one possible (and often unlikely) cause.

In general,

      A. People do stuff.
      B. Programmers write code.
      C. People do stuff.

so don't automatically blame the programmer for fuck-ups in Phases A or C.

More specifically, one of my recent real world examples:

[http://edweissman.com/it-takes-6-days-to-change-1-line-of- co...](http://edweissman.com/it-takes-6-days-to-change-1-line-of-code)

<comment><USER8> Exactly!

It has nothing to do with the programmer. It has everything to do with what projects really are today.

1\. Undefined in scope even when defined 2\. Problems to be solved (innovation) not solutions to be produced (production) 3\. Filled with hidden complexities of potential infinite character.

 _Copied from another post of mine:_

Time estimations is an industrial way of thinking applied to a post-industrial (and post-capitalist) world.

In the post industrial world time isn't the problem but rather project definition and scoping. In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X)

In the post industrial world every project is about problem solving and scoping. To put it into comparison.

If we apply post-industrial reality to an industrial world.

It means that each time a product needed to be done if not the factory, then the machines would have to be developed.

It will take many many years before time estimation will die, but it will happen.

<comment><USER10> Do you have a link to that post? I really like your summary here and would like to link to it directly, outside of linking to this comment.

</comment></comment></comment><comment><USER11> Programmers are often asked to accurately estimate tasks that are too large to estimate. The smaller or larger the task, the more likely it is that there will be errors in the estimate. The larger a task, the more likely there is a detail that has been missed during estimation, the more chance that you will encounter a surprise during development that greatly increases development time.

Most successful estimation methods boil down to refusing the estimate larger tasks, and instead breaking them down into smaller tasks. The process of breaking them down forces people to think through them in more detail, and you flush out many of the surprises early on. Similarly, most of the successful systems require you to apply a minimum amount of time per task (e.g. one hour). This removes the problem of programmers underestimating simple tasks.

The best estimates come when you continue to use that system over several iterations of work, and analyze the accuracy of previous estimates. This gives you (and other developers) a better sense of how to make good estimates.

Sadly, even when you have a reliable system of predicting how much work a development team can get done in a given chunk of time, many managers bow to pressure from above to hit deadlines, and expect the team to accomplish more than the data says they are able to accomplish.

<comment><USER12> I would add that the only really good estimates happen when a small task is estimated by a programmer who has already performed that task, at the same level of complexity, a few times before. (And the programmer doing the estimating is the one who'll be doing the implementing, natch.)

Even at the scale of small tasks, programmers estimating things they've never done before are often wildly wrong.

<comment><USER13> You are correct, but note that a wildly wrong estimate provided with good intentions is better than no estimate at all.

If I get an estimate for something that's never been done, I want to know that it's a SWAG so I can rate it accordingly. If you go ahead with the task, I'd probably ask you to give me more frequent updates than normal, so we can see if the estimate needs to be adjusted.

I know that a lot of people work for hugely disfunctional organizations, but in most reasonable places, it's expected that some estimates will be wrong and either the task should be killed, or the schedule adjusted.

<comment><USER12> Oh absolutely. It's like that old chestnut about plans being useless but planning being essential.

And one can even find productive use for an aggregate SWAG-to-reality ratio, tracked over time. Individually, that ratio won't give you any better an indication on where a given SWAG is likely to land, but in the aggregate you can use the ratio to put something like error-bars on the project as a whole.

</comment></comment></comment></comment><comment><USER14> Programmers are bad at estimates for one main reason: Many think that to stay employed they must give the answer the manager or client wants to hear and often that number is way too low.

<comment><USER15> I've done some work at a customer where they used Planning Poker. I'm guessing the idea comes from some Agile development or Extreme Programming methodology. I'm not a fan of the latter, but Planning Poker was entertaining and seemed like it had some good points.

The team sits together, everyone has a deck of cards with values. The team lead calls out a task and everyone throws down his estimate at the same time. If the values diverge widely, the team lead asks the outliers to explain, and everyone can reconsider after the explanation. The highest remaining number is taken as the estimated time.

This was done in days for big tasks, who where then split up in sub-tasks where the same was repeated in hours.

Sharing the responsibility of estimates prevents the manager-pressure problem you talked about. If the team estimates it takes 5 days and the manager thinks it should only take 3, the team isn't going to back down (unlike what could happen in 1-1 conversations), and the manager will ignore the estimate at his own peril.

[http://www.codinghorror.com/blog/2007/10/lets-play- planning-...](http://www.codinghorror.com/blog/2007/10/lets-play-planning- poker.html)

<comment><USER16> Planning Poker helps, but a few caveats must be recognized:

Some people have little, or no, idea the effort required for a task. Fair enough, just don't base plans on known ignorance. Compelling them to vote is silly.

Some people have differing notions of "done". One self-appointed hotshot may be able to crash thru the code and make something run happy path in a few hours and thus gives a low estimate, but unlike others fails to account for ripple effects, breakage, documentation, consulting with others, etc. Are votes for "it works"? or "everything related is completed"?

All too often outliers are _right_ , but dismissed because they're outliers and given just a few impromptu seconds to explain complex nuances why they're right and the disinterested opposition is wrong. Subsequent "I told you so"s much farther down the road are disheartening, and kept quiet as the opposition still doesn't see the connection nor want to.

Again, make sure the estimate includes _all_ related work. Implementation may be quick; integration testing or documentation may be long. Don't give something a 3 to do and ignore the additional 5 needed for ripple effects.

<comment><USER17> THe team quickly learns what everybody is going to say for each part of the estimate, and they all throw down the same card. Nobody wants to spend any more time in the meeting, and throwing down an outlier means thinking hard and explaining yourself.

</comment></comment></comment></comment><comment><USER18> The top answer to this question on Quora is the best I've seen. [http://www.quora.com/Engineering-Management/Why-are- software...](http://www.quora.com/Engineering-Management/Why-are-software- development-task-estimations-regularly-off-by-a-factor-of-2-3)

What really surprises me is that everyone accepts that there have to be estimates. While estimates are useful in many scenarios, most of the estimates I see developers giving add no value and are a waste of time. I've been working with teams now for the last 2 years who don't do estimates, and they are the highest performing teams I've ever worked with and the rest of the business have the highest trust in IT I've seen.

</comment><comment><USER19> The (only) way to get good at estimation is to make them, track your time accurately, then compare actual to estimate with focus on what factors influenced the estimate to be wrong. Repeat.

This will also provide a velocity (actual / estimate) which future estimates are multiplied by. My initial velocity on new project is 2. That is if I think it will take a 8 hours, I estimate 16 hours.

Also the unit of estimate is "eng hour" not "wall clock hour". You need to multiply estimate by friction factor to account for standups, meetings, demo's, hallway talk, breaks, etc. Typically 1.2-1.5 depending on environment.

btw the "Tracking time spent accurately" is the main reason developers don't get better at estimation. It's hard, developers don't do it, PM's / Managers are interested in billable time or other derivative metrics and they and sr eng rarely provide the support needed to develop estimating skill.

<comment><USER20> I've tried this before, and I didn't find that I got any better. I had an excel spreadsheet tracking each task, my time estimate, and the actual time spent doing it. And I found that while for half to most tasks, I was fairly accurate, every couple of tasks, I'd have a task that was wildly off. Thus, my variability was huge for task estimation.

<comment><USER13> How large were your tasks? The rule of thumb I use is that no individual task should be more than 4 hours. If it comes out longer than that, I break it up into subtasks. It is much easier to estimate small things than big things.

<comment><USER20> The tasks were at most 8 hour estimates. Perhaps I should try 4 hours next time.

</comment></comment></comment></comment><comment><USER21> I don't think that the problem if being able to estimate time is only with programmers. Time estimation is a combination of many factors. In the context of programming or software development, it can be anything from the skills of the developer, constant customer/client scope changes, sudden resource loss, critical vendor bugs that are usually more time consuming and cannot be fixed in-house (if using vendor system), sudden change in company's budget policy and project criticality (i have worked on million dollar projects that are delayed because management does not want to take a risk due to other un- related issues) etc. Unfortunately, all these variables are extremely difficult to estimate.

So even if a programmer is good and can estimate almost accruately from his/her side, these other variables can throw off a project in no time.

</comment><comment><USER22> I know this isn't a real answer, but I say: fuck estimating.

I'd much rather have my team focus on good on-the-fly prioritization, recovery from rabbit holes, spiking efficiently, smart dependency engineering and building fully featured stories.

Building software - especially anything new, or with an odd mix of integrations (i.e. everything) - is full of a lot of unknowns. When you accept that, and stop trying to control or predict it, you can spend more of your time and methodology horsepower on things that deliver more reliable value.

<comment><USER16> Easy when software is the totality of development. When there's hardware design, marketing, training, etc. happening in parallel, top management needs to know how long it will take. Sometimes, if you don't get the software out the door by an arbitrary date, the company is finished; _estimate_ accordingly.

<comment><USER23> This is exactly why software estimating is bullshit.

If the software has to be out the door by a specific date or the company dies - you DON'T NEED AN ESTIMATE.

Are you going to cancel the project based on the estimate? Dead Company

If the project is _really_ too big to complete in time: Dead company, and optimistic estimates won't help.

If you could build a subset of the project and survive, then you still don't need an estimate - you just do the important stuff first.

If you were being chased by a lion, would an estimate of the time necessary to outrun it be of any use whatsoever? Of course not. You start running, and you either make it or you don't.

If there is other stuff happening in parallel, like marketing, then it is happening in parallel, and has no dependency on the software. That's what parallel means.

If you have a critical path dependency, then you're back to the situation above where you are going to make it or not, and the estimate won't really affect your ability to deliver.

Even estimating for cost is bullshit - if you practice lean development, you watch your metrics and if something doesn't work, just scrap it for the minimum amount of money lost. You can't do much better than that, except for not starting, and in that case you don't need an estimate.

I prefer the approach that saya "we're going to deliver feature X, and if it takes longer than Y or costs more than Z, we abort." You know exactly how much you stand to lose under this plan. The problem is, this means that management has to be involved on a day-to-day level with monitoring progress and making go/no-go decisions, when most managers I've met would prefer to have a single 3 hour planning meeting and then disappear for 4 months to raise money or play golf or go to tradeshows in Vegas or whatever.

<comment><USER16> No, correct estimations mean management knows "X cannot be done in time T", and now can act accordingly to decide what subset/variant of X to pursue instead.

"Dunno, we'll give T a shot" will fail.

<comment><USER23> I was responding to the comment that established "X _must_ be done in time T" or the company fails.

In a perfect world, estimates would come before deciding to proceed, but in 95% of the places I've ever worked, the project necessity is decided first and the estimates are asked for afterwards.

In reality, the project often settles for a shoddy subset of the original vision in order to make an arbitrary date, when they could have had the same exact subset at much higher quality if they had merely proceeded with the important parts first in a lean/agile manner, using micro-estimates (if bothering to estimate at all).

A bigger problem with estimating the solution of unknown problems is that confidence in the estimate varies inversely with the precision (or usefulness) of the estimate. I could estimate all my projects with 99% confidence as "somewhere between 1 day and 1 year".

That's not a useful estimate.

Or I could estimate "this will take 42 days" and be wrong 99% of the time.

</comment></comment></comment></comment></comment><comment><USER4> Steve McConnell of _Code Complete_ and _Rapid Development_ fame also wrote a book about estimating software development -- _Software Estimation: Demystifying the Black Art_. It's a great read and as usual McConnell is an absolute master at distilling vast reams of research into concise, interesting reading.

</comment><comment><USER14> But is it just a programmer problem? How good are lawyers at giving estimates for solving legal problems that are even slightly complex?

<comment><USER24> Its everyone's problem.

Everything in life has a deadline, and at every point in your life you'll be asked to make and meet them.

From dinner to that assignment/project due, the pressure is always there.

I feel that most people underestimate the time things take, mainly because they want to look compitent. There are many things you just cannot put a deadline on; and yet you will be asked to.

Under promise, over deliver. Either way, they want results.

</comment></comment><comment><USER25> The only thing I've ever seen work (and I've seen it work well) is to avoid estimating based on time. Instead, you estimate things relatively and then empirically measure how long things take (known as the "velocity" in agile parlance). So the programmer doesn't have to think about the 1001 things that they have to do in order to complete a task, or all the distractions or BS or overhead they'll have to deal with, they just need to think: is task A about as hard as task B, or is it twice as hard?

There are a key pieces to making that work. First of all, you give your estimates in terms of "points", not hours or days. Secondly, you estimate tasks relatively to one another, not absolutely: a 3-point task is about 3-times as much work as a 1-point task. Third, you have multiple people give the estimates, often using something like "planning poker" (where everyone on the team selects their estimate and reveals them simultaneously, then discusses if they're different), which ensures they're more reliable. Fourth, you measure the velocity of the team (not individuals, the team) over time. It often takes a while for it to get anywhere close to stable, as people get used to the project, the technology stack, each other, and so forth.

That's the only thing I've ever seen work, and it can actually work pretty well. It prevents the developers from having to account for all the non-coding things: you don't have to think "Well, this will take 2 hours of coding, 2 hours of test-writing, 1 hour of debugging, 1 hour of docs . . . but I also have 2 hours of meetings a day, and I get pulled off to firefight customer problems periodically, so really it'll take 4 calendar day." You just measure all that stuff empirically: if you have a bunch of meetings or firefighting, your velocity slows down, but your estimates don't have to change to account for it.

It also avoids wishful thinking, especially if you're rigorous about what counts as something being "done". It's harder to lie about whether or not you're going to hit your dates if your measurements say you're going too slowly; it's far easier to be in denial when all you have are time estimates, since those are easier to fudge than relative estimates of difficulty or empirical measurements of velocity.

(Of course, as with any measure of productivity, it's subject to abuse by idiots. But as a scheduling and measurement tool, it can be invaluable.)

</comment><comment><USER26> This bit made me stop reading immediately: _"The task is way too large to get an understanding of for most programmers. It has to be sent back to an architect.."_

I checked the date to see if it wasn't written in 1982 before I closed the tab.

<comment><USER27> Yeah, that was a really poor comment. If your developers can't break down a 1-week task without an "architect" stepping in, then either your process is broken or your developers suck (or both).

</comment></comment><comment><USER28> Humans are generally bad at estimating time (and budget) for projects, in large part because we tend to take an "inside view" [1] and imagine unrealistic best case scenarios, instead of making an estimate based on empirical data for similar projects completed previously.

[1] <http://www.overcomingbias.com/2007/07/beware-the-insi.html>

</comment><comment><USER29> The most popular article on my blog is called "How To Estimate Like an Adult":

[http://www.writemoretests.com/2012/02/how-to-estimate- like-a...](http://www.writemoretests.com/2012/02/how-to-estimate-like-adult- part-1.html)

Estimation is a skill, like any other part of learning to be a good software engineer. People shouldn't be making excuses for their poor estimation skills after ten years of experience...

<comment><USER30> I think this is a good point, but, also, see edw519's comment at the top. You should work on your estimation skills, but management should understand the values you give them are for the work, not necessarily today + your estimation. Stuff happens, and your estimates seem to slip, but in reality, they could be spot-on for actual time it would take do the task without interruption.

</comment></comment><comment><USER31> Estimating time is no trivial task. From my past experience I can say that it really differs from person to person from team to team. In fact in the past we have wasted so many hours estimating work load, time that could have been better spent on the actual tasks. It took quite some effort to get into a Kanban style process. Not for developers but for business and product managers as their central question 'when?' is meassured differently now. We got away from developers guessing how long it will take and instead take the past performance to guess future timelines. Works better for us. The whole point is: Take burden off your developer, improve your processes around him. Provide better requirements, give valuable feedback, understand issues and risks. The more input from your side, the better the 'estimations' from your developer.

</comment><comment><USER32> "4 hours: This is probably the only realistic estimation. It is large enough to have some margin for unexpected problems, while the task is still small enough to grasp."

        1. Estimate everything in 4 hour increments
        2. 100% accurate estimates
        3. Pizza party

<comment><USER33> This was also my entire takeaway.

</comment></comment><comment><USER8> Time estimations is an industrial way of thinking applied to a post-industrial (and post-capitalist) world.

In the post industrial world time isn't the problem but rather project definition and scoping.

In the industrial world the problem was already solved (machine was built, market often established and output depended on a few factors that could be adjusted. Need more output add more of X)

In the post industrial world every project is about problem solving and scoping.

To put it into comparison.

If we apply post-industrial reality to an industrial world.

It means that each time a product needed to be done if not the factory, then the machines would have to be developed.

It will take many many years before time estimation will die, but it will happen.

<comment><USER20> If writing software is more akin to writing essays than building bridges, and thus hard/near impossible to do accurate estimations--

Why do we need time estimates at all? Why does a company manager need time estimates? Is it mostly budget concerns?

How would a company operate if there were no time estimates?

<comment><USER8> That is hard to say and it would be a book worthy to explain what could come next.

All I know is that it is unsustainable.

The complexity is simply too high and it's not getting better. One of the reasons I think why you see the fail fast movement be so successful.

Once you accept that failure is part of the process, once you abandon the "zero mistake" policy that many large organizations instill internally and externally you will begin to approach projects differently.

The truth is that "zero mistake" organizations make as many mistakes as everyone else, they just have the financial strength to ignore them as long as economy of scale works in their favor.

I could write forever about projects that went wrong not because the developers where bad but because the premise that fuels product development is broken.

I blame primarily business schools and large parts of academia for this. But it could extend all the way into the way the stock market is structured.

If you buy my premise that post-industrial is different than industrial age. That project definition is primary and time is secondary today. Then it does put some doubt at least in me about whether the stock markets focus on growth and Q's is sustainable.

Nature seems to be doing a good job as pacing various processes. It takes nine months to give birth to a child. One cell at a time. But the process is ongoing. Nature is the ultimate continues deployment strategy.

</comment></comment></comment><comment><USER34> When explaining this, I usually turn it around and say "How long will it take you to get 10,000 paid recurring customers? OK, how about 2?" Then the concept of task estimation and scope starts to make sense to most people.

</comment><comment><USER35> I just want to point out that in #1: "Time for starting the computer, the development environment and getting the right source." What programmer needs to start their computer to fix a bug? That is crazy talk.

</comment><comment><USER36> The annoying thing for me is not necessarily that programmers are bad at estimating time but rather that programmers and others don't fully understand/appreciate that fact. People who don't understand it always seem to try and push developers to come up with timeframes that are either completely unreasonable or have so much padding that they end up being ridiculous. I think the solution to this whole problem is simply getting everyone involved to read articles like this and start leaning more toward managing priorities than setting hard deadlines.

<comment><USER36> But to counter my own point, the only reason why I think deadlines are good are for some people that don't put in a full effort unless there is a deadline. Even with that, however, the person setting the deadline should understand the estimates will be off and expect things may very well be late no matter how hard you push the developers.

</comment></comment><comment><USER37> Does the "wisdom of the crowds?" help in this case?

At the company I just did a project for, there were no requirements that weren't vague general statements, only "bugs" that are discovered after the fact. Discovery after playing with the app is fine, but calling it a bug is not. Also, all estimates were done on the spot or on short notice (as if they were "bugs.")

Even worse, it turns out that there is a lot of knowledge about requirements and use cases, but it only comes out in the form of "this is a bug because..."

You can think of this as "avoiding documentation through blame."

</comment><comment><USER38> I've been estimating my time as a designer in the AEC industry since my first job more than 20 years ago.

The only reason I did was because Greg, the VP of Engineering, said doing so was the only way I would get better at it. And the only reason I got better at it was because I've tracked my actual time against my estimates on many occasions over the years and been burned by bad assumptions from time to time.

At this point I have a process which produces a fairly accurate range of "billable time" based upon an important recognition: a list of tasks with assigned times doesn't account for flow nor does it account for the efficiency experience brings when dealing with "known unknowns." My first estimates tend to be wildly pessimistic (the opposite of what the author observes in the estimates of others).

On the other hand, one of the ways I evaluate my initial task list with assigned time estimates is by chunking the work into half days, because I've found half-days to be highly accurate across a variety of project sizes...at one point all my proposals were written as $xxx.xx/half day.

One of the useful features of the half day is that it is vague. Maybe it's three hours and I can go for a walk, maybe it's five and I'm at the computer a little longer. Either way, it doesn't have much impact on my day or productivity.

Another useful feature is that it allows chunking multiple small tasks together intuitively.

       > (equal half-day (add-hours .25 1.0 .25 .5 .75))
          T
       > (equal half-day (add-hours 1.25 1.0 .25 1.5 .75))
          T

But the half day doesn't try to force the unrealistic optimism of large time spans downward - what does it mean to estimate something will take a week? Billable time does not translate directly into calendar time because of flow and the productive use of procrastination.

In other words, a forty hour project doesn't mean I will be done in a week (unless the work is entirely rote, and in that case I am probably going to be too expensive anyway). From start to end, a forty hour project probably takes at least two months - which is about the same amount of calendar time an 80 or 120 hour project might take - because a 40 hour project tends to have a higher proportion of creative time (in my case design) than a relatively larger project.

</comment><comment><USER39> Most people don't even know what they are actually asking for when they ask 'how long will this take?'. I always try to tease out whether the person asking is looking to find out 'when will this be done by?' or 'how much effort is this?'. Even when you've figured that out, you need to understand what they think they mean by 'done'. code is changed on my machine? I've checked it in? code deployed to QA and tested in multiple browsers and run through the regression suite? code deployed to pre-production for approval by the client? code approved by client, deployed to production and live? Also, do you want me to take into account the time I'll spend waiting for decisions to be made about how this feature has to work, or just tell you how long it will take me to do it once you've got me the answers to these questions?

One thing I've noticed is that organisations can only normally operate at a certain number of 'decisions per day' (and the larger the organisation, the lower this number). For estimating anything where requirements are not yet firm, or will be discovered during development, that rate is usually the constraining factor, not the development effort.

</comment><comment><USER40> Tom DeMarco, of Peopleware fame, wrote a book called "Controlling Software Projects: Management, Measurement, and Estimation". He has, in some ways, rejected his ideas in that book.

In this article, "Software Engineering: An Idea Whose Time Has Come and Gone?" [http://www2.computer.org/cms/Computer.org/ComputingNow/homep...](http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf) he states:

"My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I'm wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no."

The tl;dr of his article is that the software projects that require tight cost control are the ones delivering little or no marginal value. That is,

"To understand control's real role, you need to distinguish between two drastically different kinds of projects:

■ Project A will eventually cost about a million dollars and produce value of around $1.1 million.

■ Project B will eventually cost about a million dollars and produce value of more than $50 million.

What's immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you're working on a project that's striving to deliver something of relatively minor value.

To my mind, the question that's much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?"

I believe this as well. If the value of software we're writing is so low, it's probably not worth being written. The high value stuff isn't worth more than a cursory (e.g. Agile "Points") estimation.

The other thing, which he doesn't touch on the article, is that in order to shrink the "cone of uncertainty" (<http://construx.com/File.ashx?cid=1649>) you must put more and more effort into actually "solving" the problem. Rarely do estimates consider the _time it takes to estimate_ (requirements docs, interviews, etc.). Ultimately, if you follow the line of reasoning all the way out, perfect estimation requires you to solve the problem and all you then estimate is precisely the amount of time it will take to type the code you've specced out.

Of course, what you don't have an estimate for is all the time it took to arrive at your estimate. And thus, the folly of software estimation is revealed.

(edit: Lack of blockquote is quite annoying, apologies for the messed up styling)

<comment><USER41> One thing to consider about the relationship between value and control is that value is not a constant. Project A may be worth 70 million if it is finished in time for partners C and D to do their portion before dates X-Y, and only 30 million or less after that time period. Time often plays a strong role in the value of a product, and the more time impacts produced value, the more control is valued.

<comment><USER40> That assumes that software development is infinitely scalable. If you knew going into it that you couldn't make the first deadline, just start off with more programmers, right? Just like 9 women working together can produce one baby in one month, right?

Provided you have the right software developers, the product takes as much time as it takes. Managers can't "speed it up" however much they hope, pray, and wring their hands.

"Finished in time" - if the requested product can't fit in that time window, then the only thing to do is cut features. Agile teaches us that if we start with the highest value features _first_ , we can meet any deadline by cutting features as we get there.

Throwing intense estimation to see if you can hit that "finished in time" point with a giant list of features is simply waterfall - and studies have shown that (for most software projects) waterfall cannot predict _a priori_ whether or not you will hit a deadline.

Thus, if you're working on a project where TIME and SCOPE are fixed, you're boned to begin with. Spending a few weeks waterfalling won't get you out of it. If anything, you burned precious developer time in the process.

<comment><USER42>
      That assumes that software development is infinitely scalable.

I don't see how overgryphon's post assumes that; whether the project can meet the required deadlines could be a go/no-go decision rather than an assign- more-resources decision.

<comment><USER40> But even assuming you do Waterfall - which has super strict requirements gathering and estimation - you still don't get a very high degree of confidence that you'll hit some arbitrary date in the future. Again, if your software has a go/no-go based on hitting some date many months in the future, you're in a no-win situation. Odds are astronomically small you'll hit it if SCOPE, TIME, _and_ EFFORT (people, since adding people to a late) are fixed.

Again, to paraphrase DeMarco, if the project is that sensitive to time/cost, it's probably not delivering enough value.

<comment><USER42> What would you say to a games company that wants to get their triple-A title out in time for the holiday season, instead of releasing it in January?

<comment><USER40> I've never worked in the games industry, but it's my understanding (from the sidelines, reading about EA Spouse and all that) that games company execs decide on a release date and then throw everything they've got at it to make it happen (long work hours, working weekends, etc.).

And given how often games get delayed (Unreal, Team Fortress, Duke Nukem etc.) it seems they're not very good at predicting software delivery dates either.

I'm not stating that software developers shouldn't estimate at all - <USER2> considering the angles helps you design it better - just that estimation in pursuit of nailing down a delivery date weeks/months in advance is a bad idea.

<comment><USER42> We all know the quote that adding extra developers to a late project make it even later. So if you have a market-imposed deadline you've got to get the number of developers correct from the beginning of the project. Hard to do without that much estimation.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> Where's the box where the project manager, given an otherwise realistic estimate of project time, decides that the number is too high, and cajoles the developer into cutting everything by half (or more)? Because that happens _all the damned time_. I've even got a catchy headline: _"Why do managers always want to squeeze blood from a stone?"_

Granted, newer programmers are bad at estimating these sorts of systematic overheads. But people get better at estimating as they gain experience. One root problem that _never_ goes away is that the people who want the estimates don't often want to hear about a cost that can't be broken down by line-item and individually justified. An answer of _"it's going to take twice as long as we think"_ , however true, rarely satisfies a manager.

</comment><comment><USER44> Simple: programmers' productivity has very high variance, especially in team project. It's not because programmers are unpredictable, it's the nature of the work. Some main reasons are:

1) Programming (by that I mean R&D, not configuration/deployment) is, by definition, creating new stuff. So unless the new project is very similar to a previous project, even experienced developers wouldn't be able to provide good estimations.

2) There's always a degree of tradeoff between reliability and new features in every design decision. Should I use the new version of this library with more functionality but has not been tested with current code base? Should there be an incomparability, do I have the time and expertise to work it out? etc.

3) Dependency on other team members and/or other teams.

</comment><comment><USER45> I am bad at not lying about it. To myself and anyone who asks. Mostly forgetting that in reality I can't ignore life's other functions and loops.

It's going to take longer than I said. But it'll be better than I described.

</comment><comment><USER46> I live my life on the Scotty Principle... [http://www.urbandictionary.com/define.php?term=Scotty%20Prin...](http://www.urbandictionary.com/define.php?term=Scotty%20Principle)

</comment><comment><USER47> Most of the errors in estimating time when programmers do estimations is the assumption that requirements are final. The requirements are never final, and never will be.

</comment><comment><USER48> Evolution. Our ancestors were the optimists who underestimated the difficulty of capturing that horse, crossing that ocean, turning that land into a farm. Those who could accurately estimate the difficulty wisely avoided it, didn't go hunting, didn't reproduce.

If it was really just a matter of uncertainty, we would overestimate the difficulty as often as we underestimate. But we don't. Humans consistently underestimate. I really think it's evolution.

</comment><comment><USER49> What it makes really hard to be well on estimating time: Programmers often have to solve problems they solved never before. You rarely solve exact the same problem multiple times. And what it makes even more difficult: The environments and tools you have to solve these problems are changing. So you don't really have that much experience you can rely of.

</comment><comment><USER50> I think what makes most of us bad at estimation is that we estimate based on effort and not duration. A good example of that is the first item on the chart - the 30 second code change that takes an hour. As a solo consultant I've stopped giving estimates for both and only give duration estimates without the explanation of the difference.

</comment><comment><USER51> Ask a house contractor for an estimate and you will find out how off he is when the house is being built.

Ask a bridge builder for an estimate and you will find out the project is delayed for years (see Bay Bridge retrofit).

</comment><comment><USER52> It's not possible to estimate _debugging_ time

<comment><USER17> Kind of. Debugging a serial protocol takes time to set up the line monitor, run the tests, validate the behavior against the spec, diddle the state machine to bring it into conformance. Actually pretty easy to estimate that process.

But other code, its different. Especially tinkering with a big ol dinosaur of code, to add/change a feature. Debugging becomes almost the whole effort there.

</comment></comment><comment><USER53> Easy - The requester asks for "time" not "duration" Programmer responds with "time".

</comment><comment><USER54> Great comments in this thread so far. Let me summarize a few and add some of my own:

1) Some people do not want estimates. They want unrealistic promises for purposes that have less to do with the project, and more to do with making themselves look good in the short term (for a promotion, bonus, whatever.) If you're in this situation, you need to go out of band with your communication about the project (i.e., above someone's head) or find a new position/manager. This is not a good place to be.

2) As some have mentioned, when people ask for when it will be "done", qualification is needed. Very often you may be asked for "calendar time", not "perfect engineering days" or their equivalent. Make sure you figure out which is being asked of you; not doing so can end badly.

3) Some estimates are well within the range of the possible, others are truly just not easy to come by. Figuring out the difference between these and communicating them is extremely important. "Build a perfect X system for our Foobarbazio engine." "GiantCo spends millions a year on this problem and still hasn't solved it. No one has. More basic research is needed (on AI, ML, NLP, whatever) to even begin to do this." "I don't believe you! Bilk-us Consultants says they can build it in 3 months! What do we pay you for!" "..." They aren't all so easy to tell apart.

That all said, there are many good rules of thumb to get you at least a basic estimate, many of which are covered in the above comments. If I had to pick a few favorites, I'd pick:

1) Ask someone who has done it already. If someone hasn't the (almost) exact thing, ask someone who has done something roughly similar. If you can't find that, ask someone who has done something /vaguely/ similar. Try to transpose the specifics (they used Oracle, we're using Postgres; they used a great library, we have to write our own.) If this is truly green-field stuff, try to:

2) Build a prototype. No, you will not get the one million tiny details that can bite you during real development, nor the unknown unknowns that can crop up while trying to solve truly hard(er) problems, but it can be a helpful way for getting your mind wrapped around the problem. If this isn't enough, you can also:

3) Build another prototype (it's the second, so maybe we should call it a deuterotype.) Flesh it out. Make it bigger than the original, but ignore the (currently) irrelevant details. Yes, this takes longer, but it's better than getting halfway through full-time development and realizing it's not going to work.

4) If after doing the above, you feel like you're no closer to an estimate, either give up and just develop it, and you'll eventually get to the point where you might be able to estimate the rest. This can of course blow up if you hit an impassable snag; that's why it's a last resort.

</comment><comment><USER55> my manager is worse, and he doesn't even program!

</comment><comment><USER56> because they don't account for the 8 hours a day they spend on HN

</comment><comment><USER57> I've long maintained that time estimates should not be a programmer's task, at least in most shops. That's one of the few things that a "manager" should do and do well: insist on realistic and as-precise-as-possible requirements, collect metrics over time to make rational estimates, and shield the team from eternal corporate stupidity.

</comment><comment><USER58> 99% of the time, I'm bad at estimating time because my boss or manager decides to keep changing the requirements.

</comment><comment><USER59> And managers are bad at understanding how long it takes to do pretty much anything.

Most effective flow I've found is: 1) ask programmer how long, 2) drop that number by 1/3 and give them a deadline, 3) indicate that the deadline needs to be adjusted if anything unforeseen appears.

Adjust ratio in item #2 as the team grows the relationship.</comment>


Windows 8 Is Taking The Wrong Approach To Competing With The iPad - <AUTHOR> http://www.businessinsider.com/windows-8-2011-9

<comment><USER2> Boo:

"Tablets are a different form factor and interface paradigm from the PC, so software made from the ground up for tablets is always going to be superior to software made for both."

That's bullshit. That's like saying "mediocre software made by developers spending no time in UX will be user-unfriendly" or "websites made for firefox 3.6 only will look like shit on ie6 or chrome". The point is, if a developer spends their time making a piece of software good and usable, the form factor and mode won't matter. You target what you need, not random crap with drop- downs. That's what people are learning nowdays.

"Microsoft is stuck in the classic innovator's dilemma: it's doubling down on the features of its offering that are getting disrupted instead of trying to disrupt the disruptors."

Again partially true. Yes disruptors are making small applications which do their nich well, but that does not mean nobody wants a really really f-ing good terminal application for power users. Also you can't develop on a tablet. Also you can't play many online games on a tablet. My wife still users her windows PC sometimes while using iPad other times. Multi-Tasking is hard to do well, and the iPad approach does not work that well for my non-tech-savvy wife. It satisfies some, but not all people. In either case, yes it's not all about feature-for-feature, but its about finally making the tablet form-factor viable for Windows which is never was.</comment>


In Defense Of Windows - <AUTHOR> http://lifehacker.com/5858462/in-defense-of-windows?tag=rants

<comment><USER2> One of the main advantages for windows is that backwards compatibility is excellent (I can generally run programs for Win95 without getting into some weird dependancy hell) and I have never had a big update (like a service pack) totally break everything like I have had with pretty much every linux distro I have ever tried.

One thing I never really understand is why people complain about windows RAM usage, especially on recent versions. RAM is cheap and you have about 8GB of it , why are you complaining about it showing usage of 2GB after boot? You didn't buy all that memory for it not to be used, surely most of this usage is due to windows preloading commonly used DLLS into memory at bootup so parts of the system can load faster?

I heard at one point that data to be preloaded is deliberately organized into contiguous blocks on disk so it can be read quickly in one pass, giving an overall performance win vs seeking all over the disk later trying to load in bits of DLLS to run a program?

I'm sure somebody can correct me on the details of that.

I'm not sure the security argument is even particularly valid anymore, is there really any concrete reason that a Unix OS has an inherent advantage over an NT based system?

I think allot of the issues stem from the culture (or pherhaps lack of it). Linux users are generally happy with their open source software from aptitute , whilst Mac users only tend to use a small number of good quality commercial apps. On the other hand a huge number of windows apps seem to be 'freeware' type apps that make their money by bundling crapware, also there is more pirated software used which I suppose would be more likely to have viruses bundled. I generally stick to either open source or fully paid up commercial software on my Windows 7 box and I've not had any real problems.

<comment><USER3> 2G of OS is 2G of data I have to hit spinning disk for. My workstation is much more than a Word/Browser box, and I never have enough RAM.

I find it a pain in the ass to work in Windows. Sure it's backwards compatible, but it seems like none of the packages I need are ever packaged for Windows. In Ubuntu, a 'sudo apt-get install' can get me pretty much anything I could ever want.</comment></comment>


Elixir For Rubyists Part 1 - <AUTHOR> http://www.natescottwest.com/blog/2013/09/26/elixir-for-rubyists/

<comment><AUTHOR> I'm sure I'm not being clear enough so please let me know where I can make improvements and let me know what questions you have for part 2.</comment>


Millions watch live streaming of hospital construction in Wuhan - <AUTHOR> https://www.shine.cn/news/nation/2001290804/ <comment><USER2> Here are the said streams:

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

[https://m.yangshipin.cn/static/2020/c0126.html](https://m.yangshipin.cn/static/2020/c0126.html)

[https://m.yangshipin.cn/video?type=2&pid=600016637](https://m.yangshipin.cn/video?type=2&pid=600016637)

<comment><USER3> Original source: [https://m.yangshipin.cn/video?type=2&pid=600016643](https://m.yangshipin.cn/video?type=2&pid=600016643)

<comment><USER4> It's very interesting that at this stage it doesn't look very different from any other construction site: 37 people chatting and walking around while the other 4-5 do some actual work.

<comment><USER5> What? Are you looking at the same stream? I see an intensely busy construction site with 10s of trucks and cranes and hundreds of people. It's extending to the right - perhaps you've missed that. Certainly not typical

<comment><USER6> They commented 30 minutes ago. Things may change in that time frame.

</comment></comment></comment></comment></comment><comment><USER7> Guess this might be a candidate for _the list_: [https://patrickcollison.com/fast](https://patrickcollison.com/fast)

<comment><USER8> It might be nice if the list was in a git repo that people could contribute to

<comment><USER9> Yeah. I'd like to add HMS Dreadnought (1906). It was the first proper battleship ever built (truly revolutionary), and it was built in one year and one day.

</comment></comment></comment><comment><USER10> I can't help but recall a tiny little <5000 sqft, one story building close to my residence (in the U.S.) that took almost a year to construct a few years ago. Somehow the construction workers managed to show up every weekday, wake me up with construction noise while accomplishing almost nothing...

<comment><USER11> This hospital is temporary. It doesn't need to be high quality, because it doesn't need to last, and its purpose is to be better than nothing. Most buildings take longer, because they're intended to last, and because they don't have such enormous crews working on them (which costs a lot). Some of the processes in this live stream don't seem especially safe to my non-expert eye either (I'm thinking of the cranes and diggers quickly moving big heavy swinging things; in NZ I've only seen that done with extra people manning guide cables to keep the movement slow and controlled).

<comment><USER12> Never underestimate the efficiency gained by completely circumventing the need for permiting, civic reviews, public commentary, funding allocation, bidding, design review, labor negotiation, inspections, regulations, and a zillion other bureaucratic wastes of time.

</comment></comment></comment><comment><USER8> 25M construction site supervisors. Imagine if we could have that for programming ;)

</comment><comment><USER13> Diseases are rivalled only by war in bringing out the best in human creativity and ingenuity.

<comment><USER14> Pure nonsense imho. Everytime there is an epidemic are new 1000 bed hospitals going to be erected overnight?

Where the heck are doctors and nurses going to come from? Do they have excess trained people just hanging out at the mall?

God knows how many other hospitals and construction projects were thrown into chaos by crews being pulled from all over the place.

This is the kind of reaction seen when too much power lies with one guy up the heirarchy and he panics and overrules all his underlings. Wants to give an appearance of solving a problem much more than actually solving it.

I have seen this kind of stuff happening at global software crisis centers, where things escalate quickly and some guy up the hierarchy panics. Has too much power and just overrules everyone below. "We have to do something! Right now!!!" Bangs table!!! Underlings without push back obey. Those who do are pushed out and resources are mindlessly pulled from all over and massively squandered. With the PR dept blaring away about decisive leadership.

China has all the ingredients for that kind of decision making. The bug will die out in a couple weeks and then this will be a standing monument to how the herd reacts under stress.

<comment> Brave-Steak Seemed to have helped the last time they did exactly this. So I don't see it as an overreaction or completely irrational. Reports say that the makeshift hospital they built in record time for SARS in Beijing turned out to treat 1/7th of all the SARS patients at the time. And judging by the projected infection rate numbers, and their medical infrastructure _already_ being stressed so much by a load that it probably wasn't designed to handle, building these hospitals could very well be a good move.

> Where the heck are doctors and nurses going to come from? Do they have > excess trained people just hanging out at the mall?

I'm sure there are regions that aren't facing even remotely the same crisis as Wuhan, where they can divert resources from. It's really not a huge deal. Unless you want to make the claim that _all_ of China is going to succumb to this such that a diversion of resources wouldn't be possible at all? That's a stretch.

<comment><USER15> The current hospitals are based on the 2003 design. One reason that they can be constructed so quickly.

(I was skeptical myself initially. Looks like it's actually coming together.)

</comment></comment></comment></comment><comment><USER16> Links to the streams;

Leishenshan: [http://t.cn/A6PIeT14](http://t.cn/A6PIeT14)

Huoshenshan: [http://t.cn/A6PIYNvD](http://t.cn/A6PIYNvD)

</comment><comment><USER17> The livestream comments are just fascinating. For some reason live chat brings out the worst in people.

It's also amazing how inneficient the whole construction medium is with human resources. Everytime I see construction going I see most of people are literally doing _nothing_ and it's not like their lazy - human resource distribution just sucks.

</comment><comment><USER18> Fascinating how quickly something can be accomplished in an emergency (shortcuts accounted for)

</comment><comment><USER19> Wouldn't be dangerous to live in buildings nearby the "coronavirus hospitals"?

<comment><USER20> I think it's fine with proper controls. I don't think the virus is going to fly out the smoke stacks and infect anyone. Of course getting infected people in can be dangerous if they're just walking themselves to it, or taking a taxi.

In Hong Kong there were protests against the gov't using an apartment building of sorts for quarantine, because the building was within 500m of residences. One protester even set fire to the lobby of the building.

[https://twitter.com/ezracheungtoto/status/122140698236137881...](https://twitter.com/ezracheungtoto/status/1221406982361378817?s=21)

<comment><USER21> Actually, some dude took a fat shit during the SARS epidemic and infected 329 people in other apartments...

I think I came across this on HN many, many years ago!

[https://www.sciencedirect.com/science/article/pii/S120197121...](https://www.sciencedirect.com/science/article/pii/S1201971211000245#bib0160)

From this paper [https://europepmc.org/article/med/15737152](https://europepmc.org/article/med/15737152)

"The index patient in the second super-spreader outbreak was an individual on hemodialysis for chronic renal failure who had diarrhea and, on two occasions, stayed with his brother in Block E in the Amoy Gardens residential complex.30, 31 Amoy Gardens has 19 residential blocks, with eight apartments on each of the 33 floors.31 In several bathrooms from block E, it was reported that the U-shaped traps linking the vertical drainage pipes, known as risers, to the sanitary fixtures, did not function properly. As a result, when water flowed down, the backflow from the risers was able to generate aerosols and spread pathogens into individual bathrooms. In addition, powerful window fans installed by residents in many bathrooms created a significant negative pressure that amplified the aerosol backflow. In the Amoy Gardens complex outbreak, 329 individuals were infected and 42 died."

</comment></comment></comment><comment><USER15> What was on the sites before? Or what was previously planned for them?

I'm curious about backstory and disruption here.

</comment><comment><USER22> Is there a link to the live stream?

Edit - Found it: [https://www.youtube.com/watch?v=Ypti_cB0JTc](https://www.youtube.com/watch?v=Ypti_cB0JTc)

</comment><comment><USER15> Is there any sort of timelapse video available?

</comment><comment><USER23> Haha, I wish sometimes I could live stream my work. It might be entertaining and I like writing code as people watch.

<comment><USER24> One main barrier is API Keys, emails, secrets etc. It wouldn't be possible for me to stream my work because of this.

I was thinking of making a filter of the video stream which would blur out sensitive strings if it encountered them...

I suppose I could just use an offscreen terminal for environment variables and secrets, but it's bound to be leaked at some point.

<comment><USER23> I wonder if it works better if you're just building an offline app.

</comment></comment></comment><comment><USER25> Boredom brews greatness.

</comment><comment><USER26> Coronavirus is completely overblown. Regular influenza kills 12,000-61,000 Americans each year.

Coronavirus is only deadly to elderly with existing medical problems. Its not worth shutting down the economy over. Reducing this population would also entail a reduction in healthcare and pension expenses, benefiting younger workers.

<comment><USER27> Let me guess, you are not part of the demographic you just opted to let die in the name of cost reduction?</comment></comment>


Code of Hammurabi - <AUTHOR> https://en.wikipedia.org/wiki/Code_of_Hammurabi <comment><USER2> Hammurabi's code is prominently featured, ruminated upon, and contextualized in Nassim Taleb's _Skin In The Game_.

It's a profound and highly recommended read, especially considering the sheer amount of downtime that's available at the moment.

<comment><USER3> I thoroughly enjoyed Taleb's earlier books: Fooled By Randomness and Black Swan. Even AntiFragile is pretty good.

IMHO "Skin in the Game" is where Taleb jumped the shark. I understand the ideas behind it but it's just too much.

</comment></comment><comment><USER4> __Adultery Ex. Law #129: "If the wife of a man has been caught lying with another man, they shall bind them and throw them into the waters. If the owner of the wife would save his wife then in turn the king could save his servant." __

Crazy how much our laws have evolved since then.

<comment><USER5> > If the owner of the wife

In Hebrew the word husband is the same word as owner. Other translations use husband rather than owner.

How much do we really understand the meaning of these ancient texts?

<comment><USER6> >then in turn the king could save his servant."

Yeah, I don't understand what this part means at all honestly.

<comment><USER7> I would interpret this as the king being allowed to pardon the citizen who committed the adultery, if the husband chooses to forgive his wife.

I actually like the law. While it does still display an asymmetry of power in the relationship, it implements a negative incentive for cheating for both men and women. This is progress compared to a more primitive law that one could imagine where women could be punished arbitrarily, e.g. to death, while the man in the cheating act could not be punished by law.

Also, it seems better than vigilante justice. It gives both parties in the decision making the opportunity to show empathy, and so acknowledge the adultery without explicit punishment.

<comment><USER8> It's hard to grasp that old "bad" laws could still be very progressive.

I remember a teacher telling us that "an eye for an eye" should be viewed not as a crazy excessive response, but as a very modern "the punishment should be commensurate to the crime", which was not a given.

</comment></comment></comment></comment></comment><comment><USER9> I would like to think the very first strategy home computer game was about Hammurabi, Hamurabi.bas, [https://www.acriticalhit.com/sumerian-game-most- important-vi...](https://www.acriticalhit.com/sumerian-game-most-important- video-game-youve-never-heard/)

</comment><comment><USER10> Also see: [http://enwp.org/Code_of_Ur-Nammu](http://enwp.org/Code_of_Ur-Nammu)

</comment><comment><USER5> Please add (1754 BC) to the title.

<comment><USER11> Wikipedia pages don't date from that era.

<comment> 52-6F-62 I think it was a bit of a wry joke</comment></comment></comment>


Google not acquiring Akamai - <AUTHOR> http://www.bloomberg.com/news/2011-10-12/google-is-said-not-to-plan-akamai-takeover-after-report-raised-speculation.html

<comment><USER2> Its not technically ironic but certainly amusing that businessinsider's story about akamai was so popular that it crashed their site, which could have been avoided by using akamai (or any cdn).

<comment><USER3> It would be a good marketing effort by Akamai to boost their sales, by crashing mainstream business web sites;

</comment></comment><comment><USER4> Out of curiosity, I wonder if it would be illegal for a journalist to falsely report a critical story about a company while buying short term puts to profit from the stock freefall. There are early stage biotech companies going through clinical trials where reporting failure could easily tank the stock 80% in a day.

While this is clearly ethically corrupt, this technically isn't insider trading since the journalist didn't have any insider info in the first place. Any thoughts?

<comment><USER5> No, it wouldn't be illegal as the journalist is purely speculating without any insider information. However, if the money involved in the trade is high and SEC's eyes fall on the trade - there is a possibility of an investigation but that would be rare.

<comment><USER6> It really says something that we apply the word "journalist" to people who "speculat[e] without any insider information."

<comment><USER5> In this context, yes. Not a generalization.

</comment></comment></comment></comment><comment><USER7> It really threw me off when they referenced "International Business Machines Corp." instead of IBM...I can't name another instance where someone decided to use the full name of IBM

<comment><USER8> Hah, same. It's like seeing someone spell out Advanced Micro Devices (AMD) or Minnesota Mining and Manufacturing Company (3M). Just kinda weird.

</comment></comment><comment><USER9> [http://cdn.shopify.com/s/files/1/0060/6102/products/book_buy...](http://cdn.shopify.com/s/files/1/0060/6102/products/book_buy_sell_sell_new.jpg)

</comment><comment><USER10> > _"It's mostly just a rumor," according to the report._

What does that mean?

<comment><USER11> Sounds like someone is really trying to say, "it's true, but I don't want you to think it's true until we announce it."

</comment></comment><comment><USER12> This acquisition just doesn't make sense for Google, especially for the (likely) $5+ billion price tag. It'd make much more sense for a company like Apple or Facebook - i.e. one that didn't just finish building its own CDN.

<comment><USER8> It /would/ make sense for Google. Think about how many customers Akamai has and the business they're in -- Google probably really wants a part of that.

Also, how would it make sense for Apple or Facebook to acquire Akamai? Apple's in the computer and mobile devices business (and has its own datacentre for iCloud to worry about), and Facebook has no use for Akamai outside of the services it currently receives as a customer. It would be stupid for either company to consider buying it at this point.

Just my opinion.

<comment><USER12> I'm not advocating that _anyone_ should be buying it, only that it makes more sense for someone who doesn't already have their own massive CDN. Apple and Facebook are just the first two major Akamai customers that came to mind.

</comment></comment></comment><comment><USER13> I really really really get bored of journalists reporting things they heard from anonymous sources. When I read something that cites an anonymous source, i just assume the journalist was bored and decided to make some shit up.

Both this article and the article it refers to have done this and its getting extremely tedious.

I'd like to see Journalists get a degree and a license just like a lawyer or a doctor, then maybe we'll get some integrity out of an industry that is filled to the brim of fear mongering bullshit artists.

<comment><USER14> Really? I'm guessing that you think a license (which can be revoked) would result in more accountability. But just imagine how that sort of system could be used to clamp down on free press and free speech.

I'd gladly keep the system we have now; I'll just get my news from credible sources and take _everything_ with a grain of salt.

EDIT: And also... what does "It's mostly just a rumor," mean?

<comment><USER13> It would in no way hamper free speech, just as requiring a lawyer to have a degree and license hasn't restricted a persons right to legal counsel.

A lawyer's requirements to practice law are the guarantee that he is properly educated in the law, same with doctors. Granted the stakes aren't quite as high for journalists, but nor does the barrier of entry have to be made as high.

The basics of how to be a Journalist with integrity should be taught and set as a standard, what those actually are, i'll leave to someone else to define, but putting an end to quoting anonymous sources i'd say is the starting point.

<comment><USER15> You can't be serious. Licenses for law and medicine impede freedom. They limit our choices of (and the cost of) legal and medical services. We are just willing to make this trade off because average people have a hard time determining the quality of these practitioners and we don't want people going to jail or dying in surgery because they aren't very smart consumers.

You can't "improve" speech without making it less free. Sometimes the loss of freedom is worth it (like yelling fire in a crowded room) but most of the time it is not worth it. Restrict our freedom of speech so that journalists can't use anonymous sources? Give me a break.

"I'll leave someone else to define [the standard]." That's convenient, since there is no standard that would be enforceable without being oppressive. I challenge you to come up with a standard that would solve the problem you state, that would be enforceable, that wouldn't be an insult to basic freedoms of speech. You also have to define what a "journalist" is. In the internet world, we are all journalists.

<comment><USER13> I dont see how requiring credentials for a job in any way affects free speech. I'm not saying you cant write something down if you dont have a license, if you want to start a blog, magazine, newspaper, etc without a license on you go, write whatever the hell you want.

Its about setting standards and showing that you have a seal of approval from a governing body. Think of standards compliant HTML/CSS and the W3C, it sets the standard, but you're completely free to ignore it and write bad markup, but it'll be recognised by your peers that you dont meet the standard. THATS what i'm talking about.

<comment><USER15> THAT wasn't clear. Both of your examples, law and medical licenses are legally required.

Journalism schools already teach ethics and offer certificates. Reporters already are members of organizations with ethics statements: <http://www.spj.org/ethicscode.asp>

All I'm saying is legally requiring some sort of enforceable code of conduct for journalists before they can work is a violation of free speech.

<comment><USER13> Well my inability to articulate myself clearly has caused a torrid of downvotes thinking i'm some kind of free speech nazi, better not to try...

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I think Amazon would be a good purchasing party, Google alike.</comment>


Ask HN: Most Innovative Web Frameworks in 2012? - <AUTHOR>

Almost all of my software development over the past 3 years has been spent building web applications. I build mainly small to medium scale sites (read couple hundred to several thousand daily hits), ecommerce shops, the whole gambit and along the way I've used and tried out tons of Framworks, CMS solutions, etc. I like Rails, Play and Symfony2, and have recently discovered Lift (still haven't made a project with it) but it looks promising. The thing is you can basically build anything regardless, but because I build largely interactive apps ( ajax, server pushing, parallel page rendering, etc), I'm always on the lookout for a good fit in this sector. Anyway, I'd be really interested to know what toolsets (front and backend), my fellow hackers use now in 2012 to build RIA :) <comment><USER2> Thumbs up for PlayFramework, our web app dropifi.com is built on java/play. Play combines the awesomeness of the Java JVM with the simplicity of a "rails like framework" into one framework.

</comment><comment> e-dard Another Flask hacker here. Use it for all internal projects at work. 4 so far in 2012.

</comment><comment><USER3> Silex is nice for APIs and such. Laravel 4 looks like it will be great when it finally arrives.

</comment><comment><USER4> Zurb Foundation?

</comment><comment><USER5> Flask (Python)</comment>


Bitmessage: a decentralized, encrypted, trustless communications protocol - <AUTHOR> https://en.wikipedia.org/wiki/Bitmessage <comment><USER2> I highly recommend not using this, it has a variety of weaknesses and vulnerabilities. [https://bitmessage.org/forum/index.php?topic=1666.0](https://bitmessage.org/forum/index.php?topic=1666.0) is a pretty thorough analysis. The biggest problem IMO is that there is no encryption when passing messages between peers, so a passive adversary can easily determine who's sending what message.

There's over 30 years of papers and academic research on anonymous mailing systems and Bitmessage incorporates not one of those concepts

<comment><USER3> If you run PyBitmessage over tor you should be fine.

<comment><USER2> Actually, not against certain attacks. If a passive adversary knows you use BitMessage and want to determine your Bitmessage identity they can simply watch your traffic, and can determine any message you send out that you did not receive must have come from you. This can be used to determine which messages you sent, and if you respond to a request for your public key your identity will be revealed. Because the inter-peer connections are not encrypted, this is all trivial, and using Tor changes nothing.

So no, you are not necessarily fine.

<comment><USER3> But isn't the traffic between me and the entry node completely encrypted? How can a passive observer even detect I'm sending/receiving a specific message.

<comment><USER4> Timing, maybe?

</comment></comment></comment></comment></comment><comment><USER5> Iirc, a difference in bitmessage from other protocols is that it has 'receiver anonymity,' in that since a message is received by all parties, the receiver's metadata is not leaked. This is possibly a benefit over some existing protocols, although it has obvious performance / scaling side-effects.

<comment><USER6> Bitmessage is just a broadcast protocol implemented with floodfill.

Anonymity protocols are mostly divided into 3 classes: broadcast (dining cryptographers, buses, bitmessage), mixes/rerouting (mixmaster, mixminion, tor) and private information retrieval (dissent and followups).

After decades of work in the field [1], bitmessage implements broadcast in the most naive way: floodfill. Global passive adversary can simply find out where the message appeared first. If the message is encrypted with a key which is only known to the receiver (i.e., message is not for chan), everything is ok. But in this case bitmessage is not better than alt.anonymous.messages.

If messages can be linked together, active non-global adversary can measure time and exploit dynamic topology of the network to reconnect closer to the sender. Bitmessage offers no protection against it. With alt.anonymous.messages the solution is remailers, and bitmessage offers no alternative.

[1] [http://freehaven.net/anonbib/](http://freehaven.net/anonbib/)

<comment><USER5> The receiver anonymity tidbit was something I recalled from this summary [http://fanti.web.engr.illinois.edu/ciss2016.pdf](http://fanti.web.engr.illinois.edu/ciss2016.pdf) which for some reason was in my crypto / chat papers folder..

</comment></comment></comment><comment><USER6> Bitmessage is mostly used for "chans" and they are insecure. Basically, when you send a message to chan, everyone who knows about this chan can decrypt the message. So the message is essentially not encrypted.

Streams are not implemented, so bitmessage does no scale.

As you can request a list of neighbors from anyone you can easily attack network by constantly reconnecting closer to the message sources. For example, you can track down all active users of some particular chan.

Freenet project did a lot of work to protect against opennet attacks, and bitmessage completely ignores it.

<comment><USER7> Isn't the point more about concealing who is sending the message in the first place?

<comment><USER6> Bitmessage is essentially a floodfill algorithm. You just need to request neighbor list from your neighbor which delivered the message to you before others. Then, you connect to them and you are one step closer to the sender. Repeat it until you are connected to the original sender and all its neighbors. So Bitmessage does not protect you if you use the same sender identity multiple times.

</comment></comment></comment><comment><USER8> Bitmessage requires a professional security audit: [https://github.com/Bitmessage/PyBitmessage/issues/381](https://github.com/Bitmessage/PyBitmessage/issues/381)

Full stop.

</comment><comment><USER9> I would be very weary of this product. I used it a while ago on a project for a course I was taking. During my research, I found a FAQ where the creator stated that if ever asked to place a back door in it, he would.

<comment><USER10> Could I burden you for a link to that, if possible?

<comment><USER10> I browsed the tubes for a bit and couldn't find anything but the following, which is a Feature Request comment under Backend[1] mentioning a "controlled backdoor", possibly added by this contrib[2]. It reads as follows:

 _at the cost of getting scorned, but dead serious: a controlled backdoor, with an automatic audit trail, to be used by lawful agencies for keeping us safe. Bitcoin by design supports criminal activities, which undermine the community. A community messaging system should have a way of cleaning itself._

1\. [https://bitmessage.org/wiki/Feature_request_list#Backend](https://bitmessage.org/wiki/Feature_request_list#Backend)

2\. [https://bitmessage.org/wiki/Special:Contributions/14skywalke...](https://bitmessage.org/wiki/Special:Contributions/14skywalker)

Probably not the example mentioned by Parent, though.

</comment></comment></comment><comment><USER11> BitMessage is very useful for receiving notifications from Dark Net markets.

<comment><USER6> If you are the receiver, it is ok. Simply connect to the network and offer you identity to the sender, then wait for message. As you do nothing else besides connecting to the network, there is no difference between you and other users.

What is questionable is the security of the sender.

</comment></comment><comment><USER12> The amount of FUD that bitmessage is receiving is strange. It's both easy to use tool and powerful. It's shortcomes are obvious so you rely on your opsec (mainly managing your multiple identities) which is the only way to be anonymous anyway. I'll continue using it and bet on the future of bitmessage

</comment><comment><USER13> I was excited about it once, but this project doesn't seem to get a traction, so probably it's not worth to use it for real secure messaging. Awesome concept, though. I hope, it'll reborn somewhere. Spam problem is a huge problem and most other messaging systems don't bother.

<comment><USER6> Look at the Freenet Message System. It even offers the captcha.

I doubt proof-of-work can really help against determined attacker. Spammers will happily calculate proof-of-work to send spam. Spamming chans is really easy and all chans will be flooded with spam once it is worth the effort.</comment></comment>


USB Armory: Manufacturing the Open Source Computer on a Stick - <AUTHOR> https://www.crowdsupply.com/inverse-path/usb-armory/manufacturing-process

<comment><AUTHOR> In light of last week's disclosures in particular.

\- ARM® TrustZone® \- secure boot + storage + RAM \- user-fused keys for running only trusted firmware \- optional secure mode detection LED indicator \- minimal design limits scope of supply chain attacks \- great auditability due to open hardware and software</comment>


Slack's Do Not Disturb Mode Is... Disturbing - <AUTHOR> https://joshfrye.com/blog/slacks-do-not-disturb-mode-is-very-disturbing <comment><USER2> I find all notifications and badges disturbing which is why I turn all of them off on my iPhone except for phone calls/text messages from my family, alarms I set, and calendar appointments. Nothing else is so important that it needs to interrupt my work or peace of mind.

I realize that many company cultures won't allow this. But it is a huge boon to productivity and peace of mind.

I check my apps when I want to check them, not when the apps or other people want me to check them.

</comment><comment><USER3> As someone that manages a large distributed team all over the world I really like these kind of features. I don't feel the need to totally disconnect from work every night. But I've also been known to leave my phone while on vacations for real disconnects a few times a year.

</comment><comment><USER4> I'm glad I'm not anymore in a workplace with Slack (or any kind of instant messages) and there's not expectations of being available to answer messages outside of office hours.

</comment><comment><USER5> I'm astounded by this commentary - is it really impossible to put slack somewhere where you won't see it?</comment>


Why WP App Store Failed - <AUTHOR> http://bradt.ca/blog/why-wp-app-store-failed/

<comment><AUTHOR> Would love to have a discussion about this here...</comment>


Siemens to buy Mentor Graphics in $4.5B deal - <AUTHOR> http://www.reuters.com/article/us-mentor-graphics-m-a-siemens-idUSKBN1390Q4 <comment><USER2> This isn't good news. One of my ideas for open, secure hardware involved a partial or whole acquisition of Mentor by a company that was pro-FOSS. Then, the product lines would be tweaked for easy verification. Plus deals for hardware startups that got them the tools cheap to free early on with guaranteed revenue for Mentor if successful.

Now, one of the Big 3 of EDA is in the hands of a large corporation far from our interests. This kind of thing happens a lot. It's to be expected. Oh well.

<comment><USER3> Used to work at Siemens. Their open-source policies were onerous from a consumption point-of-view. Every revision of every approved open-source product had to be reviewed by their open-source legal hawks to ensure that nothing had changed. I don't remember their mandatory training on open source but I especially don't recall any encouragement to publish open source projects and to contribute to them. Great company but it certainly treated open-source with a sentiment that I can only describe as fear.

<comment><USER2> That's definitely bad. One of my ideas for Mentor didn't even need open- source, though. The idea was that they enabled export of some intermediate steps in RTL synthesis or optimization so customers could equivalence check them. I don't use their stuff so forgive me if they already do this & I just didn't know. Anyway, the initial, intermediate, and final RTL's could be checked both with testing and formal tools that were open-source. All the magic behind making those steps happen can remain proprietary. Likewise, do some OSS stuff for gate-level testing and material checks to run _after Mentor 's_. Analog stuff done similarly as there's already diverse proprietary and FOSS tools for SPICE, etc.

So, they can differentiate on verifiability while still keeping the trade secrets that make them the most money. There is risk that the intermediate steps could let people reverse engineer some of the magic. However, that's low given people can already analyze their binaries when running those steps and academics [like Mentor funds] come up with better ones all the time. The next step in my Mentor-oriented plan was same buyer acquiring eASIC so the verified, hardware designs could be practically thrown into initial production at little cost. Key IP that almost everyone needs they get for free so long as they use eASIC for the HW design for X years or iterations with a fair, royalty agreement.

Interested in what people in hardware market think of these schemes?

</comment></comment></comment><comment><USER4> Also related since both, Mentor and Harman, have a strong automotive business: [https://news.samsung.com/global/samsung-electronics-to- acqui...](https://news.samsung.com/global/samsung-electronics-to-acquire- harman-accelerating-growth-in-automotive-and-connected-technologies)

<comment><USER5> Strange, because Siemens sold their automotive business (VDO) to Continental in 2007.

<comment><USER6> I think times were a bit different then. People are bracing for a major change to the automotive business between autonomous driving and electric cars.

<comment><USER7> Exactly. Siemens has already proved it can build motors for electric plane and they could easily become major player in electric vehicle industry.

</comment></comment></comment></comment><comment><USER8> Intel->Altera,

Siemens->Mentor,

It'll be interesting to check _Siemens ' Modelsim - Intel edition_ and to see if they will eventually move to Qt for the GUI!

</comment><comment><USER9> Alt Headline: Siemens to buy Mentor Graphics for 0.15 LinkedIns, or .23 WhatsApps

<comment><USER10> Mentor graphics has revenue of 1 billion, instagram has revenue of 3 billion and maybe more growth potential.

</comment></comment><comment><USER11> Hopefully it will not get (too much) infected by corporate red tape and inefficiencies of the parent company

<comment><AUTHOR> Well I work here, and its safe to assume that it was already infected...lets hope that the parent company does the opposite...

</comment></comment><comment><USER12> $4.5B, not $45B.

<comment><USER13> The title is a unintentional clickbait...lol

<comment><USER14> Funny... The title made me research the company some. I don't think I've heard of them.

<comment><USER15> Only few people have contact with their product, but if you have to work with hardware description languages like VHDL or Verilog or want to design a chip, you will be very familiar with them. I think Mentor dominates the market together with Cadence and Synopsis. The tools used for chip design are so incredibly complex, it's impossible to build a competing product without decades of experience and development.

What I find interesting is that tools like ModelSim don't look like modern software, the UI was never changed because it's not important. Examples:

Mentor Modelsim: [https://www.youtube.com/watch?v=9mpRF6bAY1g](https://www.youtube.com/watch?v=9mpRF6bAY1g)

Cadence Virtuoso: [https://www.youtube.com/watch?v=DPCu822wXPQ](https://www.youtube.com/watch?v=DPCu822wXPQ)

Synopsys Design Compiler: [https://www.youtube.com/watch?v=JvZmwWJ2FGI](https://www.youtube.com/watch?v=JvZmwWJ2FGI)

<comment><USER16> It's important to note that most if not all of these tools are written for Linux first. You would usually have a local server running the tools which you'd then SSH into and use X11 forwarding to get the GUI. Interestingly, most of these tools can be fully automated and operated from the command line using Tcl (Mentor), or even a custom scripting language like Cadence's OCEAN.

I personally found Cadence Virtuoso to have above average UX, but I do agree that the GUI looks slightly dated.

<comment><USER17> They didn't start by writing their tools for Linux, as all of these companies were founded in the eighties and started writing their software before Linux even existed...

And Mentor Graphics initially ran on Apollo machines, which were running a proprietary though somewhat Unix-like OS ([https://en.wikipedia.org/wiki/Domain/OS](https://en.wikipedia.org/wiki/Domain/OS)).

[https://en.wikipedia.org/wiki/Mentor_Graphics](https://en.wikipedia.org/wiki/Mentor_Graphics) [https://en.wikipedia.org/wiki/Cadence_Design_Systems](https://en.wikipedia.org/wiki/Cadence_Design_Systems) [https://en.wikipedia.org/wiki/Synopsys](https://en.wikipedia.org/wiki/Synopsys)

<comment><USER16> I'm not familiar with the history of their tools to be frank. I was talking about their current offerings, which are as I said mostly designed to run on Linux, with Windows support added in as an afterthought - if you're lucky.</comment></comment></comment></comment></comment></comment></comment>