Lisping at JPL (2002) - <AUTHOR> http://www.flownet.com/gat/jpl-lisp.html <comment><USER2> C++ was promoted by the Illuminati under the advice of a secret group of aliens to slow down the development of human progress. It achieves this via insanely long compile times whose purpose is stop anyone from getting shit done in good time.

I mean, how do you iterate and refine if it takes ages to compile stuff? The flow of your of thoughts has probably gone to shit before the compile is over.

Apparently the guys at CERN love it so much they created an interpreter [http://root.cern.ch/drupal/content/cint](http://root.cern.ch/drupal/content/cint) for it. No wonder the Higgs boson hasn't been discovered yet (or has it?)

<comment><USER3> first the practicalities: CINT cannot and is unlikely to ever properly interpret ANSI/ISO C++.

In my experience, many people who use ROOT at least have vague feelings that it is making their life more difficult then it rightly should. Nearly everyone I know that writes code that other people use feel even more strongly that ROOT's poor design leads to productivity losses.

[http://www.insectnation.org/howto/problems-with- root](http://www.insectnation.org/howto/problems-with-root)

[http://linuxfr.org/nodes/18919/comments/632920](http://linuxfr.org/nodes/18919/comments/632920)

[https://linuxfr.org/nodes/19928/comments/698692](https://linuxfr.org/nodes/19928/comments/698692)

<comment><USER4> Isn't CINT being replaced by Cling?

[http://root.cern.ch/drupal/content/cling](http://root.cern.ch/drupal/content/cling)

<comment><USER3> ROOT can't be said to be OO because it breaks the encapsulation in the guts. There is a massive usage of "g" global pointers : gROOT, gDirectory, gTree, gEnv, gSystem, gPad, etc... Around one hundred in v5-18-00, a disaster. And this definitely breaks the fundamental OO principle of encapsulation.

Then since ROOT violates three basic principles of OO (encapsulation, inheritance, virtuality) we are compelled to conclude that ROOT can't be considered as an OO software. ROOT is a bright example of people having jump to C++ but missed totally the point of OO. At least it will probably stay in the history of software because of that.

What could be the improvements in a ROOT major revision ?

o at least fix the name ! Is it ROOT, Root, root ? (Hell, we are pretty sure that any Bazaar model software have at least converged on that !)

o have then a correct namespacing of classes and libs.

o restore encapsulation (then get rid of the g pointers).

o revisit the inheritances. At least have a good histogram class. And arrange the storage area to be stable (then "fix" the TTree). And please, have an introspection class that looks like an introspection class.

o use pure abstract interfaces to separate domains. And stick strongly to the idea to have them pure.

o etc, etc, etc, etc, etc, etc, etc, etc, etc, etc,...

[http://openscientist.lal.in2p3.fr/osc_web_16.11/html/faq.htm...](http://openscientist.lal.in2p3.fr/osc_web_16.11/html/faq.html#faq_ROOT)

<comment><USER5> Given that this is a topic nominally about Lisp, I'd like to point out that the CLOS crowd (Common Lisp Object System) would strongly disagree that encapsulation of the restricting access kind is a basic principle of OO. That's not in Lisp's DNA.

<comment><USER3> _restore encapsulation (then get rid of the g pointers)._

Global variables begin with g

[http://root.cern.ch/root/htmldoc/guides/users- guide/GettingS...](http://root.cern.ch/root/htmldoc/guides/users- guide/GettingStarted.html#coding-conventions)

While it's true that indiscriminate use of global variables can turn code into spaghetti nearly as quickly as unrestrained use of goto, global variables do have legitimate uses and exist in one form or another in almost every programming language.

Lisp's version of global variables, dynamic variables, are both more useful and more manageable.

Common Lisp provides two ways to create global variables: DEFVAR and DEFPARAMETER.

[http://www.gigamonkeys.com/book/variables.html](http://www.gigamonkeys.com/book/variables.html)

</comment></comment></comment></comment></comment></comment><comment><USER6> ". . . we're confusing best practice with standard practice. The two are not the same."

I'm going to print this on a Louisville Slugger and bring it to architecture and design meetings.

<comment><USER7> i.e. ISHYGDDT

</comment></comment><comment><USER8> Funny thing: some C and C++ programmers who swear they could never work with the parenthesized expressions of Lisp somehow have no trouble churning out complicated GNU makefiles with cruft like $(filter-out $(patsubst %,%/d,$(foo foo bar, xyzzy) ...) ad nauseum. Note how the parenthesis is outside the function name. It must be the dollar sign somehow softens it, plus the comma separators that are required after the second argument.

</comment><comment><USER9> There are also a number of comments in an older thread at [https://news.ycombinator.com/item?id=304736](https://news.ycombinator.com/item?id=304736) .

</comment><comment><USER10> I'm a product of that cookie cutter system, its really horrible, in this case c# rather than c++ or java, I never got exposed to lisp until recently, but if you look at ruby as a kind of lisp or close to it when it comes to the web and startups the lispy coder as artist approach has won over the "software engineering" coder as inter-changeable component coder paradigm.

</comment><comment><USER11> Thanks for posting this. I wrote a whole thesis about computer vision using Ruby instead of C/C++ [1]. Now I am working on computer vision with GNU Guile (Scheme) [2]. Not that I have convinced many people apart from myself about it ;)

[1] [http://www.wedesoft.de/ruby-computer-vision- thesis.html](http://www.wedesoft.de/ruby-computer-vision-thesis.html)

[2] [https://github.com/wedesoft/aiscm](https://github.com/wedesoft/aiscm)</comment>


A Possible Keats - <AUTHOR> http://www.nybooks.com/daily/2017/07/24/a-possible-keats/ <comment><USER2> It was great to read that, after reading the excellent Hyperion cantos by Dan Simmons [https://en.wikipedia.org/wiki/Hyperion_Cantos](https://en.wikipedia.org/wiki/Hyperion_Cantos)

<comment><USER3> One of the best set of science fiction novels I've read. I'm always surprised at how few sci-fi loving friends haven't heard of the Hyperion Cantos. It should be required reading.

Apparently it's being made into a movie. All four books squeezed into a feature length film.

<comment><USER4> I can't imagine how they would manage that in one film. The first book alone feels more like a series, with each episode covering one pilgrim's tale. Then there's the time jump between the Hyperion books and the Endymion books. Maybe two movies could work. Maybe.

</comment></comment></comment><comment><USER5> I'm reading through Fleur Jaeggey's recently translated short story collection _I Am the Brother of XX_ right now. If you enjoyed this piece by her, check it out. It's dark, glittering, terse yet rich, and thought-provoking.

<comment><USER6> If it's all as intense as "A Possible Keats" I think I'll give it a miss for the moment. I don't think enjoyed is the right word. Appreciated certainly, but not enjoyed.

<comment><USER5> It is all rather dark, condensed, and intense. Certainly not everyday reading for most.</comment></comment></comment>


Invention Worms - <AUTHOR> http://www.whattofix.com/blog/archives/2009/03/invention-worms.php

<comment><USER2> Daniel is proposing to create a HN-like site to aggregate interesting hacker news and writers that no one else is serving. He proposes some variation on the HN karma system because it's an itch he wants to scratch. Some experiments: no down modding,karma is fungible,tunable aggregation, finding little seen material, and making it more sociable.

If he can create a site with good, people, good material, and good discussions, I say more power to him.

Of his 6 bullet points, "There's good material out there nobody is using" is the only one that strikes me as significant. This is the hard one because he will have to activelh dig it out. I dont think automatic aggregation will do the trick.

Does he need more on the social side than HN provides? Just contact info for those who want to be contacted or maybe RSS feeds for particular commentors.

So let me give a couple of niche areas that I am interested in. I am wallowing alone in the complexity of the Jboss/hibernalte/spring/struts stack. What are others doing? Collect entrepreneurial best practices. Browser side best practices or programming techniques. What's new on the programming language front, particularly concurrent programming? OK that's 4 suggestions.

<comment><AUTHOR> Thanks for the validation on the "there's good material out there that nobody is using" point, russell.

I'm still working on ideas for collection, but I know an easy way to filter: simply refuse submission from any of the top 10K internet sites or so.

What would a news aggregation site look like without material from Engadget, CNN, NYT, etc but yet with stuff you really enjoy reading? Is such a thing possible? Or in other words, does the popularity of the source determine how much you enjoy reading the content, and not the content itself? Kind of like the expensive wine taste tests, where people consistently view expensive wine as tasting better but _only_ after somebody tells them the price!

I don't know. I do know that it's been bugging me.

<comment><USER2> 10K top sites seems like an awfully large ban, so I would edit the list to allow interesting sites. Another tactic would to subscribe to feeds from particularly interesting sites, maybe filtering them for content length. For example, take joelonsoftware. He has interesting things to say, but most of his posts are there to keep the site fresh and should not be aggregated.

As for what I am looking for, I want information about techniques and developments in the software development and web entrepreneurial spaces. Popularity is probably a negative, because I have already seen it elsewhere.

I value commentary. I read the comments on HN before I read the story to see if it is worth the investment of my time. I also do first comments as a kind of payback. An interesting twist on HN would be to require a comment on a submitted article rather than prohibiting it. That might be an effective junk filter.

<comment><AUTHOR> Yep, you're right. Perhaps only 1K sites as a rule. I also like the idea of getting feeds and just manually sorting through them. I firmly believe that there's a mix between old-fashioned editing, user-editing, and user- submissions that hasn't been tried yet. Seems like everybody wants to do one or the other, when mixing them up might be the best solution. Perhaps an editor scours the top-hundred or so sites in a niche, along with user submissions. After the editor is finished, users can validate or not the entries based on feedback, like you said.

At the end of the day, how many articles do you really need to provide the average reader? It can't be that many. If you can find four or five truly unique and high quality articles for a reader each day, I think you'll build a loyal following. So the goal is to have zillions of articles enter, but only a few appear to the reader. I don't think "herd mentality" or voting systems are the way to sort that data. There has to be a better way.

Good stuff to think about.

<comment><USER2> You probably need to allow more than 4 or 5 per day to encourage your readers to submit stories. I would suggest putting featured stories at the top and other noteworthy submissions below or on anther page. People really like to see their names in lights. Some concession to that will encourage that. Of course the downside is more trash. HN survives by the diligence of its community. Manual moderation should work well too.

</comment></comment></comment></comment></comment><comment><AUTHOR> I've always been curious as to why people start programming projects. The usual answer is because they have some problem they want to solve, but a lot of times people just enjoy coding.

Sometimes, however, the problem overtakes the person. You're stuck _having_ to code, to get it out of your system. I was trying to ask in this article -- is this a common thing or not? It happens to me maybe once every year or so. Didn't know if anybody else felt that way.</comment>


Why don't software development methodologies work? (2014) - <AUTHOR> http://typicalprogrammer.com/why-dont-software-development-methodologies-work <comment><USER2> For me, the real issue is ownership. I come from a finance background and have seen "business people" often run technology into the ground because they simply can't let go of ownership or control. They want to define too much and leave little in the hands of the developer. Development managers can be just as bad with their overarching methodologies. Really bad ones can stifle the creativity of their developers by micromanaging and just end up making people miserable. I personally don't follow any particular methodology, but instead, I agree with each team member a well defined deliverable and deadline, and just let them get on with it (with whichever methodology they prefer). The only thing we stipulate as a firm is the version control system and test procedures. The whole team has an informal chat once a week or so to make sure things fit together properly - no daily stand up rubbish. It's not complicated or even that structured, but it works and my colleagues seem happy. Basically our philosophy is, hire good people, make them responsible for something, and let them find the best way to deliver. And definitely don't tie them up in stupid admin tasks as stipulated by the latest fad.

<comment><USER3> Ownership is good, but only up to a point. In this approach, developers end up being independent contractors on a payroll.

If you focus only on deliverables and deadlines, you'll end up with developers using a mix of different approaches, libraries and even languages. It hurts team cohesion and makes the logistics of project management much harder since Joe can't take over Tom's code now that Tom has the flu.

As I see it, one of the main tasks of a technical manager is to set conventions so everyone would feel at least semi-comfortable with everyone else's code. That's not micro-management, that's management.

<comment><USER4> One view of management is that it's about making sure the cogs of the machine are completely interchangeable. Everything is uniform, orderly, perfect. Everyone is replaceable. No one's contribution can be distinguished from that of any other. Everything must be measurable and measured. See how the graphs in our status updates always show progress!

This is actually an extremely inefficient and demoralizing environment for those involved. Yeah, it's easy to take over when someone leaves, because they were so hamstrung by the environment that they never built anything interesting. And you're going to be doing a lot of this taking over, because people are always leaving, because they were hamstrung. So this idea that we can't trust individuals to stick around and do a good job, and we have to make sure they never have enough power to do damage when they make a mistake, it's a self fulfilling prophecy. It makes them untrustworthy and drives them away.

It really is about ownership. Programmers who are achieving at a high level move _much_ faster and do _much_ greater things. It's worth letting them make mistakes to retain the best people and get their best work. The only catch is figuring out how to keep them accountable for their decisions. OK, you want to use this new tech or try this new architecture. How do we tie your compensation and career progress to the success of those decisions?

<comment><USER3> > One view of management is that it's about making sure the cogs of the > machine are completely interchangeable.

That's not what I was talking about. Employees are neither bricks nor cogs. But having said that, if you run any long-term project, you should expect people to come and go, it's part of the game. Thinking that this will not happen in _your_ project is simply negligent.

> This is actually an extremely inefficient and demoralizing environment for > those involved.

It doesn't have to be. Working with common conventions and tools doesn't have to be demoralizing. Conventions should be set for a good reason, after an open discussion, and possibly even a vote ("Do you think that it's worth bringing in this library?", "Should we all use the same IDE?"). Also, conventions aren't set in stone, they can change over time.

This gives _the team_ ownership of their project. It makes passing knowledge between team members easier, it makes it easy for team members to help each other when they've run into an issue, not to mention that it makes code reviews and various technical discussions a lot easier.

If Bob is writing using a different language or a set of libraries than the rest of us, who can review Bob's code? Who can help him out when he's stuck on some bug? Who can help him flesh out his design ideas for some feature he's writing?

Without team cohesion, you're creating not a team of developers, but a bunch of individuals who happen to work on related stuff. I don't know about you, but to me that sounds a lot more demoralizing. To me, one of the great benefits of working on a team is that we all get to learn from each other, plus we get to share a common goal. Agreeing to some common conventions seems like a small price to pay for that.

<comment><USER4> Team cohesion is definitely not about using the same IDE.

I worked at a place that essentially standardized on Vim. They emphasised pair programming so IDE standardization helped with that. If you already use Vim, sounds great. If not, probably sounds terrible. So what looked like team cohesion was homogeneity. They subtly turned away a lot of people who didn't fit the mold in what should be a minor detail.

I've worked at two companies that basically banned Redis. Having a conversation with an SRE who had a bad experience, trying to convince him it's worth having this tool available, is one of my worst professional memories. Consensus driven technical decisions suck. It's better to give people authority and responsibility. I would have happily admined it myself.

Nobody's going to review Bob's code, not really. If they're not working directly with him on the project and it's doing anything reasonably complex, then they don't have the context to say anything useful beyond catching typos. Things get rewritten every few years anyway.

</comment></comment></comment></comment></comment><comment><USER5> > I think programmers should pay much more attention to listening to and > working with their peers than to rituals and tools, and that we should be > skeptical of too much process or methodologies that promise to magically > make everyone more productive.

Sounds pretty much like:

> Individuals and interactions over processes and tools [1]

I don't know why, but somehow people don't get it that agile is not a methodology but a spirit.

[1] [http://agilemanifesto.org](http://agilemanifesto.org)

<comment><USER6> > I don't know why, but somehow people don't get it that agile is not a > methodology but a spirit.

Because of all the agile coaches, boards, trainings, conferences and companies. It feels then more like a religion.

<comment><USER7> I'm sympathetic to agile but it does have a quasi-religious feel to it. I've noticed that its proponents make claims about the right way to do things with an unwarranted level of certainty. When I ask "why" (politely) I seldom get a satisfactory answer and often they get offended by the very question.

<comment><USER8> All methodologies are created for people who do not understand "why", they are inherently religious. Otherwise why would you need a methodology if you do understand all the "why"s? You can just develop one much more suited for your people and your projects and fine tune it over time.

</comment></comment></comment></comment><comment><USER9> There is such a things as physics in software: between time, scope and people, one of them almost always has to give. Exceptions I've seen are with mature and well-bonded teams working on familiar scope they understand clearly, with a timeline they themselves defined.

I've found the best "methodology" to deliver decent results are sticking with short iterations. Software is often about doing something we've either not done before, in a way we've not done it before, with people we've not done it with before. So we will have surprises (aka delays) on the way. The more frequent we check just what these delays are, the more realistic we can be about whether we can make it on time, or if we need to cut scope or pull in more help to make it on time.

<comment><USER10> > There is such a things as physics in software: between time, scope and > people, one of them almost always has to give

This can be true but can also be completely false. Massive differences in productivity are possible depending on how individuals work together on a team.

<comment><USER11> True. Also, there is a fourth variable where you can cut corners (even if it's almost never a good idea): quality.

Great teams can produce much more than mediocre ones, but they too have a limit. When deadline is set too close, one of these 4 things has to give, and it is good to know in advance which one that is, so team can set the priorities accordingly.

<comment><USER12> I would say that is part of the scope. The scope being a well tested, functional and relatively bug free software that does x, y and z.

<comment><USER13> Unfortunately most business people don't make things like "doesn't corrupt the database when an exception is thrown" into a feature bullet.

So while you can argue it's part of the scope, it's not part of the scope that anybody else seems to think about.

</comment></comment></comment></comment></comment><comment><USER14> This sits uneasily with me. I cannot remember any time when a Methodology was followed in practice. Just my bad luck?

The relogious people (mentioned in the article) harmed by false adherence. They adhered to the headlines and warped the substance of what the Methodology said. I remember (with pain) a place that wouldn't develop development scaffolding. They had rules for software development, good ones, motivated by achieving near-perfect uptime for customer-facing services. Implementing a scaffolding service or crontab to that standard was a lot of work.

Then there's the non-adherents who eroded the Methodology. Like the scrum shops that eroded scrum by deemphasising the product owner and stories until the result looked more like a waterfall.

The Methodologies may be broken as a whole but the practice I've seen was generally so distorting that I feel it's unfair to blame the Methodologies.

<comment><USER15> If a methodology cannot be followed effectively by (presumably intelligent and sincere) individuals, why blame the people?

This reminds me of the people on the far right or left who believe, "[Capitalism/Communism] can't fail; it can only _be_ failed."

<comment><USER14> This would be an excellent point if there existed a methodology that people do manage to follow.

Some of the failure I've seen can be partly explained by people who wanted to have their cake and eat it. Who wanted, say, the promised advantages of Scrum but were not willing to pay its costs (lack of long-term plans and fixed finish dates).

That's not all. It's part of the explanation for some of the suckage I've experienced.

I do blame people for not making up their minds. The people who invented scrum were willing to give up some parts of long-term planning, and got remarkable results for that. They are not to blame when others later failed by not giving up blah.

Maybe some blame should go to conslutants who oversold the benefits of Methodologies without stressing the costs. "YES YOU ACTUALLY HAVE TO DO THIS, IT WILL WORK BADLY OTHERWISE".

<comment><USER16> I take the other view. I actively blame some of the people that "invented" these methodologies.

Being introspective of your capabilities and your achievements is an extremely valuable skill that I wish more of us had. However, selling your capabilities and giving vague promises that it will help with development if you only followed these practices is a deceitful way to make some money off of your reputation.

Worse, many of them do this by attacking those that came before them, but then taking the stance that their "teachings" are above attack. And that anybody that isn't getting the same benefits they did just aren't applying themselves correctly.

</comment></comment></comment></comment><comment><USER17> I think methodologies could benefit by being treated like software, since that's effectively what they are - 'human' software to manage teams. That means:

* Frequent releases (i.e. do iterations or 'sprints' or whatever).

* Accept that your methodology has bugs and 'fix' those bugs between releases. Most software is horrible and buggy. Don't trust the "methodology gods" that they wrote a perfect piece of working software. It's probably half assed and worked semi-well for their specific use case so they 'released' it along with a reality distortion field.

* Accept that different use cases require different methodologies. Writing space shuttle code? You need vastly different team dynamics to a group of 10 people at a marketing agency running short lived campaigns.

* Follow the UNIX philosophy: don't have ONE methodology that you follow to a T - string together a bunch of small, self-contained rules and team processes that serve your purposes and iterate upon them.

tl;dr fuck scrum. it's the internet explorer of methodologies.

<comment><USER18> Scrum is great for non-software companies that need to write software.

They will not attract the most talented software developers (on average, not in all cases), and the business people for whom the software is a means to an end care more about consistency and predictability rather than quality.

As a result, fungible resources (humans), deeply regimented stories, regular delivery milestones (sprints), and consistent velocity IS the best possible outcome.

<comment><USER17> Scrum is not 'great' in any sense of the word.

I don't think it really matters what kind of company you work for. I've worked for many software and non-software companies and the same issues crop up in both.

The main one is that scrum accelerates the accretion of technical debt, which "business people" can somehow not care about right up until the point where it drives them out of business.

It has some good ideas (retros, sprints, no deadlines) and some terrible ideas (treating team members as fungible, story pointing/velocity, too many meetings, PO has to make decisions about specific pieces of tech debt).

My main problem with it is the teachers, coaches and promoters who take an all or nothing view of it and who treat deviations from the official 'scrum' policy as, by default, problem with the team rather than, potentially, a bug in SCRUM.

I used to think that it was a good base to work from, but after arguing fruitlessly with the people who take a religious approach to it I've come to the opinion that it just needs to be trashed wherever possible, because the problems it does have will only be resolved by moving on to something else. Better to move on sooner rather than later.

So, fuck scrum.

<comment><USER19> What's the issue with story points and velocity? I've been using them for years and personally I think they're some of the best parts of agile!

<comment><USER17> Your team's velocity going up can mean that:

* Your team did more work this week.

* Your team worked more efficiently this week.

* Your team inflated its story point estimations this week.

Any one or all of those things could have happened in varying degrees.

Given all of that, what useful knowledge is it actually supposed to impart?

The best part is the number of story points / velocity can vary wildly depending upon what the team believes the measure is being used _for_.

<comment><USER19> In my experience, if you track velocity long enough, and 'categorise' the values based on things like team size, technology etc, you get values that are useful to predict how much work you should commit to in an iteration.

Yes, things change: productivity, moral, team members join and leave, some teams are _shit_ at estimating etc - but at least in my experience if you take an average you do arrive at a useful figure.

<comment><USER17> In my experience if you have some sort of measure that looks a bit like productivity then senior management will latch on to it and treat it as a proxy for productivity.

That inevitably means that developers have an incentive to inflate their estimates, which means story point inflation.

Averaging does not fix this dynamic.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> My own view is that something analogous to Conway's Law is at work: software design reflects the constraints inherent in the software methodology used.

The problem is not software methodologies per se, it is trying to apply a software methodology to software development where the priorities of the methodology are fundamentally at odds with the requirements and goals of the software being built. The root of the problem is the notion that there is one software methodology that is efficient and productive for all possible types of software development. I would argue that there is an optimal methodology for most software but it is a different methodology for different types of software.

If we discard the oft-argued proposition that a PHP website, an embedded system, and a high-performance database kernel can -- and should -- all be developed with the same software methodology then this entire discussion goes away. A software methodology is a tool; they work best when you select the best one for the job.

</comment><comment><USER21> I think this is why DevOps is becoming so popular. It's less about methodology.

There's no certificate, role, set of tools or prescriptive process. There's no specification, it's not a product, or job title. There's no one true voice on what DevOps is or isn't. It's about attitude, ideas, customs and behaviours. Culture, paradigms and philosophy. It's a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It's a conversation. It's about taking the best experiences and sharing those with others.

<comment><USER22> A lot of companies just rechristen their "ops" guys "devops" and then say they're doing devops.

<comment><USER23> The company I work at did this. The CTO and I even joked about it being "DevOps in name only". It's gotten better, but they're really still an ops team.

<comment><USER22> I mentioned to some people at my company that "devops" was meant to be more of a philosophy than a separate team and they were bewildered. But I guess I'm happier with ops being a separate team anyway.

<comment><USER23> Right? Ops, but an ops team you'd trust touching the code.

I feel like devops to most just means "ops but closer to the code now that there are so many code/release management tools and someone has to manage it all".

</comment></comment></comment></comment></comment><comment><USER24> I find the problem with development "methodologies" are the people implementing them. Frequently the Agile Master or someone who has read the book and granted a certification but doesn't understand the subtleties of company culture, team capabilities or project etc. They just want the "process" to be followed.

<comment><USER25> Methodologies help. But ultimately there is no methodology that lets you make money, deliver products that buyers want, outsmart your competition, eliminate team/corporate politics and so on.

I don't know why people buy into the "when we'll be agile enough, everything's going to be ok; until then let us use this whip and self-flagelate for not being agile enough:

</comment></comment><comment><USER26> Seems to me yet another confirmation of the first rule of the Agile Manifesto: "Individuals and interactions over processes and tools."

The methodology cannot be effective without creating the right personal dynamics.

<comment><USER17> I've seen many teams claim to have switched from 'waterfall' to 'agile', but the only ones that haven't slipped back into a 'waterfall'-like mode after a few bad releases have been ones that put a strong emphasis on tools - specifically testing tools.

Good interpersonal dynamics are important, but the sheer level of irony that the _first_ rule of the Agile manifesto emphasizes deprioritizing the _main_ thing that will actually get you away from waterfall-like development is pretty staggering, IMHO.

Never mind. Forget the tests. If you have a meeting at 11am every morning where anybody who sits down is shouted at then you've done it. You're "agile".

<comment><USER26> The manifesto emphasises the importance of sharing the values of a method, before actually applying the method. It's the difference between wisdom and dogma. Take tests for example: blindly going for coverage metrics will be much less effective compared to having a deep, shared understanding of the pro's and con's of testing. To know that your co-workers have a similar understanding of the methodologies, makes the methodology itself of lesser (or no) importance.

Personally, I am of the opinion that a strong emphasis on test-driven development in the long run will cause waterfall-style development. Tests are all about risk-prevention, instead of risk-mitigation. Prevention eventually becomes exceedingly expensive, whereas mitigation is all about building robustness into the running system. Due to that, the scalability of mitigation systems, such as true micro-services or actor-systems, are inherently more dynamic and cause less latency in development.

I don't understand your last statement. It seems to confirm my position: "... anybody who sits down is shouted at ... ". The process (standing up, not sitting down) is less important than good team dynamics (not getting shouted at).

(edit: down-voters, please share why you down-vote! I'd like to know. Also, please don't down-vote based on opinion, but on weakness of argumentation instead.)

<comment><USER27> > edit: down-voters, please share why you down-vote!

The one thing that I religiously downvote on HN is complaints about down votes.

<comment><USER26> Well, at least I now know why you down-voted :) Sometimes I ask because I feel a comment was properly written, non-offensive and with reasonable argumentation. I put time and effort into finding the right words and thought through my argumentation multiple times before writing it down. Since English is not my mother-tongue, I'd like to know if i caused a possible misunderstanding. Hopefully others share my belief that down-voting should be reserved to punish abusive behaviour.

<comment><USER27> I understand the desire for an explanation but more often than not in my experience a comment that has quickly been downvoted to in a fit of follow- the-leader will soon be voted back up into positive territory. You just have to be patient :)

</comment></comment></comment></comment></comment></comment><comment><USER28> There's a difference between methods that are shown with evidence to help developers and methods that are merely marketed as such. The writeups on methodologies should distinguish between these. It's also possible these people have thought about methodologies a long time without ever discovering the ones that work. Fagan Software Inspections, Mills' Cleanroom Software Engineering, Meyer's Eiffel Method, and Praxis' Correct by Construction all worked if we're talking about developers delivering products in acceptable timescale with low defects. They all let developers do their job in an iterative way providing extra tools or restrictions that help ensure quality and/or maintainability.

[http://www.mfagan.com/pdfs/software_pioneers.pdf](http://www.mfagan.com/pdfs/software_pioneers.pdf)

[http://infohost.nmt.edu/~al/cseet- paper.html](http://infohost.nmt.edu/~al/cseet-paper.html)

[http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf](http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf)

[http://www.anthonyhall.org/c_by_c_secure_system.pdf](http://www.anthonyhall.org/c_by_c_secure_system.pdf)

On concurrency side, there were also SCOOP for Eiffel and Ravenscar for Ada which eliminated race conditions by design. Some methodologies in high- assurance sector were using tools like SPIN model checker for it. People spent a _long_ time talking about those bugs while some design methods just removed them entirely. A lot less debugging and damage might have happened in industry with the aforementioned methods getting way better with industry investment.

[https://www.eiffel.org/doc/solutions/Concurrent%20programmin...](https://www.eiffel.org/doc/solutions/Concurrent%20programming%20with%20SCOOP)

</comment><comment><USER29> In the age of Internet, I believe there is a way to conduct experiments that would yield an answer based on data. Spitballing here, but how about a kind of contest for 'points' where a statistically significant number of devs volunteer to participate. They each provide a 'resume' (GitHub, LinkedIn, CV,...) into the system. The programming task is presented and the devs self assemble into teams, and endeavor to complete the task.

As an example, let's say 100 devs jump in. The task is to create a simple Android app, with a requirements statement provided, with server back end, launch it into the app store, support it for some period with bug fixes and improvements, and then declare it '1.0 released' to wrap up the experiment.

What you'd wind up with is a variety of team sizes, a variety of team experience, a variety of development systems used, a variety of outcomes. But all building the same software.

The key would be that as many attributes of each team's efforts as possible would need to be recorded and entered as data to be studied in search of patterns.

Repeat this _n_ times and I believe valuable insights could be gained.

Rather than trying to control for all the variables of team size, experience, method, you control for the end product being targeted and then look for insights into the variety of approaches that teams took.

<comment><USER30> The problem with the observational approach is generally that it's really hard to decorrelate the results. In your proposed experiment you control only for the project itself. What if good developers generally prefer modern programming languages, so they chose Roslin. Does that imply that using Roslin is a better language for programmers that are not as good? Does it even show that they wouldn't have been even more productive using Java?

From the other direction, even if you get the value of controlling for the project itself, that might also add some bias. Could be that for a project with that setup waterfall actually works pretty well, but is it representative of projects overall? Are most software projects comparable to developing a simple Android app with a well defined specification up front?

I do agree that it would be good to do this kind of experiments where multiple teams get tasked with building similar systems to figure out what works. But I don't think it makes sense to actively avoid controlling for variables. That would make the results very hard to interpret and much less usable.

</comment></comment><comment><USER31> Agile always seemed like a cargo cult.

When you don't understand how or why something works, this is how you go about it. Let's make airplane-shaped things out of coconuts.

<comment><USER32> Really being agile basically amounts to "use best judgment at all times". It is highly unstructured because it provides absolute freedom. That means that the only people who can actually be agile (have the experience and discipline necessary), are the ones who don't benefit from being told to be so. Any time a team is told to "be Agile" to fix their problems, that team lacks the maturity to actually "be Agile".

</comment></comment><comment><USER33> I have a question: can someone describe something akin to what we call "methodology" in a completely different field?

Does "scrum for surgery" exist? What is an equivalent of "waterfall" in warfare?

Does something like this exist at all?

<comment><USER34> Not really, although in the book "The Checklist Manifesto", Atul Gawande reports that having something akin to a "stand up meeting" before a surgery has been shown to reduce the likelihood of errors occurring during that surgery. And that brings us around to "agile" methodologies. I feel like most people agree that the underlying value system outlined in the agile manifesto made sense, and that many of the practices outlined can be useful, but at some point (scrum, maybe?) a particular set of practices got bundled up and sold as The One True Way of Doing Things, and then sanity went out the window. For example, test-driven development can be a useful tool for thinking about how to approach a problem, but of course it isn't the only way to write a program (see Ron Jeffries hilarious attempt to TDD a sudoku solver as a counterexample). But sadly, many teams aren't in a position to think critically about what they do or don't do - instead, they have to show that they're "doing Agile".

</comment></comment><comment><USER35> > But in terms of the only measurement that really matters—satisfying > requirements on time and within budget—I haven't seen any methodology > deliver consistent results.

Good, Fast, Cheap. Pick two.

That's what you are doing when you are pitting requirements, a time frame, and a budget against each other.

The first problem is this is a company wide process, not just software development. The only thing development tells you is how long it will take given the budget. Development doesn't define the requirements or the budget.

The third statement in the Agile Manifesto, which tends to get overlooked:

"Customer collaboration over contract negotiation"

That is entirely a business process and ultimately determines both the requirements and the budget. It is something that is sorely lacking at most companies, regardless of how hard their engineering department tries to follow agile. It doesn't work without the full company buy-in.

<comment><USER22> In many software projects none of those are satisfied.

</comment></comment><comment><USER36> > Try this thought experiment: Imagine two teams of programmers, working with > identical requirements, schedules, and budgets, in the same environment, > with the same language and development tools. One team uses waterfall/BDUF, > the other uses agile techniques. It's obvious this isn't a good experiment: > The individual skills and personalities of the team members, and how they > communicate with each other, will have a much bigger effect than the > methodology.

Another thought experiment: imagine getting two teams of programmers using the same methodologies and everything else and expecting the results to be the same. It's just not practical to perform studies like this because there are too many variables.

<comment><USER37> That's because you are using an extremely small sample; of course the individual differences are going to matter. Now, get a random sample of 1000 teams using waterfall and 1000 teams using agile, and you'll get much more meaningful data. The larger the amount of samples, the more the individual differences are going to be smoothed.

Of course, not many people have the resources to do that kind of experiment.

<comment><USER36> > Of course, not many people have the resources to do that kind of experiment.

That's what I meant about it not being practical. Who would invest that amount of money? There's infinite variations of different methodologies as well.

I'm not sure what the solution is but it's tiring seeing bad studies used to promote certain approaches.

<comment><USER38> > _That 's what I meant about it not being practical. Who would invest that > amount of money?_

Tons of organizations and governments could.

20 10 person teams * 5 methodologies = 1000 people, for a 1 month project = 1000 * $100.000 = 100M dollars.

In the grand scheme of things this is insignificant amount -- in a world where businesses spend $15 billion for buying Instragram. A military could do that kind of spending for buying a single airplane -- and such a research could potentially have a huge impact / savings on future soft-eng projects.

And it could be even subsidized or be tax-deductible. Or could easily drop to like $70K or $50K per month compensation.

</comment></comment></comment></comment><comment><USER39> Software methodologies don't work because we're not getting the fundamentals of software development right. Reorganizing your kitchen layout won't help your restaurants if your chefs are still struggling to make scrambled eggs.

The most important thing any software team needs is proper logging, monitoring and metrics. No matter how great your process and engineering culture, you'll need logging, monitoring and metrics; things will happen. The worst part is that this is relatively cheap and simple to do (at the scale that most of us operate on), with huge rewards, and most teams still do it wrong. Whether they're logging too much noise, or collecting metrics that show what's right vs what's wrong, or swallowing exceptions, etc. This is the litmus test.

Next are automated tests. Unit tests, integration tests and fuzz testing. The downside with this is that it takes a long time to master. Yes, it costs time at first, but that's why you have senior developers who should be able to use tests to save time and teach others from their mistakes (like too much mocking).

Finally, code reviews and pair programming. Almost every line of code is an opportunity to teach and to learn. No methodology or tool can help if you hire junior programmers and don't do pair programming (or some other really involved mentoring, but I don't know of any).

Technical debt is real. Most of the time people don't have time to do things right is because they didn't take the time (or didn't know how) to do things right in the first place.

<comment><USER40> What metrics do you use for software?

Most of the struggle with methodology research is due to the difficulty of objectively measuring code productivity or quality.

</comment></comment><comment><USER41> I don't particularly think the methodology merchants are in the business of improving software development. Their bottom line is affected by selling trainings, consultancy and certificates, thus the single metric of a methodology working is whether and how fast it can grow its user base, keep them happy and coming back for more. It might loosely correlate with improving software quality, but that is entirely secondary.

</comment><comment><USER42> They don't work because it seems most places treat software development as a function separate from whatever the company does (with the exception of software companies which rarely follow one "methodology" but just do what works for them). Software is a way to tell a computer how to produce an outcome. The more important thing is how that outcome fits into the business, not the method of reaching it.

</comment><comment><USER43> I like the article, and agree mostly. Though I've come to look at it a little different.

Agile/waterfall/etc are PM methodologies used to manage software devt projects. Especially Agile has limited use beyond software devt.

Methods of deving software are things like: domain driven, data models first, TDD, etc.

Then there are programming paradigms: OOP, FP, Actor based, etc.

So the set of "techniques" the article lists in one list are of different types. All of these have to be evaluated against the people that have to use them (don't for OOP on an FP team, or vise versa) and the type of problem to be solved (TDD is less usefull for a simple UI project, than for a complex algorithm involving time and lots of corner cases).

</comment><comment><USER44> "Whether a methodology works or not depends on the criteria: team productivity, happiness, retention, conformity, predictability, accountability, communication, lines per day, man-months, code quality, artifacts produced, etc. Every methodology works if you measure the right thing. But in terms of the only measurement that really matters—satisfying requirements on time and within budget—I haven't seen any methodology deliver consistent results."

You star with a premise that requirements, time constraint and budget are all set magically right before the project began.

<comment><USER45> That's actually a good point. In my company most projects start with a fixed budget, a hard deadline and unclear always changing requirements. Everything is already set before the dev team gets involved.

<comment><USER46> That's a failure of the project manager. Before any deadline is set the dev team leads are supposed to meet with all of the leads on the project, who in turn meet and come to a consensus with their teams. The results of the negotiations are supposed to start at the top with the idea and goals, go all the way down to the people who will be executing them, and then go all of the way back up to the top over and over until everyone until a consensus is reached. Things may change, but in proper/formal project management a change management process is in place where the leads must come to a consensus before any change is approved. Good management enforces this process, and good leadership at any level makes everyone above and below them aware of the implications of what everyone wants. Everyone has to be on board and working towards a common goal, and come to agreement to how best to reach that goal. The biggest problem I see is at the organizational level, where the project manager is not the one with authority to control the process. When this doesn't happen, the people above and below them are not protected from the implications and things go bad for everyone. This is taught in PMP courses, but what isn't taught is what happens when the organization doesn't give the project manager authority but instead turns them into a project coordinator or project expediter. A formally trained, knowledgeable and experienced project manager with the authority to control the process can and will make sure everyone is on board, but they can't do that when their authority is undermined by the organization, client, or teams. Likewise for the team leads. This is the definition of cooperation.

</comment></comment></comment><comment><USER47> I find if you have excellent programmers who enjoy the problem they are working on and are put under the right amount of pressure you get great software no matter what process is followed.

<comment><USER48> In that scenario I bet they're even more effective without the condescending "manager" adding nothing.

</comment></comment><comment><USER49> The thing that I feel these methodologies solve is reminding developers of the users.

Ultimately a lot of people tend to lose track of higher level objectives when working on the (admittedly complex at times) implementation details. This is probably the biggest productivity killer in the business

How many of us have had that first demo with some people external to the dev team and for all the feedback to be super obvious things that could have been caught before a single line of code was written?

</comment><comment><USER38> Because software has uncertainty (about requirements, environment, tolerances, complexity) and creative elements thrown in.

It's not a regular pipeline kind of workflow, like some Taylor-inspired assembly line, or regular old civic engineering.

Besides all those methodologies are unscientific BS invented by consultants, not something derived from actual studies (even when there are some comparative studies involved they are laughable in scope by scientific standards).

<comment><USER15> Exactly. Software development is fundamentally unpredictable because you're always making something that's new, at least to the team doing the making.

After all, if you were repeating yourself, you'd just re-use the methods and classes and packages you'd already written; worst-case, you could copy+paste the code and tweak it.

And since you're doing something novel, of course you're not going to be able to predict how long it will take, beyond extremely broad guesses.

</comment></comment><comment><USER50> The author misunderstands what methodology is. TDD is a single practice, not a methodology. OOP is a way of structuring code, not a methodology.

What I have seen work is methodologies adopted to get the benefits of what the methodology actually delivers. Not a checkbox so say "we are X".

<comment><USER51> Thanks for the comment. I'm the author of the original article. I was surprised to find this old piece on the HN front page today.

With all respect, I don't misunderstand TDD or OOP. I agree that those aren't methodologies in the strict sense. But rigid adherence to OOP design or TDD can paralyze a team and focus development on goals that aren't the customer's priorities. OOP and TDD can influence how the team works and what shape the project takes just as much as waterfall or agile. When I read articles claiming that TDD is the sure path to reliable development, that's a methodological claim, not a technical practice.

<comment><USER50> I think we're really in "violent agreement" here. Rigid adherence to these "things" (not necessarily methodologies) never work. The benefits of what these "things" offer, to the degree that they are understood by the practitioners, are real. But they are often (perhaps categorically) misunderstood, applied haplessly and held to claims they never made in the first place.

<comment><USER51> Yes, we're in violent agreement.

</comment></comment></comment></comment><comment><USER52> Software is no different than any other engineering discipline. We absolutely do have software development methodologies that work, we have decided to exchange speed for quality.

Better, faster, cheaper, you get to choose 2 and only 2, we've selected faster and cheaper.

</comment><comment><USER53> This article is unreadable on my phone. All I see is the immovable side-bar filling 80% of the screen with "hire me" in the middle. Ah, no thanks!

</comment><comment><USER54> [http://programming-motherfucker.com](http://programming-motherfucker.com)

The one true methodology. Preach!

</comment><comment><USER55> I spend more time now on asinine meetings than writing code. Must be some kind of ironic hell. Needless to say, I agree.

</comment><comment><USER51> Some great comments here. Does anyone mind if I link to this thread from the original article?

</comment><comment><USER56> It sounds like author is not too fond of code reviews, test approaches, and linting rules. These things are based on personal preference and semi- religious beliefs often leading to conflicts, even on two person team.

</comment><comment><USER57> No silver bullet

</comment><comment><USER8> > satisfying requirements on time and within budget—I haven't seen any > methodology deliver consistent results

There seems to be a false premise. Methodologies don't deliver consistent results on time and within budget because they attempt to help to figure out those software requirements, so that an actual problem can be solved, not useless requirements satisfied.

</comment><comment><USER58> > Maybe social skills come harder to programmers than to other people (I'm not > convinced that's true)

This is, in fact, the answer.

You haven't truly SEEN office politics until you've worked on a team of developers. I'm shocked a reality show hasn't come out yet about software development. It would make Survivor look like Family Matters.

<comment><USER59> I think this is bullshit. I tend to get on pretty damn well with most of my co-developers. The friction comes with managers trying to fit us into weirdly- shaped boxes.

<comment><USER58> What do you mean, "weirdly-shaped boxes?"

I get along with my co-workers too, but social skills are more than just playing nice together.</comment></comment></comment>


Color Founder Bill Nguyen Explains Why You're All Wrong - <AUTHOR> http://www.businessinsider.com/exclusive-bill-nguyen-qa-2011-3?op=1

<comment><USER2> I can see real-time news being an interesting application.

On the other hand, cops and stalkers may also find it useful...</comment>


UK mass surveillance ruled unlawful in landmark ECHR judgment - <AUTHOR> https://www.openrightsgroup.org/press/releases/2018/uk-mass-surveillance-ruled-unlawful-in-landmark-judgment <comment><USER2> To whomever flagged as dupe, can you please link to the original comments/submission?</comment>


Microsoft Is Getting Rich on Android - <AUTHOR> http://www.fool.com/investing/general/2013/07/19/microsoft-is-getting-rich-on-android.aspx <comment><USER2> While it is funny that they make more on android, they are hardly "getting rich" off it. 100 mil for msft is peanuts. It doesn't move the needle.

<comment><USER3> Microsoft had net income of $5 billion last quarter. $100 million isn't "getting rich," but it is 2% of net income.

Granted, it's a smaller percentage of net revenues than of net income. But patent licenses are essentially pure profit, right? You're not doing the R&D for the purpose of getting patent licensing revenue.

<comment><USER4> It's a hundred million more than they deserve for that patent.

</comment></comment></comment><comment><USER5> Does anyone know what patents are claimed by Microsoft on Android? Is it one for FAT16/32? Correct me if I am wrong but isn't FAT16/32 Microsoft's proprietary format? So why is it wrong for them to put a claim on it? Wouldn't Apple do the same?

<comment><USER6> FAT goes back to CPM, maybe even farther (long before Microsoft, and any patents on the original would have expired 20 years ago, and there weren't software patents back then). The extension from FAT12 to FAT16 and FAT32 is trivial.

<comment><USER7> IIRC, CP/M had 8.3 file names, ctrl-Z terminated text files, and drive letters, but its on-disk structures where totally different. That certainly was the case when comparing it to FAT versions that allow for subdirectories (CP/M did not have subdirectories)

<comment><USER6> I had used, in 1984, a CP/M version that had FAT, so I assumed it went to the origins of CP/M. It doesn't, and credit for the original design _does_ go to Microsoft in 1977. [http://en.wikipedia.org/wiki/FAT_file_system#Historical_evol...](http://en.wikipedia.org/wiki/FAT_file_system#Historical_evolution)

The point still stands though: any patent protection for the original implementation would have expired before 1997, which is more than 15 years ago. And it shouldn't have received (in fact, didn't receive) patent protection.

</comment></comment></comment></comment><comment> guard-of-terra The idea Microsoft gets money from Android devices despite not doing anything other than stiffling innovation for the last ten years makes me want ppl in Microsoft have bad stuff happening to them.

<comment><USER8> Stifling innovation? Microsoft was developing software for mobile devices more than 10 years before Google did and for a long time it was the main driver behind the market for PDA/smart phone components (e.g., colour/touch screens, ARM CPUs).

<comment> guard-of-terra They sort of parked their mobile devices progress in the same sense they tried to park IE forever at version 6 and Windows at version XP.

I guess they figured out they no longer have to innovate now when all the market was theirs following the fall of (Netscape, Mac & other OSes, Palm).

And when iPhone came the whole Windows Mobile thing imploded like a house of cards.

<comment><USER9> You cannot compare the failure of Windows Mobile to IE6. The situation created by IE6 popularity was in all likelyhood a fluke, I am not sure Microsoft had a grand nefarious plan that they successfully executed at all. Besides without IE6 we would have most likely had to wait longer for Firefox and Chrome.

<comment> guard-of-terra I don't think it's a grand nefarous plan.

They just thought that they made it. That all the revolutions of desktop browsing (or PDA OSes) are over, and what they have to do until the end of eternity is introducing small evolutionary changes while preserving reverse compatibility.

And that they did. But they were wrong, browsing revolution happened which left IE6, 7 and partially 8 in the dust. Mobile happened, which made them throw away all the Windows Mobile and make it from scratch.

They were not ready to innovate by writing heroic projects fast and tried to persuade market that glacial is okay from now.

</comment></comment></comment></comment></comment><comment><USER10> Google's somewhat foolish acquisition of Motorola would begin to show some dividends if they could leverage Motorola's patents to force a cross licensing agreement which didn't involve paying these fees.

</comment><comment><USER11> This is unfortunate for Android but consumers are still much better off by having a 3rd major operating system. I really hope Android(or Chrome/Android) becomes a viable desktop solution.

</comment><comment><USER12> Aren't these numbers ignoring the possibility that some of those Windows Phone revenues are from app/game purchases on the Windows Phone store?

<comment><USER13> We don't even know for sure how much Nokia pays for licensing Windows Phone, do we?

<comment><USER10> Microsoft is pumping cash into Nokia, not the other way around.

<comment><USER14> That doesn't necessarily mean Nokia isn't paying a license fee. Also Microsoft is paying Nokia for using its maps, so I'm not sure how far the "freebies" go, on either side.</comment></comment></comment></comment>


The Nexus Browser:  the first website in its true environment - <AUTHOR> http://digital-archaeology.org/the-nexus-browser/

<comment><AUTHOR> The book mentioned early in the video is _Enquire Within Upon Everything_

[http://en.wikipedia.org/wiki/Enquire_Within_Upon_Everything](http://en.wikipedia.org/wiki/Enquire_Within_Upon_Everything)</comment>


GitHub acquires AppCanary - <AUTHOR> https://blog.appcanary.com/2018/goodbye.html <comment><USER2> I met Max just before his YC interview. The fun fact there was that we both have the same firstname, came from the same region (Europe), and work on the same product family (Vulnerability Management).

AppCanary went to YC, and Cyberwatch went back to France.

However, for us that was for the best! Most of our customers indeed really liked the fact that we are a 100% French company.

We are now profitable and provide a complete Server Vulnerability Management + Patch Management solution.

Different paths to glory, but the world is small and I'm sure we'll meet again someday :)

=> I wish you the best at GitHub!

<comment><USER3> I remember meeting you that day, it was a very surreal start to our summer in Silicon Valley.

I'm really happy to hear you're doing well in the space!

Building a profitable company is really hard, I should know :)

</comment></comment><comment><USER4> For anybody that needs a replacement that is OSS and can monitor dependencies for updates, there is this:

[https://libraries.io/](https://libraries.io/)

Disclosure: I have no interests (direct/indirect) of any sort in libraries.io

</comment><comment><USER5> I really found AppCanary useful for linux packages. They had nice rollup emails for your servers' packages installed with fixes/patches and those with public vulnerabilities without patches. Is there a similar service that does that on the cheap? I'd rather not run/install my own.

<comment><USER6> For vulns related to linux packages you are welcome to try [https://tactycal.com](https://tactycal.com)

</comment></comment><comment><USER7> Launch feels like just yesterday! [https://news.ycombinator.com/item?id=9935458](https://news.ycombinator.com/item?id=9935458)

<comment><USER8> Top comment in that thread is an expression of hesitation over the pricing. Looks like they kept largely the same scheme over their lifetime, except by replacing the next step up from the $99 tier -- $299 for 50 servers -- with a $499 for 75 servers:

[http://web.archive.org/web/20151205162125/https://appcanary....](http://web.archive.org/web/20151205162125/https://appcanary.com/)

[http://web.archive.org/web/20171026173951/https://appcanary....](http://web.archive.org/web/20171026173951/https://appcanary.com/)

I like the idea of smartly compiling and packaging vulnerabilities and building a business off of that. But was the pricing competitive to what a company devops employee would typically spend in monitoring this? It looks like they provided monitoring and reports with these plans but not anything else on top of sending the alerts.

<comment><USER9> I assume that's why they were acquired. At this point, they were a little bit more of a "feature" than a product. I suspect this tech is driving vuln alerts on repos:

[https://github.com/blog/2470-introducing-security-alerts- on-...](https://github.com/blog/2470-introducing-security-alerts-on-github)

<comment><USER10> > There, we'll be working on expanding GitHub's security tooling, like their > recently announced vulnerable dependency alerting.

You don't have to suspect, it's in the article :)

<comment><USER11> I would hate to take credit for work I didn't do, so I would just like to quickly set the record straight:

We had nothing to do with that feature! We legit joined just now. But it certainly demonstrated a certain synergy between our skillset and GitHub's feature roadmap ;).

</comment></comment></comment></comment></comment><comment><USER12> Congratulations Phill and Max! Really excited to see what you do with GitHub's security alerting. Seeing GitHub take ownership of the space feels like a great development.

</comment><comment><USER13> Congrats Phill and Max! Glad to see some Toronto exits.

<comment><USER14> Are acquihires successful exits?

<comment><USER15> If the equity ends up being worth > $0, I would say "yes."

Way better than just shutting the company down and being left with nothing.

<comment><USER16> Even if the equity ends up being worth $0, I'd still say it's a successful exit, since you're ending up working for a great company that you might otherwise not have been able to get in to. Think of it as an alternative to the standard "whiteboard hazing, recruiter ghosting" interview track.

EDIT: To clarify I'm talking about acquihires in general, not specifically this one, the details of which I'm obviously not aware.

<comment><USER17> I'm not sure that 900 days of labor resulting in an equity value of $0 and a job offer is worth skipping the whiteboard and other recruiting nonsense. (I have no idea if that's what did or didn't happen here, of course, and suspect it was better than that, but that scenario is not one of "success", IMO.)

</comment></comment></comment></comment></comment><comment><USER18> Good luck Phill and Max for your new adventure! And thanks for having mentioned [https://gemnasium.com](https://gemnasium.com) as an alternative.

</comment><comment><USER19> The trend is integrating security into the DevOps lifecycle (DevSecOps). At GitLab we already do SAST and are working on SAST for containers with Claire and DAST. I looked today but couldn't find a good IAST solution that was open source.

<comment><USER19> [https://github.com/baidu/openrasp/blob/master/README.md](https://github.com/baidu/openrasp/blob/master/README.md) Looks like a good rasp solution and with dast that gives IAST. But it is Java only.</comment></comment>


Ray Bandar's Bone Palace - <AUTHOR> https://www.niche-museums.com/browse/museums/100 <comment><AUTHOR> I figure this falls under "anything that gratifies one's intellectual curiosity" from [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment>


How to Ask for a Raise - <AUTHOR> https://medium.com/@jocelyngoldfein/how-to-ask-for-a-raise-da34ee4ecd5a

<comment><AUTHOR> Discovered through Jason Goldman's tweet:

      As someone who hates negotiating I found this really
      good concrete advice for how to ask for a raise.
      https://medium.com/p/da34ee4ecd5a

Source: [https://twitter.com/goldman/status/521030226596618240](https://twitter.com/goldman/status/521030226596618240)</comment>


A New Era of Video Backends: The Unification of VideoCommon - christoph-heiss https://dolphin-emu.org/blog/2019/04/01/the-new-era-of-video-backends/ <comment><AUTHOR> This is an incredible achievement, and despite it being far outside of my area I was fascinated by it.

</comment><comment><USER2> Seems like the strided accesses to the EFB could be recognized in the JIT maybe, and only the pixels likely to be accessed would be copied (not sure how they prepare the EFB copy though, maybe they're not able to resample it).

</comment><comment><USER3> Superb and very enjoyable writeup!

The kind that makes you sit down in a comfy chair with a cup of hot chocolate and enjoy a good read.

Kudos for both the engineering and the writeup!</comment>


NCAA Bracket generator (uses historical data) - <AUTHOR> http://lazyncaa.heroku.com/2012

<comment><USER2> Where did you get your probabilities from? This is a cool idea and although it's getting too late to be useful now, I think it would be nice to implement in my Twitter based bracket challenge, <http://tweetyourbracket.com>. Sorry for the shameless plug, I'm just trying to get the word out about it since I finished it about 8 hours ago.

And I'm with you in the horribly written source code boat. I had my idea the Sunday before the bracket came out and wrote code until last night. Gonna take another look at the code once the tournament is over, we'll see how that goes.</comment>


Ask HN: Interview questions for experienced programmers - <AUTHOR>

I have 15 years of experience as a software developer. What kinds of interview questions are asked to experienced programmers at Silicon Valley startups and companies like Google, Apple etc ? Are they exactly the same as someone getting out of collage ? <comment><USER2> Nope.

When you're a new college grad, it's assumed that you know jack but are hopefully smart enough that you can learn it. Even if you've had some internships, it's understood that someone else was calling the shots, and you're just doing what you're told. The only real exception here is folks who've shown some true entrepreneurship or have already made significant open- source contributions.

Therefore, the questions that most companies ask new college grads are to assess potential - what you got out of your college courses, what initiative you've shown in your life so far, what your general level of curiosity, intelligence, etc, etc, etc is. Hence lots of puzzle-type questions and softballs to give you a chance to highlight the best stuff you've done in the first 20 or so years of your existence.

However, when you have 15 years of experience, you'd better know your shit in several areas related to your work experience. Expect to be grilled in the top few technologies you list on your CV. Also, at this point, you're expected to have shown good judgement and leadership at some point, so expect to be asked about that. And savvy companies know that in 15 years, you've likely royally screwed up on some occasion, so expect to be asked about that in order to demonstrate hat you're honest, humble, willing to learn from mistakes, and a whole slew of other things smart developers want to see in their experienced comrades.

In other words, review your work experience so far - what have you learned? How have you demonstrated your value? Where have you grown? Where are you still growing? Be prepared to talk about those things - and don't pass up the opportunity to do so.

Many prospective employers and future coworkers will be concerned that your knowledge is 15 years old, so be prepared to answer potentially condescending questions about how you've kept your skills up to date (and I sure hope you have).

(Nevermind that everything interesting in software was discovered 30 years ago - that won't impress anyone who's not already very aware of the fact, so it's probably not worth pointing out.)

Oh yeah, and expect to code. At the very least, expect to show some code you've written. This should be true (at clueful companies) for new grads as well, but is typically more true for experienced hires.

<comment><AUTHOR> Thank you for your thoughtful response. So it seems, there could be a lot more behavioral style questions compare to white-board coding? Does that mean less algorithm and binary tree/sorting related questions?

I've been a programmer all those years and haven't pursued much on managing other people, would that work against me ?

<comment><USER2> Yes, more behavioral, less algorithmic. At least, fewer general algorithmic questions, though maybe expect some that are specific to the employer or your experience.

Regarding the managing thing - not necessarily, though most programmers with your years of experience have managed in some capacity before, you so may be asked why you have not. In my experience, though, a lot of experienced programmers looking for jobs seem to be in the opposite situation - they've been managing for a few years and now are looking to get back into programming.

<comment><AUTHOR> I was in academia for 8 years and working with scientists to build prototypes. Although work is interesting in universities, most programming jobs are dead- end career wise. I quit my job a year ago to build iPhone apps and learned quite a lot as an entrepreneur. Hopefully that should help me with the interviews.

</comment></comment></comment></comment><comment><USER3> Why is a manhole cover round? It's an oldie that tests logical thinking, I believe Microsoft used to use it back in the day :)</comment>


Don't include social engineering in penetration tests - <AUTHOR> https://jacobian.org/writing/social-engineering-pentests/ <comment><USER2> Is there really no code to not do any physical damage or harassment as a pen tester? It seems like don't hurt or terrify the employees of the company would be a pretty high priority for any business that wants to do repeat work.</comment>


Writing An Interpreter In Go (2016) - <AUTHOR> https://interpreterbook.com/ <comment><USER2> I had a lot of fun with this book, after belatedly buying it. I've read a couple of similar online-books in the past, but this was the first one I worked my way through completely.

As a result I later had a lot of fun writing a simple compiler for a reverse- polish calculator, to generate AMD64 assembly language [https://github.com/skx/math-compiler/](https://github.com/skx/math-compiler/) , wrote a simple BASIC intepreter [https://github.com/skx/gobasic](https://github.com/skx/gobasic) , and put together a couple of DSL-projects which followed a similar approach.

All in all I'd recommend reading it, and definitely working through the code. Once you're done you can continue to experiment - adding support for regular expressions, a standard-library, etc, etc.

My version of the language is here and contains a fair number of improvements/additions. After covering the core in such detail it wasn't hard to extend further, even if that was primarily for fun, rather than for a real purpose:

[https://github.com/skx/monkey/](https://github.com/skx/monkey/)

</comment><comment><USER3> Can anyone recommend other books similar to this one?

Having done the Nand2Tetris course and started the Ray Tracer Challenge book I find I really like these books that guide you through a pretty complex project.

It helps you learn by doing while at the same time preventing you from falling into bad practices or getting overwhelmed.

<comment><USER4> [https://www.itu.dk/people/sestoft/plc/](https://www.itu.dk/people/sestoft/plc/)

Sestoft is a very clear writer, and F# is a better language than most for writing interpreters or compilers.

<comment><USER5> How is the quality of F# in that book? I've been itching to make the leap and this seems like a good way to do that, but I'd feel more confident if I knew that Sestoft's demonstration of the language set a good example.

<comment><USER4> I've never done F# professionally so I can't speak to how idiomatic it is, but it gets the job done from a learning point of view.

</comment></comment></comment></comment><comment><USER6> Highly recommend this book. After reading it (and the compiler book by the same author), I started my own compiler for Knox, a Go-like language. It has been a fun project, but I made some bad decisions regarding the type checker and how I store the AST, so I'm currently procrastinating fixing those. You can check out the source here:

[https://github.com/AZHenley/knox/](https://github.com/AZHenley/knox/)

</comment><comment><USER7> This week's Go Time podcast featured the author. It was enjoyable (as are all their podcasts). He also has a compiler book that is the sequel.

[https://changelog.com/gotime/107](https://changelog.com/gotime/107)

</comment><comment><USER8> There recently also was an entertaining podcast episode with Thorsten Ball on SE Radio, in which he talks about compilers vs. interpreters and about his book as well: [https://www.se-radio.net/2019/05/365-thorsten-ball-on- buildi...](https://www.se-radio.net/2019/05/365-thorsten-ball-on-building-an- interpreter/)

</comment><comment><USER9> What timing. I just started implementing an interpreter in go this past weekend. I'd been following Bob Nystrom's [https://www.craftinginterpreters.com](https://www.craftinginterpreters.com), translating java into go as well as comparing my impl to the go package scanner, parser etc. ([https://golang.org/pkg/go/](https://golang.org/pkg/go/)) It'll be very interesting to compare my own approaches with Thornsten Ball's to see if my use of idioms and intutions about certain things were on the right track.

</comment><comment><USER10> I'm about 1/4 of the way through it. I enjoy it so far. My only criticism is that I wish it had something in the way of exercises. It's a lot of copying (typing) code and it explaining what the code is doing and the concepts behind what you've written. That's a good approach, but I enjoy thinking through things on my own a little as well then being told how the author would have done it and why. Otherwise very good!

</comment><comment><USER11> Lol, ebooks should have regional pricing like games. Buying these books means I will have to shell out 1/3rd of my total monthly income (student in a third- world country). Makes me wonder if there is a market for a paid service that can make copies of books available for a monthly rate (kind of like a paid ebook library with region locking and special format that can only be read by the app with a constant internet connection - Netflix for books if you will ). But I guess it would be hard to do because its just texts and if there was money in this, Amazon would have done it already.

<comment><USER12> The author is very friendly and responsive. I'm sure he'll respond to your concerns if you reach out to him.

<comment><USER11> Ah, my comment was not particularly about this book. It was just a general assessment of how pricing may be a barrier for useful and practical books to a larger set of audience. And a little bit of thinking out loud if there was a viable solution to it.

</comment></comment></comment><comment><USER13> I find it interesting that the Monkey language, created solely for the examples implemented in this book, looks strikingly similar to a simplified EcmaScript (ES2015+ actually). Is ES/JS the best example of a parseable language? Why not just shoot for a (subset) ES interpreter instead of a made up language that does not resonate as much with the reader?

<comment><USER14> Using a fantasy language lets you avoid anything that makes the implementation complicated or tedious.

</comment></comment><comment><USER15> I worked through this soon after it came out and I enjoyed it a great deal

<comment><USER16> Have you read other books with similar goals? How does this compare? I've been meaning to go through and write an interpreter / compiler but havent found time / right resources, but this seems interesting cause I've grown to love Go more lately, and how you get so much out of the box. I might just try it, but I'm curious what someone else's experience might be who was in my shoes when they read it.

<comment><USER15> I studied compiler design at university and the subject matter here was a lot more approachable, but in that, it sacrifices a lot of the theory.

<comment><USER10> I agree that it doesn't dive deep into a lot. It also makes notes of things you don't need to know while you're working through the book. That said, if you just want a basic grasp of what is happening to your code when you run it, this is a good place for that. I don't plan on writing a compiler outside of this book, and I don't think this book directly serves doing that. What it does serve is my curiosity in a compact way.

</comment></comment></comment></comment><comment><USER17> As someone who just recently started learning Rust, I'd love to see a book like this that uses it as the implementation language instead.

</comment><comment><USER18> I'm curious about this chapter:

"Why not a parser generator"

Seemse like the way to go these days? Why write it yourselve if you can generate it from EBNF notation?

<comment><USER19> Author here. I'm going to be super shameless here and quote myself in that chapter:

> [...] we are here to learn, we want to understand how parsers work. And it's > my opinion that the best way to do that is by getting our hands dirty and > writing a parser ourselves. Also, I think it's immense fun.

In other words: use a parser generator when you need a working parser, quick. But if you want to learn how parsers work, what ASTs are, what "top-down parsing" means, etc. then I recommend you write your own. It's not that hard once the concept "clicked" and, again, it's a ton of fun :)

<comment><USER20> > use a parser generator when you need a working parser, quick.

Not necessarily. Use it also when you need a more correct one :-)

The way the book presents the parsing subject leaves the impression that a handcrafted parser is generally preferrable.

I have experience with a project that was based on that book, and there were (and probably, are) a lot of bugs in the parsing code, that wouldn't have been there if a parser generator was used.

I don't camp for using parser generator at all costs, however, presenting both sides of the coin would allow readers to make a (more) informed choice.

<comment><USER19> > I have experience with a project that was based on that book, and there were > (and probably, are) a lot of bugs in the parsing code, that wouldn't have > been there if a parser generator was used.

I think I need to a add a big "do. not. use. in. production!" disclaimer then :) The parser we build in the book is, of course, not a battle-tested, industrial-grade parser that can survive every fuzzer you throw at it. Far from it, but that's fine, since that was never the goal. The goal was always to learn.

So, yes, I agree. If you do need a production-ready, stable parser: use a mature parser generator or, maybe, invest more time in getting good at writing parsers than it takes to read and work through the ~100 pages I wrote on the subject.

<comment><USER21> Since you have written a book in the subject you obviously are much more of an expert than I am. After reading your book what materials would you recommend for someone wanting to reach the stage is bring able to implement their on "production grade" parsers?

</comment></comment></comment></comment></comment><comment><USER22> I really enjoyed this book. In fact, after reading through it I wrote some code to tokenize TypeScript with TypeScript. It was a fun little project even thought I didn't really go all the way with it.

</comment><comment><USER23> funny, i was listening to the go time podcast during my commute this morning and they had the author on...

the author seems to suggest that one should start with an interpreter, then move to a compiler. (read the interpreter book, then read the compiler book...)

i think it really depends on what you are doing. in fact, python is a good example. it compiles to bytecode that is interpreted. it has the both compiling thing going on and then the whole VM thing. i believe java is similar. what i am trying to say is that the line is very blurry nowadays.

<comment><USER24> I'm not an expert, just a hobby language designer, but it seems to me that the advantage of starting with an interpreter first is that this allows you to more easily design a language in which compile-time expressions have some reasonable expressivity. Generally, an interpreter allows the designer to experiment more with the semantics. Typical examples are evaluation of expressions for constant definitions at compile time or having built-in access and language support (e.g. syntactic sugar) to 3rd party libraries like arbitrary precision arithmetic.

The disadvantage is that it can be a lot of work. From my experience, writing a toy VM in Ada didn't seem much easier than writing a compiler in a toolkit like LLVM. (But I've never done the latter.)

</comment></comment><comment><USER25> A thread from 2017: [https://news.ycombinator.com/item?id=13707000](https://news.ycombinator.com/item?id=13707000)</comment>


The curse of the spinning statue at Manchester Museum - <AUTHOR> http://www.manchestereveningnews.co.uk/news/greater-manchester-news/video-curse-spinning-statue-manchester-4698583

<comment><USER2> > Campbell Price, a curator at the museum on Oxford Road, said he believes > there may be a spiritual explanation to the spinning statue.

> "In Ancient Egypt they believed that if the mummy is destroyed then the > statuette can act as an alternative vessel for the spirit. Maybe that is > what is causing the movement."

FFS.

> "But it has been on those surfaces since we have had it and it has never > moved before. And why would it go around in a perfect circle?"

Off the top of my head: floor joists have moved causing more vibration now than in the past.

About it moving in a circle: that's what physics does. It's lovely. Here's a diagram of a ruler placed on the fingers of two hands, where you move the hands together. The ruler slides, and the hands meet in the middle. (Good Grief I need to learn how to express a simple idea.)

([http://imgur.com/ZQ6RQkj](http://imgur.com/ZQ6RQkj))

</comment><comment><USER3> It's just a smart advertising.

<comment><USER2> It is immensely depressing that a museum (a place of learning and wonder) is using such tactics (appealing to the worst kind of ignorance) to drum up trade.

<comment><USER3> Absolutely. But still, the final goal is fine : if more people go to this museum to see this "haunted statue" and learn new things, then I guess it's okay.</comment></comment></comment>


Iron Sky Official Theatrical Trailer - <AUTHOR> http://www.youtube.com/watch?v=Py_IndUbcxc

<comment><USER2> I was looking forward to this until I found out it was a comedy instead of a serious b-movie.

The latter would be awesome.</comment>


Show HN: Procrastination Solved, for the Price of a Coffee - <AUTHOR> https://accountably.net <comment><AUTHOR> If you are someone who really wants to get things done but procrastination often comes in the way, then you need a coach. BIG TIME! But wait, those coaches are very expensive right? N-O!

You can get a personal coach for the price of a coffee! Now that's a coffee well spent. Think about it!

For the price of a coffee, we give you a personal coach who will check in with you regularly and keep you on track with your goals. There is also a 4 week free trial, so there is really nothing to lose.

If you have any questions, I'm happy to answer. Feedback and suggestions are always welcome!

Cheers :)

</comment><comment><USER2> I'll get around to it one of these days.

<comment><AUTHOR> Thank you! Appreciate it!</comment></comment>


Obamacare backend code? - <AUTHOR> https://www.java.net/forum/topic/glassfish/metro-and-jaxb/jaxb-error-no-element-mapping-exists-when-binding-xml-objects Zip file at the bottom of the page... <comment><USER2> This one looks more related to www.getinsured.com than the obamacare. I accuse you of the Title is misleading and to get more karma :).

</comment><comment><USER3> source file pulled from post: [https://gist.github.com/michaelkirk/6922847](https://gist.github.com/michaelkirk/6922847)

In package "com.getinsured"

<comment><USER3> Post was by "Sirini", could that be short for "Shankar Srinivasan, COO and Co- Founder"[1]

[1] [http://www.getinsured.com/answers/our- team/](http://www.getinsured.com/answers/our-team/)

Edit: Nope, probably their product manager: [http://www.linkedin.com/in/srinidhanam](http://www.linkedin.com/in/srinidhanam)

</comment></comment><comment><USER4> cms.gov is medicare back-end, not sure if this is an extension of that or part of the original

<comment><USER5> The Healthcare.gov Github repo does live under the CMS.gov account ([https://github.com/CMSgov/healthcare.gov](https://github.com/CMSgov/healthcare.gov)).

(Edit: No, this isn't the marketplace code, but the fact that they share a Github account is some evidence the marketplace could be reusing/extending CMS.gov code).

<comment><USER6> That's only the static information and FAQ site, not the marketplace.

From the readme:

>This project does not include any source code for the Federal Health Insurance Marketplace (the online systems located under www.healthcare.gov/marketplace.

</comment></comment></comment><comment><USER7> Ugh jaxb. I thought we had all moved on? Real men stax directly.

</comment><comment><USER8> it would be in java...

<comment><USER9> Damn! It figures boring insurance code would be written in rock solid tried and true technology that hipster kids dislike!

<comment><USER10> C# has all of those listed features, yet is still usually considered at least okay by hipsters. :)</comment></comment></comment>


Why China will beat the West in the deadly race for AI weapons UK - <AUTHOR> https://www.wired.co.uk/article/artificial-intelligence-weapons-warfare-project-maven-google-china <comment><USER2> I see it opens with a classic hippy-punching quote from someone who probably thinks the Vietnam war was just great: ""These naive hippy developers from Silicon Valley don't understand – the CIA should force them," says [Sandro] Gaycken, founder of the digital society institute at ESMT, a Berlin-based business school."

My three questions would be:

1) How is countering ""AI"" weapons different from countering any other kind of guided or semi-autonomous weapon system? (Do things like "Phalanx" anti- missile guns count as AI, for example?)

2) How do the information security challenges differ from the normal information security challenges against human-made massively automated attacks? At the moment defense in this area is really neglected to start with.

3) (The dark question) How does this stuff relate to civilians, especially in partial, secret, undeclared or unconventional warfare? Do we get to be civilians at all or are the norms so thoroughly eroded?

</comment><comment><USER3> Those who don't live by the sword can still die by one. Any capable party should, at the very least, be developing AI countermeasures in anticipation of fully autonomous weapons, even if they swear off autonomously targeting humans. Throwing your hands up in the air and protesting "but it's not _nice_ " isn't going to help you when push comes to shove.

<comment><USER4> We have nuclear weapons. Nobody would dare to invade our mainland. This is only useful for one of our many murderous expeditions around the world. I'd say maybe we shouldn't be invading other countries.

</comment></comment><comment><USER5> mods: pls edit the title as there's no UK in it.</comment>


Hyper - <AUTHOR> https://hyper.is/ <comment><USER2> Why?

Seriously, why?

Not only is it electron based, so my memory usage for a terminal is stupid high, but what sets this apart from your _standard_ terminals, because maybe plugins?

I'd trust the standards over this any day, just because of handling of edge- cases, unicode comes to mind.

<comment><USER3> Are we really worried about memory usage anymore? I mean, I am using a laptop that has 16GB of DDR4 RAM, what's 100-200MB of memory usage going to do?

<comment><USER2> Yes.

Why on earth would you rather something that takes up 100-200 MB over something that uses less than 5 MB (my biggest memory hog putty on Windows)

With that mindset, your 16 GB of RAM will go away after a few programs, because the devs weren't worried about memory usage. That is just the wrong mindset to have as a developer.

Apps like this are making things needlessly complicated, just for the sake of complicating.</comment></comment></comment>