Why do we fall into the rewrite trap? - <AUTHOR> https://www.justindfuller.com/2020/01/why-do-we-fall-into-the-rewrite-trap/ <comment><USER2> A reminder that Joel Spolky's essay being cited is about people rewriting _ugly_ code that already works.

That nuance is important because successful companies do invest in rewrites when there's an _architecture_ change because it's the cleanest most economical way to do it. My previous comment of Microsoft examples: [https://news.ycombinator.com/item?id=19245653](https://news.ycombinator.com/item?id=19245653)

Another example is Google rewriting their early web crawlers of Python/Java into C++ to make them more efficiently scalable to thousands of machines. They also rewrote the frontend web server from C++ to Java.

But some rewrites also failed such as Evernote's rewrite to C#/WPF.

I think for the topic of "rewrites bad/good", it's better to list a bunch of famous real-world case studies and extract the common criteria that makes rewrites successful.

<comment><USER3> I think the ironic thing about Spolsky's example is that, in the end, it worked. It eventually gave birth to Firefox. So I think there are many lessons to be learned about _how_ to do a rewrite, how to message it, how to do it in a way that it doesn't stop other forward progress. But if a rewrite fails, that doesn't necessarily mean that _not_ doing a rewrite would have been any more successful in the end, and that's the trap I think people fall into.

<comment><USER4> Joels article was written in 2000 and Firefox 1.0 was eventually released in November 2004. In the meantime they lost almost all their market share. They eventually won some of it back, but this was probably only because Microsoft had stopped all development of IE and disbanded the IE team.

Usually you can't count on you competitors stopping all development for half a decade.

Obviously you _can_ rewrite from scratch and end up with a fine product, since the original version of the was developed from scratch. The question is if you can accept losing all customers and wasting years of effort.

<comment><USER5> There is still more to the story though. When Netscape went under and open sourced their code, they had to rip out all of the proprietary bits. The result? What they had didn't actually run!

It wasn't a question of rewriting working code. It was a question about whether the better path forward was to try to fix what they had and didn't understand, or whether to rewrite into something that they understood.

In other words, Joel set up a straw man argument.

<comment><USER4> They could just rewrite the components which they didn't own, then. They would have to do that anyway.

I'm not sure what you mean with "didn't understand". It was their own code. They could just read it.

<comment><USER5> _I 'm not sure what you mean with "didn't understand". It was their own code. They could just read it._

I meant exactly what I said.

The missing proprietary bits were not their own code. There was nothing to read and no documentation. They could see the call, and that something important happened, but what it did and how it should work was guesswork.

Furthermore key people were gone. How the code that they had was supposed to work is harder to dig out than you might think. Read [http://pages.cs.wisc.edu/~remzi/Naur.pdf](http://pages.cs.wisc.edu/~remzi/Naur.pdf) for an explanation of why.

Just to add to the fun, just getting the browser running wasn't enough. Netscape and IE were incompatible all over the place, on everything from how styling worked to what order event handlers ran. (In IE, the thing you clicked on gets the event first. In Netscape, the window did. That's a pretty fundamental difference!) They needed to not just have a running browser, but have a browser with enough IE compatibility that it could be usable on webpages designed for IE. It is easier to design something to be compatible from scratch than to find out what deep assumptions need to be changed in existing code to fix incompatibilities.

As fun as it was for Joel to beat up on them for their choice, their choice was arguably the best way forward given the actual situation.

<comment><USER2> _> The missing proprietary bits were not their own code. There was nothing to read and no documentation. They could see the call, and that something important happened, but what it did and how it should work was guesswork._

To your point, the following link is another famous example of smart programmers not being able to easily understand someone else's source code. Raymond Chen at Microsoft couldn't easily figure out why Pinball didn't work in 64bit Windows and gave up:

[https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=58...](https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=5803)

<comment><USER4> I'm sure they could have figured it out if it was important enough. They just decided it was not worth it and scrapped the product instead.

"we couldn't afford to spend days studying the code trying..."

So the estimated time to fix the bug was on the scale of days. It would certainly have taken longer to rewrite the game from scratch if that was the alternative.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Rewriting from scratch is usually, but not universally a bad idea. There are times in your life when you encounter that piece of legacy internal software that is simply garbage. The math is simple if it takes less time to rewrite than to refactor then rewriting is better, but also keep in mind that estimating software efforts is often inaccurate.

I have also noticed that in Agile teams refactoring is generally not rewarded and sometimes is even discouraged. Instead it is a voluntary effort taken at the developer's expense and risk, which is perhaps the greatest crime of Agile.

<comment><USER7> > _I have also noticed that in Agile teams refactoring is generally not > rewarded and sometimes is even discouraged_

As a long time Agilist, the spread of Fake Agile is a sad thing to see.

Constant refactoring is a _core_ Agile practice! [https://martinfowler.com/bliki/OpportunisticRefactoring.html](https://martinfowler.com/bliki/OpportunisticRefactoring.html)

<comment><USER8> I always get nervous when "refactoring" shows up on the backlog and then gets deprioritized. In my mind it should never show up as a separate task and then it should never get ignored . It should just be a normal part of the workflow for professional development that gets done without much fuzz. Most long term technical debt can be reduced a lot by proactively refactoring small things that for some reason don't work well.

When I worked closer to production the people at the workshops also cleaned and repaired their equipment every evening, crunch time or not. They didn't just let their machines die long term because it may buy some time in the short term to skip maintenance.

<comment><USER9> This has been my experience. Carving out time for refactoring explicitly is only beneficial when your stakeholders, PM's, etc. understand its importance completely. Usually, at least one person up the chain says "it's already working and we have more important things to focus on. Put it on the backlog indefinitely."

Better to just incorporate refactoring into the estimate for any given coding task and do it without explicit permission. Unless of course you're in a culture that is willing to straight up miss a deadline in order to get refactoring finished.

<comment><USER8> "Better to just incorporate refactoring into the estimate for any given coding task and do it without explicit permission."

It should be as implicit as attending planning meetings. For some reasons PMs usually have no problem forcing people to sit through meetings but they have a problem with spending the same amount of time refactoring .

<comment><USER10> Evidently the answer is refactoring _during_ meetings. /s

<comment><USER9> Sarcasm not needed. I've probably done this during a meeting. I definitely code if it's an all hands on deck meeting that gets hijacked by technical discussions that aren't relevant to my work.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> One of the oft-unspoken things about refactoring is that it's a way to do a rewrite without anyone noticing. Essentially it's the Ship of Theseus gambit: [https://en.wikipedia.org/wiki/Ship_of_Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus)

Later on I realized a sort of reverse Catch-22 in this: The people who are most capable to do a rewrite are also the least likely to ask for one. They will just do it.

An official rewrite often just becomes a pressure release valve. During the early stages nobody can measure how the team is doing, so the team gets a break from scrutiny. Whether that's healthy or not comes down to a lot of factors, but the odds are in favor of it being unhealthy.

<comment><USER12> I rewrote two applications, once on my own, once with some help from the team. The first time we switched the backend to a completely new framework (I'm in the middle of one of those right now...) and the second time we upgraded from an outdated version of the framework to the latest one in one go (so, essentially a rewrite from the ground up).

Both times sucked, both times we underestimated the amount of work to be done, and both times we were much happier with the new product than what we had before.

<comment><USER11> If the team refuses to work on the old code, you have to do something. A rewrite may be the least bad thing you can do in that case, but if you don't ask how we got here and why we won't end up right back here again...

The Relentless Improvement model that many refactoring advocates espouse is one (great) answer to that question. But it also means they won't wait for a rewrite. They'll fix the bullshit they're staring at today, and stare at some other bullshit tomorrow.

<comment><USER13> Lately I've been testing a "third way" of thinking about refactor/rewrite decisions, which is to first document the existing requirements.

The trick is in making those docs so small and lean that they fit neatly in comments inlined with key functions, and this I have accomplished by reduction to a list of "must" and "cannot" (abbreviated to + and -) bullet point items. It must function like this, it cannot function like that. Some requirements can be turned into automated tests or static checks, others need an eye to verify. But the cycle I'm seeing often works out to be: write speculative requirements, write speculative code, then reverse-engineer true requirements and maintain code against that.

Doing this creates a base quality bar that the code has to hit in both the rewrite and refactor cases. The trap that rewrites tend to fall into is that the requirements are lost during the rewrite, so the new code becomes just as speculative as the original greenfield code. If you have the requirements as your reference, on the other hand, the area of bad code you can write is limited to the boundaries of those requirements and any missing requirements. This makes new code much less of a gamble.

<comment><USER11> That's a very good point.

It's so hard to get people to write good requirements that we often overlook (or rather, won't look at it) as a solution.

Rewrites are easier with good requirements. They're a constant stream of bad surprises without them.

It's possible, while refactoring, to begin to collect those requirements, in the tests if nowhere else. But it's not a given.

</comment></comment></comment></comment></comment><comment><USER14> _The company had built heavily around .NET, which, while it has its merits, did not provide the type of experience that was best for this environment._

And then he makes the same mistake that his entire article is based on. He _needed_ to rewrite the code to use Angular instead of .Net? I'm assuming he meant he needed to use Angular instead of server side rendering. I can't imagine a scenario where server side rendering wouldn't have gotten the job done. Especially since he admitted that he didn't need high UI performance.

<comment><USER15> It depends, I've some some beasts built in ASP.Net Webforms. Worse than anything you'd see in PHP from a reliability and extensibility perspective (although factors better in security - Microsoft pushed their kludgy ORM hard back then whilst PHP tutorials started with string-based SQL).

If I inherited an ASP.Net Webforms product which was built by amateurs from an MVP/PoC which would go on to form a very small part of a large product then I would absolutely re-architecture (and thus rewrite) it.

If it's an existing product the the rewrite cannot be compartmentalized then there's no way I'd touch the code.

In the scenario of an aging product I think that you're honestly better taking your best engineers and product people and starting again. At some point when the new product is mature enough you can look at how to move the last straggling customers over. I've seen that done successfully by clients and also by large companies (Microsoft with WebForms > MVC and later .Net Framework > .Net Core).

<comment><USER16> WebForms is pretty similar to Coldfusion. Which he spent the whole start of the article saying was fine and got the job done.

There's nothing inherent in .NET that would 'not provide the type of experience that was best for this environment'. If anything, probably the vast majority of code that is written for managing 401Ks out there is probably written in .NET or Java.

</comment></comment></comment><comment><USER17> In my experience it's a management problem more than a technologist problem. New engineering manager, wants to leave their stamp, has a grand vision, and is able to get buy in and budget from the higher ups.

"Higher ups" in most companies don't have the tech literacy to question such a move. And there's a lot of ego going around to say "this time is different" when it's really not.

Usually when I see just a technologist push for a "big rewrite" they won't succeed without management allies or enablers.

One reason this happens is that management and technologists alike have a huge dearth of skills when it comes to dealing with and evolving legacy code. It's not taught anywhere and has to be learned. It's this lack of skills that CAUSES a lot of new shiny tech to come out, as it's more fun to write my own JS framework than try to work with other people to improve theirs.

<comment><USER18> I agree. I think the other dynamic that I've observed in these situations is that the technologists who oppose the big rewrite often sound like a wet blanket who are just opposed to the excitement. The old curmudgeons are just raining on the parade of excitement.

For some senior executives who are looking to generate passion and excitement the desire to endorse and support the big rewrite is just too much to resist.

</comment></comment><comment><USER19> I saw a link here on HN a short while ago (though I can't remember where exactly) to a Ribbon Farm post talking about Legibility, or the idea that people generally like things that can be understood and categorised.

[https://www.ribbonfarm.com/2010/07/26/a-big-little-idea- call...](https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called- legibility/)

It seems to capture the idea of The Grand Rewrite fairly well. From the post:

      - Look at a complex and confusing reality, such as the social dynamics of an old city
      - Fail to understand all the subtleties of how the complex reality works
      - Attribute that failure to the irrationality of what you are looking at, rather than your own limitations
      - Come up with an idealized blank-slate vision of what that reality ought to look like
      - Argue that the relative simplicity and platonic orderliness of the vision represents rationality
      - Use authoritarian power to impose that vision, by demolishing the old reality if necessary
      - Watch your rational Utopia fail horribly

There are often good technical reasons for a rewrite or major refactoring, but more than once in my career the urge was definitely based on the fact that if we rewrite it then we will know it inside out and we will only have what we need, nothing more. Full control and understanding.

</comment><comment><USER20> My feeling is that rewrites simply don't scale well.

To make them work you need resources, good planning and motivation from everyone involved. As the number of people increase the probability that any of them made a mistake estimating how long it will take or how well their part will run explodes. That's why refactor tends to work better, rewrite with a scope.

I worked at a company were we build small embedded devices (EM dataloggers). I was supposed to take an existing code base shared by several products and modify it to build a new one. The code was beyond ugly. As an example:

       delay_ms(5)

Would yield a 5 milliseconds delay, as long as you weren't in a variety of modes, the GPRS connection wasn't hang up, and GPS had a lock. It was painful to think about it, let alone work with it.

I convinced everyone that a total rewrite was necessary, and then I let everyone keep working on the _old_ code base while I worked on the new one to add the basic functionalities. Then we started to move product by product, adding the "extras" each device required. Now the new products are built with that skeleton, and refactors are way less scary and faster, and can be made across devices easily (one of the improvements is that "business" logic has automated testing now).

To this day I'm convinced that the only reason that could be made is because we started with the new product, and then moved upwards. Trying to build a new ecosystem for all of them would have failed hard.

<comment><USER21> > rewrites simply don't scale well.

I learned early on that rewriting a codebase is a lose-lose proposition: I'll never suggest or recommend it again. Not because I don't think it's ever a good idea, but because it can only go wrong. If everything happens perfectly without a single hiccup or surprise, you're still right back "where you started from" from the perspective of management. I worked on a massive rewrite porting a C++-based codebase to Java. The rewrite was actually suggested by "the business" because they were having trouble finding C++ developers and they noticed that Java developers were easier to come by. I was actually hired because I had a strong background in both, so I jumped right tin. I was too young and too naive to realize how backstabbing, conniving, and treacherous business people can be: I actually ended up being blamed for every surprise that came up during the rewrite process.

</comment></comment><comment><USER22> Another aspect I didn't see mentioned was that, at least in my experience, one can put too much effort into solving a problem. Then one ends up with a nice bespoke solution, but once it's been used for a bit, the requirements change and the solution might end up being a poor fit.

Very often in my experience this is because the client doesn't have a perfect handle on what exactly it is they want, which is only natural when venturing into the unknown. So they end up spec'ing a solution that doesn't exactly match the ideal work flow.

These days at work, when the client wants some new custom feature, we try to figure out if we can get something good enough by making small adjustments to existing features.

Then, when the inevitable changes come, we're in a much better position to determine the true requirements if we decide to go for a bespoke solution.

This does however require that the code is malleable, so I write with that in mind.

</comment><comment><USER14> He kind of touched on it, but he really didn't go into one reason to rewrite code is if it is based on old legacy technology that won't be supported in the future.

If your website was Flash heavy, you had to rewrite it for it to work on mobile.

I mentioned another post where I was responsible for rewriting a legacy 20 year old PowerBuilder app that depended on sql server 2003. The first step I took was to upgrade it to a "newer" version of PowerBuilder that supported COM, put a C# REST API on top of it, and then create Postman/Newman integration tests.

After that, we slowly started moving the code from PB to C#.

Honestly though because everyone has their own self interest at heart, sometimes you have to rewrite or transition to newer tech to keep existing employees and/or to get new employees.

I was at a job where the department grew from 4 to 15 developers in a year. The product was a B2B product where we had 90%+ of the sellers market using a PHP web app with complicated business logic. We didn't have a product for the buyers market.

We were going to put COM on top of the (well written) PHP rules engine and share it with a new product for the buyers written in C#.

The buyers product written in C# didn't find a market, but we were getting interest in expanding the PHP product. Every single developer left within 6 months because no one wanted to spend the next year doing PHP. We all knew that PHP wasn't marketable at the compensation rates we were looking for. The only reason it took six months for them to leave is because some were waiting for their 3 year vest.

</comment><comment><USER23> Probably the best section is right here:

> However, refactoring can be a better tool before you begin making any > changes as a way to make your change easier. As Kent Beck said "Make the > change easy (warning: this may be hard), then make the easy change."

<comment><USER24> Combine that with "Red, Green, Refactor" (write failing tests, fix code refactor) and we have another pair for the list of mutually contradicting proverbs.

<comment><USER25> They're different development phases. If you've got a green test suite, you can just "Refactor, Green, Refactor, Green".

</comment></comment></comment><comment><USER26> > _Just like in Joel 's post, where Netscape took years to rewrite its already > working code, rewriting code because Coldfusion was "dead" or "inferior" > would have served little business purpose._

 _I understand there are plenty of counter-arguments to be made here. First and foremost, it gets harder every day to find a Coldfusion developer. Those who know the platform are most likely looking to give a facelift to their skillset, rather than prolonging the inevitable drying-up of the proverbial job pool. More, it may be harder to implement functionality in Coldfusion, particularly the kind we were dealing with, than, say, in .Net, Ruby on Rails, or even Go.

Even so, there are other, better ways to move toward new technology without rewriting an entire codebase._

Interesting that the author doesn't provide any real suggestions to this specific case, only the other examples, which are not similar.

The facts are the following:

1\. The Coldfusion community is dying.

2\. Adobe is actively making it more difficult to commercially pay for the software. They are now seeking compensation for use of CF as part of "SaaS Revenue". You have to submit a form that says what your revenues are. I kid you not, thats what the sales people are saying to customers.

These two situations have serious economical ramifications on a company running CF.

<comment><USER27> When the answer to "what is your pricing?" is "well... how much can you pay?" the vendor gets kicked out on their tuchus in our shop.

<comment><USER24> How much do you charge your customers?

<comment><USER28> Well, I work in a government so...

But anyway, the problem of that behavior is not really the pricing, it's all the rest that comes bundled with that attitude.

</comment></comment></comment></comment><comment><USER17> Rewrites are a symptom of orgs that focus only on feature velocity, and not other forms of customer value.

If in addition to getting features done, teams were held more accountable for uptime, performance, and stability, there would be appropriate focus on careful redesign, but only in proportion to some customer end-value after that is delivered.

A rewrite for the sake of a rewrite, because X doesn't conform to software engineering technobabble is a huge red flag. These things exist to support customer value, and are not ends in-and-of-themselves.

In short, there shouldn't be a difference between new feature delivery and refactoring to support some other customer need (like uptime or performance). It's all work that needs to get put into a backlog, prioritized, and delivered with clear success outcomes

</comment><comment><USER29> Don't fall into the trap of "never do X" prescriptions written in blog posts. Rewriting an application or library from the ground up is often a joyful experience packed with an immense amount of lessons to learn. Similarly, refactoring an existing application and watching it come back to life can also be a joyful experience packed with an immense amount of lessons to learn. Whether or not you know what you're getting into on either side, you'll learn soon enough, and experiencing both approaches many times over is part of what being a programmer is about.

<comment><USER4> If you are just developing for your own enjoyment, sure, you can rewrite for the learning experience or for fun.

<comment><USER29> if you are clever enough, you can get your employer to go with either approach you choose and you can learn while getting paid.

</comment></comment></comment><comment><USER30> > _If your reason for rewriting the code is that you don 't understand it, you > should not rewrite it._

This is a fundamental thing that most people miss.

If you don't understand the code/system/structure/process/law, you can't possibly rewrite it in a way that is a) effective and b) addresses the use cases it was designed to address.

If you try to rewrite something you don't understand, everything after that decision is re-discovering the same old pains, lessons, and practices that the first person discovered.

</comment><comment><USER31> This notion of code being "done" is the root problem. This idea that you write something and ship it and that's over is wrong. Code is never done, it is almost biological in its emerging complexities. The current code is the running manifestation of everyone's understanding, of the architecture : it will and must change.

Viewed through that lens you can see;

* estimation is hard, as you are never _really_ done.

* software has a very high maintenance cost, plan for it.

* architecture and design are important, longer term : spending more money on things with longer value life just makes sense.

* Interfaces are important and allow for rewrites on a smaller scale.

* you will always be releasing: focus on CI and devops to take the grind out of that.

Rewriting is a form of refactoring I guess: It's like chopping a leg off or something. One thing I like about microservices (or rather, strict boundaries) is that you can rewrite the worst part but keep the rest going.

Yeah and oh man I hate the "this code sucks" culture :(

</comment><comment><USER32> The most important thing for developers is will they have the skills to get the next job or will they be working on technology that no one wants in a few years time. If FANG companies are hiring people with SPA, JS, Python experience it makes perfect sense to get rid of any technology no matter how well it is working.

<comment><USER33> Those are the same companies that 5 years down the line discover why all big corporations bet on .NET and Java when performance matters.

<comment><USER34> "Nobody ever got fired for buying IBM", or so the industry said for decades.

But IBM wasn't (always) the best, they were just safe bets. Until the world started changing and they weren't.

.Net and Java have always been good enough. Even today they're good enough for many, many problems.

I probably would not reach for .Net and Java if performance literally mattered.

<comment><USER28> > I probably would not reach for .Net and Java if performance literally > mattered.

There are many tiers for performance mattering. It is quite possible, and common, for Python to be too slow while .Net is fast enough.

</comment></comment></comment></comment><comment><USER35> The biggest trap is new and shiny. Let me explain, they decided in the company to do a complet rewrite while we only needed a few apis connecting to the existing software. Its a group of 8 people. The current software is written in PhP, jQuery, Mysql and some use of Yii. Blazing fast, customers are happy. New guys come and of course we need a rewrite. Everything has to be microservices. Now they have to work in Kubernets, Docker, React, Node, elastic search, MongoDb. With each of these is nothing wrong, but its a lot of new technology to pickup with 8 people. Now the clients hear when they want a change or modification, no just wait till we have platform 2.0. Long story short, development has gone downhill, customers unhappy and after 6 months they are already 12 months behind schedule. This company will byte the dust within a year.

<comment><USER8> A lot of rewrites end up trading one set of problems with similarly sized set of different problems.

But to be honest the rewrite was probably a positive for the devs. They have more cool stuff on their resume and will do better in the market. That's one of the big problems with finding jobs. If you do what's good for the company you may quickly end up with an outdated resume and be marked as dinosaur who hasn't been keeping up. Even your own company will hire new people for new sexy projects instead of the people who did what was good for business.

</comment></comment><comment><USER36> 10% necessary to fix the code itself

20% necessary to get into a better ecosystem (especially for hiring)

30% NIH

40% know it's bad but padding review/resume

</comment><comment> mark-r > _If your reason for rewriting the code is that you don 't understand it, you > should not rewrite it._

Which is just another example of Chesterton's Fence: [https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...](https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence)

I once lived through a complete application rewrite. The rewrite was necessary to add a new feature that didn't fit into the existing code organization. We were able to reuse large parts of the old code, but it still took twice as long as estimated. And the result was the most bug-ridden version of the app ever. But ultimately it was successful, and the new feature was much loved.

<comment><USER37> And again: _it depends_. I was involved in at least one rewrite where large sections of the original code were incomprehensible, and rewriting the whole thing from scratch proved a massive success.

</comment></comment><comment><USER38> I would ask a meta-question: why did the author fall into the trap of writing about the rewrite trap? While much of what the article says is true, it talks about a phenomenon that exists mostly in the funhouse mirror of HN and Reddit. People don't actually rewrite so much; in fact, they probably do it less than they should. Yes, there is a "contempt culture" but it almost always comes from the losing side. E.g. Go is not very popular outside the US, but it's _hugely_ popular in America; how popular is it in the US for _active_ development? 33x _less_ than Java [1]. That's still very respectable, but let's not get carried away. Moreover, HN and Reddit are not only terrible at describing the current state of the industry, they're also terrible at predicting trends. While a few of the ideas/language/techniques hyped on such forums do end up successful, the vast majority end up failing. Some of them continue to be hyped on those forums even long after they've failed.

Why do Reddit and HN paint such a distorted image? I have a couple of guesses. For one, by their very nature, they focus on new and unusual things, which is what they're supposed to. This means that by their nature they focus on things people _don 't_ actually do. For another, these forums can, at best, represent the content that's actually produced online, and here there is a big bias towards smaller companies -- perhaps because such content is an efficient form of marketing for them -- as well as towards places and industries where producing blog posts featured on HN is a part of the culture, namely startups and SV companies. Even there we see that an SV company like Google, that employs 2000 times as many employees as a startup, does not produce 2000 times the number of technical blog posts. When the content is so skewed towards small organizations, it gives disproportionate representation to the practices of small companies working on small codebases. When those companies grow, they tend to shift their practices and technologies to more established ones that are not as new and not as unusual, and also produce fewer technical blog posts. Similarly, younger, less experienced developers have more time and incentive to publish posts, and so are overrepresented, but as they mature the often realize, like their predecessors, the mistake of their ways, but also produce less online content. The result is that HN and Reddit mostly talk about things that _aren 't_ usually done, and overrepresent smaller problems and practices that come from inexperience. That makes them fun to read, but readers shouldn't forget that the genre they're reading is more that of GQ/Vogue than, say, the New York Times.

[1]: [https://www.hiringlab.org/2019/11/19/todays-top-tech- skills/](https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/)

</comment><comment><USER39> A programmer never starts from scratch. Every new line of code typed brings with it the legacy of past struggles and new understanding;

</comment><comment><USER40> I agree. Mostly you need refactoring to account for the changes in requirements over time. We don't spend enough time focusing on encapsulation and modularization.

People want to rewrite because it is green field and they can do it how they want. As you said, this doesn't really add value to the company.

</comment><comment><USER41> Quick question, since we are on the topic: do you think that it is a feasible (or even the optimal) approach to first develop an MVP, using a very productive, but much less performant, language (Python) and then, upon reaching a product-market fit, if needed [i.e., after trying to remove performance bottlenecks and using a faster compiler, like PyPy], rewrite the product (SaaS platform) in a more performant and otherwise more suitable language (e.g., Julia, C#)?

P.S. By "rewrite the product" I meant rewriting only the backend.

</comment><comment><USER42> Depending on the size of the refactor, the lines between it and "rewrite" start to blur, so I'm just going to consider what I'm doing right now at my job a big refactor of how the data is stored and read, even if it involves making some big changes to the database models and how they are interacted with.

Really, it's pretty much a rewrite of the database handling code but hey, that won't impact how the data is sent through the endpoints so the interface didn't change. Refactor!

</comment><comment><USER43> What if the rewrite was intended to be competing product rather than a replacement for the existing one?

So many rewrites die as they attempts to reach parity and acceptance from users of the legacy version.

When a startup comes along and "disrupts" a product with their fancy new tech, they have basically done a rewrite without caring about the state of the legacy product. And then the incumbent often acquires them for a lot of money.

So, why not just do that whole process in-house?

</comment><comment><USER44> The company where I'm working is doing a full rewrite of one of its product from a single-tenant, installed on-premise to a multi-tenant solution in the cloud. Except that the previous version is still worked on (new features & fixs), with perhaps less people than a few years ago. And the new version is developed by new teams set up for this project and the targeted market seems a little different.

Well we'll see in a few years how it ends.

</comment><comment><USER45> > Coldfusion (you've probably never heard of it),

I still use it.

</comment><comment><USER46> > One of my favorite reads is Joel Spolsky's Things You Should Never Do. He > wrote this post almost twenty years ago, outlining the downfall of Netscape > and others because they spent years rewriting working code.

I've read that piece long ago, and over time my cynicism has ripened. Should I be surprised that the opinion of a former Microsoft employee is that Netscape's downfall was their own fault?

</comment><comment><USER47> My policy on rewrites is that you must already fundamentally understand not only the code but also the business that the code covers. If the developer responsible for the rewrite satisfies this constraint, I have a much greater deal of confidence in the success of the effort.

Also, any rewrite should be done in contrasting terms of: Value to the end customer VS long-term technical value. Many rewrites remove value from both ends of the scale. Some may improve both. I think as long as you keep this equation balanced you will be ok. Many developers have ulterior motivations which can greatly compromise this equation if not carefully accounted for (e.g. chasing shiny things, resume padding, etc).

I would say that in purely technology terms, rewrites are amazing. My approach to writing a new system usually involves writing it 2 times at a minimum. The first pass is the fastest, hacky way I can get to MVP with a major focus on the most difficult technical aspects of the product. This pass is what I put in front of our internal developers to get some input so that I can quickly correct course if needed. During this time, I allow myself to make sloppy mistakes in favor of proving that a certain feature can (theoretically) work. This seems to do wonders for productivity because you are much more likely to experiment and find better paths when you aren't worried about your extremely pedantic code policies (of which we have many).

The 2nd pass (aka the rewrite) is when I have the first pass project up on the left hand side of my monitor, and a new solution on the right hand side. I use my original implementation as a reference, but now view it through the lens of auditing another developer's code for quality and policy. Having already proven that the hard thing can be done, my mind is now free to focus on the correctness and standards applied throughout. This is the code that I would actually put in front of our customers. From this point onward, unless a major shift in framework, architecture or language is decided, all future iterations are done on top of this 2nd pass codebase.

I would also say that just because you decide to do the rewrite doesn't mean you have to throw away the old code and any support for it. The most successful rewrites I've ever seen occur where the legacy system is ran in parallel with the new system with both being maintained and used in production simultaneously. Obviously this has some overhead, but it also ensures you have a stable fallback option with clear A/B comparison capabilities throughout the migration phase.

</comment><comment><USER33> Usually the way I turn down junior ideas about rewriting the whole deal is making them think about the monetary costs of a rewrite, and to show what is the benefit for the end customer from an cost / analysis report.

Rewriting stuff is cool when one isn't paying the work hours expended in them.

<comment><USER48> it's called investing in your product. if a rewrite will cost x amount in dollars and man hours upfront, BUT will save much more over the lifetime of the product in support and pain for both you and your customer, then it is ALWAYS worth it.

<comment><USER33> If that is proven for the use case in question, by all means.

If not, then there are better places where to spend money.

</comment></comment></comment><comment><USER49> Because we did it wrong the first time.

<comment><USER50> but it'll be so much better the second time!! [https://news.ycombinator.com/item?id=22104506](https://news.ycombinator.com/item?id=22104506)

</comment></comment><comment><USER51> The only times I had to rewrite the software was the time when initial documentation, didn't match what was actually delivered/expected from the client. Sometimes it's very hard to plan architecture when the whole concept change.

</comment><comment><USER37> While you should be careful about rewrites, Joel is not correct that a rewrite is always a bad idea. I've been (reluctantly!) involved in a bunch of rewrites in my career and they were invariably highly successful.

So, as always:

1\. it depends, and

2\. please use your best judgement.

</comment><comment><USER52> Parable: Company wants to move "into the cloud" and adopts AWS managed services or Kubernetes to recreate and re-platform existing and functional, though sketchy, on-prem services. "Agile coaches" and "Solution Architects" advise rewriting the old code because of its fundamental alien-ness in a cloud-only environment. So it's a rewrite. But of course, the re-write doesn't work, primarily because of fundamental misunderstandings about what properties allow software to scale across many machines, in many time zones, running processes 1000's of times per day. So it becomes necessary to either cut losses and re-write the re-write or decide to start iterating now on the crappy re-write to make it closer in terms of functionality to what already existed in the crappy on-prem systems - which begs the question of why you didn't just iterate on the original sketchy code in the first place.

There are times when rewriting does make sense - rare though they may be. I've only seen a few, and they always had to do with improving stability and reducing the potential for bugs. None of them required you to use the latest shiny to "completely reimagine what software could be doing for your business". I've helped to rewrite subscription-management systems that ended up noticeably reducing churn and cutting out spurious chargebacks from customers who couldn't navigate our bug-prone subscription service wasteland. But some refactors are so labor intensive that they amount to re-writes, even if you're using the same tools and languages. Some code is acutely awful and it needs to die for people to be able to go to sleep at night without having to drink a fifth of whiskey beforehand. Some atrocities don't need to exist.

But, again, if the reason for a refactor or rewrite is summed up as "we're bored and want to play with these new shinies" then you are in for it. If rewriting provides you with some sort of new business capability or fundamentally changes a business process drastically for the better, then go ahead. But in my experience, if a technology or paradigm is fundamentally "so much better than what we do now", then it should work so well with what we do now so well that it doesn't require fundamental rewrites of large software systems. So rewriting things in Python or C++ is great, or using Kubernetes instead of Lambdas or whatever is fine, but it's more important that these paradigm shifts can be incremental rather than a complete recreation of what already exists, that the gulf between refactoring and rewriting can be relatively small instead of two completely different processes.

</comment><comment><USER53> Does anyone know the error handling pattern the author mentions?

</comment><comment><USER54> Something I've noticed over the years is that the people who say that reading code is harder than writing code are people who have been writing code for a long time and are paid to write code.

I think the truth is that it's actually a different skill, and one that's much harder to pickup because when you write code, there's a very quick feedback loop telling you that you're wrong, but you can read code, think it does something different than it does and never ever learn you were wrong.

<comment><USER8> I think reading code is very good for one's character. It teaches compassion and openness to other people's ideas. Pretty much like listening without prejudice. I am very guilty of not being interested in what other people did so now I am making a point to really trying to understand code before criticizing. It's so much easier to throw a fit and think everybody else is stupid.

</comment></comment><comment><USER55> What if it's written in ASP classic and powered by deprecated SQL procedures that won't run on anything newer than SQL Server 2005?

</comment><comment><USER56> People not wanting to write Cold Fusion isn't "contempt culture", it's an objectively terrible platform.

</comment><comment><USER57> But isn't Firefox Quantum a result of a successful rewrite of Firefox Gecko?

<comment><USER58> Firefox Quantum isn't a rewrite of Gecko. At one point, Servo was going to be a rewrite of Gecko, but that petered out. They pivoted to a strategy where some parts of Servo would be integrated into Gecko, and other components of Gecko would be rewritten in Rust. The most significant of these was Stylo, Servo's CSS style (but not rendering) subsystem. However, despite the rebranding, the core of the engine and the overall architecture is still Gecko.

</comment></comment><comment><USER59> do we have a model for differential structure migration back to formal specs ?

</comment><comment><USER60> This came up a few weeks ago regarding crypto.

There's a distinct difference between rewriting code WITH a regression suite, and rewriting code WITHOUT a regression suite.

The difference is enormous.

I come from a hardware background where the # of employees looks like this:

lead architects = N employees microarchitects = 10 * N employees circuit designers = 10 * 10 * N employees validation = 10 * 10 * 10 * N employees

It is rough, but true: 10 lead architects can equal 10's of thousands of validation engineers

There's a reason why it is so upside-down: bugs cost a lot more in the hardware world than in software because they are much harder to fix in the wild.

The answer to the question, "Should we rewrite?" is always "maybe", and then requires risk exposure analysis and a robust mitigation plan. You need regression testing and a bug tracking system from day one, but you also need a rollout plan and a response team.

It is not an easy decision for established software. Or rather, it shouldn't be! :)

</comment><comment><USER61> Sometimes there's no option, because enterprise policy mandates that you have to port that uncommented, spaghetti code, dependent on archaic Win32 calls, written by amateurs VB6 image processing application to something modern like .NET. BTW if anyone needs that skillset I'm open to offers!

</comment><comment><USER62> I feel if you need to rewrite something you're already in the trap. Rewriting is climbing out, not rewriting is digging deeper.

The problem with rewriting though is sometimes it's another trap, but anytime you feel the need to rewrite... you are already in a trap.

</comment><comment><USER63> Obligatory comment I have to repost every time rewrites come up: [https://news.ycombinator.com/item?id=11554288](https://news.ycombinator.com/item?id=11554288)</comment>


Ask HN: What software exists for playbooks/runbooks? - <AUTHOR> A playbook/runbook meaning an editable guide or set of strategies to solving problems a company/individual encounters throughout their existence.<p>Are people just using wikis or google docs? <comment><USER2> We just use the company wiki. We are thinking of moving that data to the service GitHub repo instead to keep the data more local. It is easy to forget to update documentation all ready, might as well reduce the places you have to update.

Ideally all alerts are either self-evident or link to proper remediation steps to attempt when auto-remediation is not available. The new person on the team should have enough info to do basic triage at 3am at the very least given a decent runbook/alert documentation.

</comment><comment><USER3> Run-books are an anti-pattern designed to resolve issues that shouldn't be present in well written software.

<comment><USER4> So throw away the disaster recover plan and blame the vendors if anything goes wrong? Got it.

<comment><USER5> In case of fire, blame vendor.

</comment></comment></comment><comment><USER6> We just use markdown on github</comment>


Here's How the Sound Blaster Changed Computing - <AUTHOR> http://tedium.co/2016/02/09/creative-sound-blaster-sound-card-history/ <comment><USER2> Funny, the keyboards video was mentioned here a while back [https://www.youtube.com/watch?v=QLJSdNYcdpk](https://www.youtube.com/watch?v=QLJSdNYcdpk)

btw: who else enjoy long synth chord progressions like in here [https://www.youtube.com/watch?v=TN4La6qmSnk](https://www.youtube.com/watch?v=TN4La6qmSnk) ?

</comment><comment><USER3> I had an IBM PC Jr. I don't remember much of it except that it used a cartridge for DOS.

I will never forgive Creative for buying then decimating Henry Kloss' Cambridge SoundWorks. I so wanted a Model 12.</comment>


How to Create an Innovative Culture: The Extraordinary Case of SRI - <AUTHOR> http://www.forbes.com/sites/stevedenning/2015/11/30/how-to-create-an-innovative-culture-the-extraordinary-case-of-sri/ <comment><USER2> As a sometimes-student of such things, I noticed that their home-brewed, four part recipe for a good value proposition is basically Real-Win-Worth It in slightly different form.

I'm not criticizing: it can be a worthwhile endeavor re-invent the wheel a bit to find out what works for your organization and your markets. I see it as further evidence that the framework has utility.

(apologies for the corporate-speak.)

<comment><USER3> It looks like the Real-Win-Worth It paper [1] is from 2007? What is the history of this method? The OPs book [2] was released in 2006, similar timing.

[1]: [http://www.ncbi.nlm.nih.gov/pubmed/18283921](http://www.ncbi.nlm.nih.gov/pubmed/18283921)

[2]: [http://www.amazon.com/Innovation-Five-Disciplines- Creating-C...](http://www.amazon.com/Innovation-Five-Disciplines-Creating- Customers/dp/0307336697)

<comment><USER2> from the text of your [1]:

The second, the R-W-W ("real, win, worth it") screen, sometimes known as the Schrello screen, can be used to evaluate individual projects. Versions of the screen have been circulating since the 1980s, and since then a growing roster of companies, including General Electric, Honeywell, Novartis, Millipore, and 3M, have used them to assess busi- ness potential and risk exposure in their innovation portfolios; 3M has used R-W-W for more than 1,500 projects.

(I've never tried to dig any deeper than seeing mentions that Don Schrello seems to have put it together sometime in the 1960s/1970s as part of his marketing company.)

</comment></comment></comment><comment><USER4> For a partial and anonymized story about the initial decline of SRI, read _The Network Revolution – confessions of a computer scientist_ (1982) by Jacques Vallée. Reportedly, they all became entranced with Erhard Seminars Training.

</comment><comment><USER5> I thought SRI was classified war related research spun off from Stanford during the anti-war years. At one time the S stood for Stanford. Stanford didnt completely divest all its war miltary research because the computer science department still accepted DARPA money. I remember Professor Terry Winograd feeling conflicted about that. Terry,s compromise was that all their results would openly published for both military and civilian applications.

</comment><comment><USER6> I thought SRI was mostly driven by being a psuedo CIA (and the IC in general) research division -- which provides a steady funding stream. Were they really close to bankruptcy in 1998? The article doesn't go into many details of that.

</comment><comment><USER5> The computer mouse and the graphic user interface was invented at the young SRI by Englebart. He didnt commercialize it. But Xerox a few miles away, fleshed it out.

</comment><comment><USER7> I worked with them at more-or-less arm's length from 1997 - 2002. Truly a magical time while it lasted.</comment>


Rails 3.0: It's ready - <AUTHOR> http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done <comment><USER2> Not to cry sour grapes here but there is not one mention of Merb in that entire blog post. I personally wrote merb in order to show that rails internals could be much better, modular and faster. I did heavy duty politicking to get the two teams to come together and I think the rails merb merger is one of the coolest open source success stories vie heard of.

But not a single mention of merb in this entire post. I'm not complaining but it seems disingenuous not to mention it as the sole reason I wrote merb was to push rails forward. And when it looked like merb might possibly overtake rails I went ahead and gave merb to the rails project and got the two teams together so there wasn't wasted effort. After all to have ruby and rails itself win we needed to compete with java and python and php. Merb was starting to fragment the ruby community as it became a more and more viable option and I did some personal heavy politicking to get it merged back into rails so we could take on the world instead of infighting within the ruby community.

I think it's been a great success story and most of the ideas of merb's architecture have made it into rails.

So I'm incredibly happy to see rails 3 finally come out. And I'm incredibly happy that my little experiment in making rails architecture better has paid off and the two projects merged. But I do think it's a bit weak that merb was not mentioned once in the article.

(Edit) all this being said I don't want to come across as co plaining. My work on merb ended up exactly as I wanted it to, it made rails better.

So huge congratulations to the rails team for making this happen!

(Edit) <http://rubyonrails.org/merb>

<comment><USER3> "Merb was starting to fragment the ruby community as it became a more and more viable option and I did some personal heavy politicking to get it merged back into rails so we could take on the world instead of infighting within the ruby community."

Interesting, if disheartening, perspective.

I much prefer to see greater diversity within a language. I want to see more frameworks, more exploration, more choice. What some may call fragmentation is in fact rich and vibrant and valuable.

And the idea that there is some sort of battle going on among languages, that Ruby needs to "win" against Java or PHP or any language, is truly perverse.

I fear this battle mentality is by no means a minority opinion among Rubyists.

I prefer to use Ramaze for Web development, but I'm glad people can pick Camping or Wave or Wuby or IOWA or Sinatra or any of the dozen other options out there. There are interesting things being done, and not simply so they can be subsumed by some One True Framework.

I was disappointed not to see Nitro get the attention it deserved, to have Chad Fowler tell a conference audience that people working on Nitro should just _stop_ , because "Rails won", was a turning point in how I viewed the larger Ruby culture.

There are many smart, adventurous people doing interesting things with Ruby, but there is also a pervasive cliquishness and neophobia regarding anything that is not somehow tied to Rails.

It's great to see progress made in Rails, but the solidification of Ruby === Rails leaves a bad taste.

<comment><USER4> It needs to at least compete with Java/PHP ect. In order to create a big enough ecosystem to provide all the libraries and core features needed and keep them up to date. As well as have enough people explaining things that new people don't feel overly intimidated.

<comment><USER5> "It needs to at least compete with Java/PHP ect."

Why?

And you know what? It never will. Rubyists need to give this up. It's a pipe- dream. Microsoft can set up large/local conferences, charge $75, and make a sales pitch. Dozens of vendors lined up to hand out schwag and pitch their product.

For management, they don't get the _best_ tool, but if it meets requirements, then it's a no-brainer because the most expensive component license is (usually) cheaper than the dev time to meet the basic requirements in-house (those are usually a small subset of what the component might do).

The bigger issue is that that sort of buy vs build scenario manages risk very well.

Ruby has a lot of strengths, but providing a strong story for managing risk isn't one of them. Especially if you don't bill by the hour.

The world of software development isn't winner take all. The same things that can make Ruby and Rubyists great are some of the same reasons it likely won't ever be a good fit for some of the mass-market issues Java and .NET are a good fit for.

That's OK in my book. I die a little on the inside every time someone tries to sound smart by saying "use the best tool for the job" when often there are clear and obvious winners and losers in software. But in this case... Use the best tool for the job. Or maybe just the tool you like most. If Ruby works for you and your company, you're already doing the risk management thing very well. No reason _not_ to use it.

</comment></comment></comment></comment><comment><USER6> Not a single mention of Merb in the entire blog post.

<comment><USER7> A comment from DHH in the comments of the post:

it long since stopped being about a Rails and a Merb team. Today there's just a Rails 3 team where everyone is working together for the improvement of the framework.

See [http://contributors.rubyonrails.org/contributors?window=this...](http://contributors.rubyonrails.org/contributors?window=this- year) for work done this year. More than 350 people who has commits this year. No factions, just collaboration.

</comment></comment><comment><USER8> Does AR really work like this?

        users = User.where(:name => "david").limit(20)
        users.where("age > 29")

        # SELECT * FROM users
        # WHERE name = "david" AND age > 29
        # ORDER BY name
        # LIMIT 20

It seems a bit counter-intuitive to me. I'd expect that

        User.where(:name => "david").limit(20).where("age > 29")
        =/=
        User.where(:name => "david").where("age > 29").limit(20)

Yeah - just nitpicking, but it caught my attention.

<comment><USER7> It may seem counter intuitive at first but here's the thing to understand:

> users = User.where(:name => "david").limit(20)

Does not actually do any calls or create any kind of sql by itself. When you follow it up by

> users.where("age > 29")

all you're telling the users object is that you want to add a condition to your next query. You are not telling it to refine the previous query.

To get what you want, you'd need to do:

> users = User.where(:name => "david").limit(20).all

> users.where("age > 29")

<comment><USER9> Well, you could do it the django way, where you can't filter a queryset after a slice has been taken (eg. limit has been used)

This is ten times more logical if you ask me.

<comment><USER10> It's very convenient to be able to pass a partially built query, including a limit, into a function which adds more conditions. Why would you not want to be able to do that?

<comment><USER9> Because the meaning of it is totally counter intuitive, for one ?

</comment></comment></comment></comment></comment><comment><USER11> > _Say goodbye to encoding issues_

And good riddance! Utterly _thrilled_ to hear this.

<comment><USER12> Bold words. I can guarantee that encoding issues will prevail. They may be of another sort, but they will never go away magically.

<comment><USER11> Certainly. But you _can_ remove the ones you create (to reach "zero"), and patch some of the ones you don't (to reach... "-zero"?).

</comment></comment></comment><comment><USER13> We've designated a release charity for people to show their appreciation of Rails 3. If you're going to use it, please help us bring clean water to 5,000 people with Charity:Water.

You can donate on <http://mycharitywater.org/rails3>

</comment><comment><USER14>
        Status: 500 Internal Server Error

Maybe not quite yet?

<comment><USER13> Fixed the issue. The weblog is a prime example of cobbler's shoes. I think it's running Rails 0.5 on a machine that hasn't been updated in 6 years.

<comment><USER15> Speaking of, you might want to get rid of the mephistoblog.com link since it is no longer valid.

<comment><USER13> I want to nuke that entire installation from orbit. It's the only way to be sure that it's gone.

<comment><AUTHOR> I mean, it should only take 15 minutes to build a new one, right? ;)

<comment><USER16> And at least one "WHOOPS!"

</comment></comment></comment></comment></comment></comment><comment><USER17> For anyone using Rails 3 with haml, upgrade haml to 3.0.18...

      bundle update haml

I lost a few hours looking for the issue where form_for was silently failing.

Great support though. Here is a discussion of the issue and resolution.

<https://rails.lighthouseapp.com/projects/8994/tickets/5493>

</comment><comment><AUTHOR> It's 500-ing, so here's a pastie of the text: <http://pastie.org/1125097>

</comment><comment><USER18> I just realized this going through the API docs when I noticed the docs for 3.0.0 were now live on api.rubyonrails.org. Finally! (Of course, just two hours after converting one app from rc1 to rc2.)

</comment><comment><USER19> die, J2EE, DIE! ^_^

</comment><comment><USER20> Congratulations!

</comment><comment><USER7> Awesomeness!!

</comment><comment><USER21> Instead of making things more simple they have made a lot of things more complex and "configureable". I think Rails 3 is a great example of over-design and over-engineering. I don't really think web-frameworks need to be this complex.

If people want to control their own stack with minimal code and complexity they should check out Python's WSGI interface and the tools that are built around it. You can in an afternoon tie your own framework using tools like werkzeug, mako and sqlalchemy. You can be the master without following other people's lame conventions.

<comment><USER22> I'm about to learn Rails 3, please, which parts of it you think are complex, over-designed and over-engineered?

<comment><USER23> I'm using rails 3. OP is full of crap. Rails is a full stack framework complete with ponies, unicorns, and rainbows. Asking it to be minimal is a joke, but you can get rails pretty slimmed down if you work at it. You wouldn't want to build a full app on ActionController::Metal but you can.

The redesign has made the internal code of rails much simplier and ActiveModel is simply brilliant. I'm using CouchRestModel and having ActiveModel means I can use plugins like Formtastic right out of the box.

Rails 3 decoupled the major components. It's more modular now. I can disable ActiveRecord without the plugins I'm using getting upset that it's missing. If anything, this makes the framework less complex because you don't have to worry about interplay between the components.</comment></comment></comment>


HTTPS isn't always as secure as it seems - <AUTHOR> https://www.wired.com/story/https-isnt-always-as-secure-as-it-seems/ <comment><USER2> I read the complete article. I read the page of the researchers that is linked. I know how this stuff works.

I still have no idea what they have found. Far too little info to estimate how relevant this is.

<comment><USER3> > Full paper will be presented at the 40th IEEE Symposium on Security and > Privacy on May 20-22, 2019 at San Francisco (CA).

Until then, there's not really much to see here.

<comment><USER4> In that case let's wait until the actual results are published. On HN it's no problem to wait until a thing is actually available.

A pity if research findings now do PR teasers.

</comment></comment></comment><comment><USER5> Interesting. Sounds like browser maintainers need to detect the patch level of a server and adjust the padlock icon accordingly. I don't know if this is as simple as a version number check, or if sites would need to be probed for vulnerabilities. In the latter case, maybe a global shared registry needs to be created that can be queried by browsers and updated by web admins (not on the honor system, obviously; after updating their server they could just ask it to re-audit them).

Alternately, an HTTPS implementation that can silently update itself without admin permissions like browsers can. The web moves too fast for manual security patches.

<comment><USER6> A lot of the cipher vulnerabilities absolutely take a probe. In fact, multiple probes.

The client sends a list of acceptable cipher suites to the server. The server then selects one that is also agrees with (this can be based on many factors, strongest first, quickest first, a custom priority, etc). Because of this, if you send, say 40 ciphers, the server will only respond with one. To get an accurate list of cipher suites supported, you must send each one individually to truly test whether the server does support a particular cipher suite or not.

Not to mention, if a server is sending out its 'patch level' to a client machine on request, that in itself is a vulnerability.

The government does use such a tool - or at least something similar - [https://pulse.cio.gov/](https://pulse.cio.gov/) is just one example of a public repository of _some of_ those results.

<comment><USER7> How is sending a patch level a vulnerability? It only makes things easier to scan, not to exploit.

(And you shouldn't trust that data anyway.)

<comment><USER6> If every site responded, upon request, with their patch level, a database could easily be created.

Or a scan becomes that much easier to perform on 100,000 endpoints - and then your targeted attacks can begin on only vulnerable systems. 'Exploiters' waste a lot of time trying non-vulnerable systems.

The less information your server exposes to the outside, the better.

</comment></comment></comment></comment><comment><USER8> So, yeah -- this is a really hard problem: mapping technical characteristics such as TLS properties and domain name similarities to actual threats.

That's one of the reasons why, in my thesis (which I defend in... 1 week!), I propose replacing replacing security indicators with risk indicators [1]. I think technical properties of a web page, in conjunction with the context of specific interactions, can be used to determine whether the interactions might be risky. By informing users of risks they may be taking, they feel more confident making their own trust decisions.

(Meanwhile on the back-end: as a web server developer, I'm trying to find ways to make it easier to do upgrades when vulnerabilities in protocols are fixed, etc. It's also hard.)

[1]: [https://twitter.com/mholt6/status/1112748525413031936](https://twitter.com/mholt6/status/1112748525413031936)

</comment><comment><USER9> As far as I can tell, this article is content free.

</comment><comment><USER10> If there are ways to detect TLS vulnerabilities, it'd be nice to know that in the browser if that's not already possible. I would simply not visit sites that don't properly encrypt, and would even go as far as to block them.

</comment><comment><USER11> In other news, Wired obviously still thinks that breaking the browser's back button is a valid way to boost conversions.</comment>


Matchure: Serious Clojure Pattern Matching - <AUTHOR> http://spin.atomicobject.com/2010/04/25/matchure-serious-clojure-pattern-matching?utm_source=social-media&utm_medium=social-media&utm_campaign=social-media

<comment><USER2> Maybe I missed this from the article, but it would be really cool if someone would mash this pattern matching up in a macro with defn (maybe called "?defn" or something) so you could do stuff like the following without relying on apply:

        (defn qsort
          ([] '())
          ([Head & Tail] (let [lower (filter #(< % Head) Tail)
                               upper (filter #(>= % Head) Tail)]
                           (concat (apply qsort lower) (list Head) (apply qsort upper)))))

I have barely played around with Clojure though, so if there is a nicer way to express that code, please drop a comment and try not to tear me to pieces. My point is that I would love to have pattern matching available in function definitions similar to Haskell/Erlang.

<comment><USER3> You can handle your particular case with Clojure's fn argument destructuring. No need for pattern matching.

<comment><USER2> Thanks for the info, didn't know you could do that! What about the classic factorial, though?

      (defn factorial
        ([0] 1)
        ([x] (* x (factorial (- x 1)))))

<comment><USER3> That's an actual pattern match. Might as well use matchure ;)

      (use 'matchure)
      (defn-match factorial
        ([0] 1)
        ([?x] (* x (factorial (dec x)))))

</comment></comment></comment></comment><comment><USER4> Duplicate: <http://news.ycombinator.com/item?id=1293600>.</comment>


Ask HN: My app images are displayed for another app review. - <AUTHOR>

In less than two weeks I'm going on a cruise on Royal Caribbean's Oasis of the Seas. I thought it'd be fun to make a companion app for the iPhone so that's what I did. Yesterday I found a review of Royal Caribbean's iPhone app but it is showing screen shots from my app in the review. You can find it here: http://bit.ly/5h9nfZ I sent an email and posted a comment explaining the mix-up and asking for a correction post but haven't had a response and the comment is still pending review. I'm not too concerned about it, just want to set it straight. Any suggestions? <comment><USER2> Clickable link: <http://bit.ly/5h9nfZ></comment>


Are We Becoming a Part-Time Economy? - <AUTHOR> http://www.ritholtz.com/blog/2015/02/are-we-becoming-a-part-time-economy/

<comment><USER2> And it needs to be!</comment>


On the brink of bankruptcy, this startup's CFO got creative - <AUTHOR> https://www.techloaf.io/2019/05/16/burn-rate-win-employee-no-longer-needs-standing-desk-after-horrific-airboat-accident/ <comment><USER2> I follow this email every week and it is hysterical.

Airboats, feminist co-working apps, mad CFOs. Carl you've outdone yourself.

Now can I get some TechLoaf swag please???

</comment><comment><USER3> Such a refreshing break from the typical tech newsletters. Cracks me up every week

</comment><comment><USER4> This seems really unfair to Jacob.

</comment><comment><USER5> It's refreshing to see a company that doesn't just pay lip service to frugality.</comment>


Google right from your command line - <AUTHOR> https://github.com/mrowa44/ggl

<comment><USER2> This reminds me of Surfraw [http://surfraw.alioth.debian.org/](http://surfraw.alioth.debian.org/) by Julian Assange. Surfraw searches Google, Altavista, Babelfish, Dejanews, Freshmeat, Research Index, Slashdot and many others on the command line.</comment>


Why we need a space program - <AUTHOR> http://www.extremetech.com/extreme/89502-why-we-need-a-space-program

<comment><USER2> We have a space program. NASA isn't going away. It puts probes on/around planets and asteroids and advances science (but not SCIENCE! which is what people tend to get miffed about). If need be we could even start using our own rockets to get humans into space, it's just more cost effective to pay the Russians to do so.

Of course, throwing more money at NASA is actually a pretty good idea, even if the sexier things people want to do are unlikely to get off the ground in the near term (say 50 years or so). But a reusable shuttle was never cost effective for manned spaceflight at the scale that we did it at.

</comment><comment><USER3> I believe it was the National Research Council Canada's director who said this (I could be mistaken, correct if necessary):

"no amount of research into the oil lamp could have invented the light bulb"

<comment><USER4> I've never heard this before, but it is a good quote.

One of the problems that people don't understand about funding research for new science is that... it's new science. People don't always know exactly what will happen or come of it. It could be an expensive lesson on how not to do things, or it could be an exercise of the mundane, but even the spectacular failures can bring about paradigm shifting change.

More importantly, people come to believe that there is often only one goal of any mission and often dismiss the collateral benefits from attempting to solve a _really_ hard problem, especially because they are often hard to truly quantify.

</comment></comment><comment><USER5> I've been trying to find this quotation from Neil Degrasse Tyson but haven't been successful. It's one of my favorite perspectives on NASA's budget (and specifically the the importance of lavish, public, manned missions).

Paraphrased: Investing only $19 billion dollars a year is a no-brainer, considering the return is a generation of American kids interested in math and science.

<comment><USER6> >Investing only $19 billion dollars a year is a no-brainer, considering the return is a generation of American kids interested in math and science.

This attitude has brought NASA to the lack of relevance we see today. Astronauts spending hours on video chat with middle-schoolers and the use of precious payload to put ant colonies into orbit are not serious ways to advance a space program. When NASA was about exploring and colonizing the final frontier, kids would join in and dream along. When the space program became about forcing science and technology in an artificial way down the same kids' throats, they tuned out. So few youngsters with an interest in space / SF exist today.

<comment><USER7> Yeah, I think the goal of sparking science interest (and other things) would be better suited with mandated reruns of Star Trek: TNG in classrooms.

The thing with the ants is I only heard they were doing it, I never heard what they found out, and they never made it sound any fun. In _Surely You're Joking, Mr. Feynman!_ he talks about his own ant experiments in an enlightening way, with a useful application of getting them away from his food without using poisons. We need more of that.

</comment></comment></comment><comment><USER8> I don't doubt the value of a space program, but I seriously doubt having NASA be the steward of such a program from this point on. I cannot help but think what would have happened if the Air Force's program had been funded and advanced past the X-15 stage. The forcing of Air Force concerns on the shuttle and NASA's own obsession with winning a race to the moon instead of establishing a permanent presence in space have done in our space program.

At this point, I just hope that multiple avenues are tried and regulatory agencies are made to get out of the way of private flight.

</comment><comment><USER9> We need advancement towards spacefaring. We don't need space programs.

There is need for government basic research, infrastructure and science programs. There is need for healthy commercial ventures, reasonable scale and agile development with quick cycles and multiple concurrent paths.

Spaceflight could well be more routine, reliable and affordarble if there never was an Apollo or Shuttle.

<comment><USER10> Exactly. One problem that they need to solve before leaving the gravity well again is creating sustainable biospheres - capable of recycling all CO2, waste and water, producing food and, most importantly, keeping the people inside happy, healthy and sane. To my knowledge this has never[1] been achieved, and we need to work out how to do it before setting up any kind of "off world colony".

1\. Biosphere 2 was a high profile, but ultimately unsuccessful example: <http://en.wikipedia.org/wiki/Biosphere_2>

</comment></comment><comment><USER11> NASA, like most government institutions, is wasteful and inefficient. The private sector can develop cheaper, safer, more efficient rockets, in a fraction of the time. Elon Musk, among others, has laid out ambitious goals; much more ambitious then the previous goals of NASA.

This is not the end of space exploration; on the contrary - things are going to start advancing at a much faster pace.

<comment><USER12> It's sobering to think, nothing the entire private space industry put together has proposed comes close to what NASA was sitting on in the 1960's, with nuclear pulse propulsion. Now it's unthinkable. But with a slightly different historical path, we could today be launching thousands of tons at a time into orbit, on a trail of small atomic bombs.

[http://en.wikipedia.org/wiki/Project_Orion_(nuclear_propulsi...](http://en.wikipedia.org/wiki/Project_Orion_\(nuclear_propulsion\))

</comment></comment><comment><USER13> We have one, it's called Air Force Space Command Center.

Their budget was increased by 700 million in 2011 ([http://www.reuters.com/article/2011/02/16/usa-airforce- space...](http://www.reuters.com/article/2011/02/16/usa-airforce-space- idUSN1523811720110216))

</comment><comment><USER14> The best way to fund science is to cut taxes on capital and to cut tax rates on the wealthy.

<comment><USER15> Do the wealthy fund long term scientific research projects?

<comment><USER11> Bill Gates sure does with his Global Health Program.

</comment></comment></comment><comment><USER16> > just look back at the discovery of North America and foundation of the > greatest, vastest, richest, and most powerful nation the world has ever > seen.

As an American, I find this sentence somewhat embarrassing.

> There would've been no Cold War, no Hollywood, and no tea bags.

And nothing of value would be lost.

It bothers me how he thinks that education funding would have to suffer for science. Why not just defense?</comment>


Ask HN: Given opportunity to become manager. What do I do? - <AUTHOR> Hi, So I just got offered a manager role in my company. It 's one of the very large enterprises.
For a while, I have been working as a lead on all things Devops, Big data, automation, Cloud etc and my manager thinks that now I should step up in a manager role.I think I would like to try it out.
My questions are: 1) It is a major career change. Can I ask for a major salary hike? What would be the ballpark?
2) How should I go about it to ensure I make the most of this opportunity.
3) what should I do in the next few months? <comment><USER2> For sake of perspective I am a VP of my IT department (smaller company, about 300 employees, about 40 reporting to me)

1) Me, personally: I wouldn't ask for a raise (and this might be me just being pedantic) but I'd ask IF the role change has a scheduled raise and what is to be expected. I'd use this answer to help me make a decision. I'd (me, personally) would assume the role would have a minor raise and future raises based on my performance in that new job. I'd try to secure a 15-20 percent increase in pay for moving to a manager role - which, btw, is hard. Moving into a manager role means learning a new job - this isn't (or shouldn't be) your other job with a couple new responsibilities. This is an entirely new job that isn't your old job... sure, you can help people when they ask but that is entirely different than hiring/firing, writing people up, or trying to determine what sort of a raise somebody deserves.

2) Be humble. Find a mentor. Read a lot. Be humble. Be humble, be humble. I believe that power exposes more than it corrupts but it can also corrupt. Work from goals. Give clear expectations. Also, you may not like this role. I've hired a lot of developers leaving their company because they were great developers that were put into management roles and learned to hate it. Good luck! Me, I love it. (to each their own)

3) Learn. Read. Read. Learn. Read... and remember: In theory practice always works, in practice theory doesn't - You are now dealing with PEOPLE not COMPUTERS. People are emotional beings and often unknowingly irrational. HOW you say something is much more important than WHAT you say.

Lastly - learn to manage UP as much as you learn to manage DOWN.

Best of luck!

<comment><AUTHOR> Thanks for the excellent reply. I happen to enjoy reading and I am looking forward to it. Any books you recommend. Primary management skills where I lack: \- I tend to look at people through my tech lens. if someone is more technically skilled than me, I look up to them and I cannot accept laziness, non-commitment, bullshit etc. Now I understand that I need to stop doing that and see people as just people who have different moods on a daily basis. What books would you recommend to become non-judgemental, and empathetic

\- What do I do about actually non-competent people. You see, while I am excited about the role, I am also scared. I have been very good in my tech role and my management career will depend upon my team. But, in the fast few years, my team has accumulated a lot of baggage and a lot of people are totally unmotivated and non-committed. I feel like I am being given this role because noone else wants it. any suggestions?

<comment><USER3> > Any books you recommend. Primary management skills where I lack:

\- FYI: For Your Improvement, A Guide for Development and Coaching> [http://www.goodreads.com/book/show/847538.FYI?from_search=tr...](http://www.goodreads.com/book/show/847538.FYI?from_search=true)

\- High Output Management by Andrew S. Grove > [http://www.goodreads.com/book/show/324750.High_Output_Manage...](http://www.goodreads.com/book/show/324750.High_Output_Management?from_search=true)

\- The Personal MBA: Master the Art of Business by Josh Kaufman > [http://www.goodreads.com/book/show/9512985-the-personal- mba?...](http://www.goodreads.com/book/show/9512985-the-personal- mba?ac=1&from_search=true)

</comment></comment></comment><comment><USER4> 1) Sure, it never hurts to ask for a raise. The range would depend on a bunch of factors, such as your location. Try looking up the salary of your position online, such as "technical manager salary" or "engineering manager salary" or something like that.

2) Assuming you will be managing individual contributors (and not managers), there are two basic types of first-line software managers:

2.1) Managers who need to still be individual contributors. These are the types where you will still be expected to do some of the former work you did before. It's a lot like being a technical lead, except you are suddenly now thrust into a world of people management. Most technology companies view first-line managers as having this kind of a responsibility, though larger corporations with more established hierarchies may not.

2.2) Managers who are not expected to be individual contributors anymore. This is a role where your responsibilities are managing the projects and people on your team. (If your company has project managers, then that aspect of the role won't be necessary.) In terms of people management, the responsibilities include managing the career growth of the individual contributors in your team, removing roadblocks from their paths (i.e. political, bureaucratic, etc), potentially moving them around from project to project to better allocate your resources to company priorities, recruit and retain people on your team, mentor and train junior employees, set and reinforce a team culture, and think strategically about how to make your entire team more productive.

3) If your company offers management training, take it. If you like to read, there are a ton of great management books out there. One of my personal favs is "Now, Discover Your Strengths", though you can find plenty of recommendations online if you search around. Talk to managers, senior managers, directors, and VPs that you admire; interview them and ask them how they do their jobs. HR or your manager will likely give you a bunch of information on how to do performance reviews for your team. The art of delivering constructive feedback can totally be learned, though if you are new to it, it may take some time to become comfortable doing it.

This is all just off the top of my head. I'm sure I'm missing a lot of other info, but this ought to be a good start.

Being a manager is not for everyone. Some call it "herding cats," which it may sometimes feel like. But it can also be a tremendously rewarding role, especially when you can set everyone up for success and can see them humming along efficiently and effectively.

Good luck!

</comment><comment><USER5> When you become a manager expect to train as a supervisor first. Ask or accept a salary hike as a supervisor that is half of what you expect as a full blown manager. Work your way to manager because if you don't have management experience on resume by the time you are 40 expect nothing but freelance work over the age 40 if you lose your job. Management experience is what separate the expendable labor from the non-expendable staff. Management sucks, I mean having authority is great but having to hire and fire sucks. It's a great deal of responsibility and needs to be taken seriously and to be good you really need to work hard at being empathetic, unemotional, and balancing risk versus reward at the risk of your own career. To not do so just means you are a riding a paycheck and not contributing a whole lot. I made the mistake of going for the job of doing things I enjoy, worked on a lot of really cool incredible projects for well known companies and found myself unemployed over the age of 40 without the ability to get an interview despite my knowledge and experience all because I was a go to guy who got the most complex jobs done but was not a manager. Don't be me. Be humble, tell your superiors you want to work your way up to management and spend time as asupervisor first so you can train in the role as someone who must manage people and deal with HR issues while not being a manager first. Set goals and mnilestones alonga timeline and make sure they are checked off as accomplishments in your reviews. You need to train as someone who has to get your staff to do what you want despite their personalities but not make decisions about the company. Being a manager means both. Once you become numb to taking a chance on employees and learning how to communicate or have crucial converstions (read the book Crucial Conversations) it becomes second nature to make business decisions and not get hung up on the risk. I'd say set a goal of being an entry elevel manager at the age of 35. By 40 tha would make you a skilled intermediate to entry level senior manager that every one repects because you've learned to master the skills.

<comment><AUTHOR> Thanks you for sharing the experience. I totally understand what you are saying. Especially the part about 40+ and getting only freelance jobs. But I have a question: As an entry manager, how do I go about managing the incompetent team members. The reason I am being given the opportunity is that they don't have anyone to take this role and the senior manager is finding it hard to deal with so many people. But I have been working with the team as a lead and it has been quite frustrating a few times due to total lack of motivation,commitment and in many cases ability to learn from many members. I am now being given the responsibility to manage them. I worry that I might be getting into a role set for failure from the beginning itself.

</comment></comment><comment><USER6> Just some feedback I haven't seen yet.

Most very large enterprises have 2 tracks: IC and management. Typically most employees start out at IC and through defined and mutually agreed to career development plans train for the management track. This may take a few years. When the time comes for you to be a manager you have been operating in a management role for some time. This is the Peter Principle.

I'd be _extremely_ wary of a surprise promotion in to management where a discussion about that possibility hasn't happened. I've seen this before and it can lead to disaster. You may be setting yourself up for failure or even worse someone is setting you up for failure.

</comment><comment><USER7> 1) You can always ask for a raise. If you work in a very large enterprise then likely you've got a predefined levels / brackets for most positions up to a VP or similar. If not, just ask them what the raise is for that position. There's also a good podcast which may help you ([http://www.kalzumeus.com/2016/06/03/kalzumeus-podcast- episod...](http://www.kalzumeus.com/2016/06/03/kalzumeus-podcast- episode-12-salary-negotiation-with-josh-doody/))

</comment><comment><USER8> 1\. In my experience, managers in professional fields don't make vastly more money than the people below them. If it's an addition of responsibilities, I would ask for more money. If it's just a change, then does it make sense to ask for more money?

2\. Learn, try and find a good mentor, get feedback, and set objective goals.

The hardest part about management is playing the carrot and stick game without turning a report's life into a carrot and stick game.

<comment><USER9> About 1), that depends on the country. Everywhere but in the U.S. (and a few other exceptions), managers make vastly more money than ICs.

</comment></comment><comment><USER10> [https://medium.com/@jessenoller/zen-of-python-applied-to- man...](https://medium.com/@jessenoller/zen-of-python-applied-to- management-424cf5bf9ea6#.oij4xohfj)</comment>


Ask HN: What Are Various Worst Practices in Software Engineering? - <AUTHOR> <comment><USER2> Applying the tool, technique, or language you know best, instead of the one that best fits the problem.

Expecting an organizational or management approach ( _cough_ agile _cough_ scrum *cough) to fix management's ineptness.

Failure to handle corner and error cases.

<comment><USER3> > Worst Practices in Software Development >> Applying the tool, technique, or > language you know best, instead of the one that best fits the problem.

A nice platitude that ignores reality. If your team is experienced in a particular tool, it may be the better option than the new "best" option that requires tons of training/hiring.</comment></comment>


Tonic is now RunKit, a part of Stripe - <AUTHOR> http://blog.runkit.com/2016/09/13/tonic-is-now-runkit-a-part-of-stripe.html <comment><USER2> Other things called "runkit":

* a PHP module - [http://php.net/manual/en/book.runkit.php](http://php.net/manual/en/book.runkit.php)

* a Swift wrapper for Grand Central Dispatch - [https://cocoapods.org/pods/RunKit](https://cocoapods.org/pods/RunKit)

* an Objective-J animation library - [https://github.com/austinsarner/RunKit](https://github.com/austinsarner/RunKit)

Of course, there are only a finite number of possible names, especially when you limit yourself to names that are brief and meaningful, which makes name collisions almost inevitable. And maybe the above items are all obscure enough that it doesn't matter (I had heard of the first before, due to my past life as a PHP developer, but the other two I only found by searching)

<comment><USER3> From the title I assumed RunKit was a fitness-related iOS SDK.

</comment></comment><comment><AUTHOR> Hi everyone, I'm a part of the Ton-err RunKit team and would be more than happy to answer any questions!

<comment><USER4> This might not be the feedback you were hoping for, but the new name is similar to a very juvenile word in Swedish (and possibly/probably in Norwegian and other Scandinavian languages). I guess it's too late, but I would probably recommend changing it if possible.

Edit: Not sure why this is getting downvoted. I'm only pointing this out to help.

<comment><USER5> As a native Swedish speaker, it didn't even cross my mind until you mentioned it. I think it's fine.

<comment><USER4> Maybe it's not as bad as I first thought. The capitalized K breaks the word up - it was only the URL that jumped out at me.

</comment></comment></comment></comment><comment><USER6> Tonic is seriously cool and the long-term vision would be amazing for Node development however...

> Stripe decided to take a bet on our vision and our team

I feel confident to make a prediction that Tonic will eventually ride off into the sunset.

After seeing what happened to Parse, I sadly feel this is going to end the same way. If a company as large as Facebook could not keep Parse going, how will Stripe manage.

This is a good acquihire for Stripe, and a new opportunity for someone else to make a web repl.

</comment><comment><USER7> First time I've heard of RunKit. I've used Jupyter in the past to do a similar thing (minus the API stuff which is very cool). What does RunKit provide that Jupyter doesn't?

<comment><AUTHOR> Hi s0l1dsnak3123,

You might have not heard of us because we used to be named Tonic ;) There are a number of different factors that differentiate us from Jupyter, but we have of course taken a ton of inspiration from them. The data science crowd including iPython, Mathematica, etc have pioneered a development style that I hope see make its way into "normal" programming. One of the best resources is a pretty in-depth blog post we wrote about what's going on under the hood here: [http://blog.runkit.com/2015/09/10/time-traveling-in- node.js-...](http://blog.runkit.com/2015/09/10/time-traveling-in-node.js- notebooks.html)

But, to give a quick overview:

1\. One of the original driving goals when we started working on RunKit was to completely eliminate friction in using other people's code. So what we did was install every permutation of every version of every package for node. You can even require two versions at once and compare them: [https://runkit.com/tolmasky/api-diff- example](https://runkit.com/tolmasky/api-diff-example) . This has lead to many interesting uses that aren't possible with other notebooks. For example, many people use us for filing bugs, because its kind of the dream: you're not filing a bug, you're filing a computer and environment with an undeniable reproduction, that the reviewer can easily test (what happens if I change node version? what happens if I change module version, etc etc).

2\. As listed in the blog post above, we've spent a tremendous amount of time on the problem of determinism, in an attempt to "unify" the REPL and file environments. Basically, RunKit notebooks read top to bottom, _just_ like a file, and we guarantee that if you take the contents of a notebooks and run it in normal node, it should behave exactly the same. For example, no asynchronous events should be first in-between consecutive cells - this is really important in asynchronous programming. To be able to deliver on this guarantee we invested heavily on "time traveling" \-- when you edit a cell in the past, the ENTIRE virtual machine is rewound, files you had deleted are restored, etc (again, more info in the blog post if you find this interesting).

Happy to answer any other questions, apologies for the rambling, haven't gotten much sleep!

</comment></comment><comment><USER8> Is there a reason why RunKit isn't open source?

PS: does this mean Ross now works for Stripe... again? :P reply

</comment><comment><USER9> If someone wants to see a runnable demo, I've created one about one year ago, that maps the bicycle stations of Barcelona [https://runkit.com/victorb/bicing](https://runkit.com/victorb/bicing)

</comment><comment><USER10> In other news, Wingdong is now Bombom, a part of Jiive

</comment><comment><USER11> Congrats RunKit team! I've always played with npm modules before I actually started using them thanks to you guys.

</comment><comment><USER12> I can't begin to tell how wonderful is the thing you've come up with. However, I would really like to be able to

a) host it on my own server as an open source app

b) pay for it

I think it's in the human nature to ignore the users who doesn't _explicitly_ pay you and I'd be rather protected by an off-the-cloud version or being able to say "you have a responsibility towards your customers" if and when the time comes for a post titled "so long and thanks for all the fish".

edit: Or... Well... You know, if and when the site is down. It's not just me, right?

</comment><comment><USER13> Congrats, Ross and Francisco! I was curious about what you two were up to, which led me to Tonic two weeks ago. You guys move quickly! ;)</comment>


Finally, accurate iPhone numbers (270,000) - <AUTHOR> http://bits.blogs.nytimes.com/2007/07/25/apple-flash-270000-iphones-in-2-days/ <comment><USER2> If by "accurate," you mean "not even counting through the first weekend of sales."

It's hard to get a sense of how many people out there have iPhones based on the initial spike.</comment>


Ask HN: How to Fix the Internet? - <AUTHOR> On a technical and commercial basis, the internet is working quite well. Apart from that, one could argue that the internet seems rather broken. Cybercrime, fake news, clickbaiting, disinformation campaigns, online profiling, mobile phone addiction — isn't that crazy?<p>What would you suggest to fix it?<p>(You might also add your thoughts via a pull request to https://github.com/linecker/letsfixtheinternet/ or email firstname.lastname@example.com) <comment></comment>


Show HN: 3D Face Reconstruction from image - <AUTHOR> https://github.com/AaronJackson/vrn <comment><USER2> I have a question,

your method is volume based, right? so the recovered 3d face mesh is generated by marching cubes on the 3d volume? So the topology of the 3d mesh isn't necessarily aligned to the face features? like this, for example, [https://i.ytimg.com/vi/AnfVrP6L89M/maxresdefault.jpg](https://i.ytimg.com/vi/AnfVrP6L89M/maxresdefault.jpg)</comment>